Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

John Morris jmorris at beau.org
Thu Sep 2 23:23:01 UTC 2010


On Thu, 2010-09-02 at 14:17 +0200, Dennis J. wrote:

> What I would like to see is a distinction between regressions and other 
> bugs. There are a least two reasons why this might be worthwhile:
> 
> 1. Regressions break functionality that has been known to work previously 
> and the users already rely on. If new stuff gets added and has bugs that is 
> not as serious because users are not yet relying on this to work.
> 
> 2. Regressions can be easier to fix because you have a "known to work" case 
> you can use as a comparison. If bugs could be flagged as regression then 
> developers you potentially look at these first right after the regressions 
> occurred and probably identify the reason for the regression right away.

I'd like to suggest another reason regressions should get higher
priority.  Regressions hit people who already have Fedora installed and
running and puts us in a bad place.  Every install is less than a year
away from being unsupported and a serious regression leaves us unable to
stay on the upgrade treadmill.

In my case I reported #573135 back in March and stopped taking kernel
updates. In another month or so I'll boot a live USB stick of F14 and
see if the bug was fixed and just didn't get closed.  Then it is either
suck it up and run without security fixes or jump distros.

That is the difference, a bug in a bad place might stop a new user from
migrating to Fedora while a regression combines with the short support
cucle to force an existing user to migrate away if it exists across two
releases.

There really needs to be a change of attitude from "Ooh! Shiny!  Ship
it!" to not shipping new until it at least does everything the old did
and reverting when serious bugs appear and can't be quickly patched.
Yes I realize I'm suggesting something that will result in new stuff
taking longer to arrive.  At some point we really need to begin a shift
away from furious development of new features into a more quality driven
focus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20100902/4c7dee0f/attachment.bin 


More information about the test mailing list