New bodhi release in production

[Kevin Kofler]

Al Dunsmuir wrote:
> You are assuming that it is somehow a good idea to push release Fn, in
> spite of no (or negative) testing.

Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see 
why testing on ANY F* isn't sufficient. Please don't bring the same old 
argument that "sometimes" breakage happens only on some releases even with 
the same specfile: in practice this is so rare that it doesn't matter at 
all, it's much more likely that regressions slip through despite the 
testing. (And I have years of experience with KDE updates to draw from when 
making that assertion. Sadly, I can't really prove it because Bodhi deletes 
all the records for EOL releases, so you'll have to rely on my memory. 
Release-specific regressions happened only 1 or 2 times overall (and the 1 
time I remember was a maintainer using string comparisons for %{fedora} 
which broke on the 9→10 transition, something that 1. can't cause breakage 
again until Fedora 100 and 2. shouldn't happen to an experienced maintainer, 
I'm sure that particular maintainer won't make that particular mistake ever 
again after me yelling at him for the breakage ;-) ), regressions missed by 
testing, despite lots of positive karma, were much more frequent. In fact, 
we completely ignored the karma value for our KDE updates so far, it doesn't 
really say anything about the quality of the update!) Testing will NEVER be 
a 100% perfect process anyway, so why do we care about some .001% chance of 
breakage? It's much more important to be able to rapidly fix things when the 
testing failed, and that's exactly what direct stable pushes are needed for 
and what the new process breaks.

> A  saner  approach  would  be  that  for related changes, release Fn-1
> should not be pushed to stable until release Fn is _also_ ready to go.
> This  prevents the EVR problem, and ensures that regressions caught on
> release Fn that are also applicable to release Fn-1 will not escape.

This can stall updates for ages waiting for all the branches to get the 
required testing. Testing requirements quickly multiply: e.g. if you require 
2 karma, of which 1 proventester (which is what's required for "critical" 
packages), requiring it on all branches makes this a requirement of 6 karma, 
of which 3 proventesters! It takes a VERY long time to get so many karma 
points, plus they need to be on the correct releases or they'll be 
worthless.

        Kevin Kofler