User: Password:
Subscribe / Log in / New account

A proposal for an always-releasable Debian

A proposal for an always-releasable Debian

Posted May 11, 2013 4:59 UTC (Sat) by dlang (subscriber, #313)
In reply to: A proposal for an always-releasable Debian by yarikoptic
Parent article: A proposal for an always-releasable Debian

having to argue for every bug for every package over if it's important enough to be a Release Critical bug that should delay a release or not is exactly why the freeze ends up being 10 months.

People really don't like to argue like that.

Dividing things into "mandatory" and "optional" for a release and promising to fix RC critical bugs in the mandatory category, but not in the optional category make sense, and is what happens today, it's just that the categories are not defined clearly, so people really don't have any idea where they stand.

I agree that the filing of a RC bug against a package should not cause it to be removed from testing.

But it should be enough so that if the bug is not addressed (either fixed or converted into some form of NOTABUG) within some time frame (I'm thinking 30 days or so) the package and anything that requires it should get publicly flagged as something that would be dropped from the release if a release were to happen at that point.

If a package in the "mandatory" group does not address a bug in a reasonable timeframe (probably something like 90 days or so), then it should be moved from the "mandatory" group to the "optional" group, as long as there is some other plausible option available (you won't remove gcc, but you could remove MySQL and replace it with one of the other forks)

It really should not be that hard for a project to avoid triggering either of these rules. If the project has been in a prior release, avoid or fix regressions and you should not have a problem.

Making 'change the world' changes to large groups of packages is a problem, but such changes are a problem anyway and should be avoided (just like kernel development, try to do incremental changes, maintaining compatibility and get to your destination gradually, or at least with an easy fallback option)

There is a category of RC bugs that are an exception to the above, and those are the "political" bugs where the rules change, with all packages required to change to follow the new rules. I would say that the "mandatory" packages should be changed _before_ any such new rules go into effect, and the "optional" packages should be encouraged, but not required to follow such rules wherever possible.

Yes, rules like this could hurt "mytinyapp", but as the post says, a bug in bash really should delay a release, but a bug in Nethack should either be tolerated, or if it really is Release Critical, Nethack should be dropped from the repository until it gets fixed. If nobody cares enough to fix it for a long time, so be it.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds