Chris Adams wrote:
> It shouldn't be based on the sum, as that would mean positives for one
> release could override negatives for another.
That's kinda the whole point. "Kinda" because of course negatives should not
be ignored, but that's always true, even if the positives are for the same
release! They need to be checked for validity (e.g. longstanding breakage
which is not a regression nor the one bug supposed to be fixed is not a
valid reason to reject the update, but I've seen even more blatantly invalid
complaints), and fixed if valid, not outvoted. (This just shows again how
numeric karma is flawed. It's really stupid to rely on that number for
anything serious.) But my point is that lack of positives for some release
should indeed be ignored if there's enough positive feedback for the exact
same update on some other release.
> If you want to require simultaneous pushes, they should only be after
> testing for each release is known good.
First of all, I don't want to REQUIRE anything, but RECOMMEND things. We
already have enough rules we're required to follow, and unfortunately more
(and completely unnecessary ones at that) are coming soon. :-(
And secondly, my suggestion is to assume that positive feedback on release n
+ no complaints on release m = the package is fine on release m as well
(which has a probability very close to 1 in practice, especially if it's
built from the same specfile in both cases).
> Just because something works on F12 doesn't mean it doesn't break things
> on F11.
Theoretically yes, but in practice it's extremely unlikely.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
