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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
