A proposal for an always-releasable Debian [LWN.net]

A proposal for an always-releasable Debian

Posted May 11, 2013 3:10 UTC (Sat) by yarikoptic (guest, #36795)
Parent article: A proposal for an always-releasable Debian

Sounds good in general and automated testing is long overdue. But I must disagree with having "two classes of citizenship for packages". Placing any strict boundary would divide not only the package space but also the community. Even though some packages are already "more important" than the others (as judged already by e.g. popcon statistics, i.e. we already have the mechanism), separating them into two distinct bins would make an ugly crack in the beauty of Debian -- Debian is a "universal" operating system and open for contributions for any field of endeavor, and thus every package at least potentially is as important as any other.
Labeling the majority of packages "second class" would just be of a mistreatment for their maintainers IMHO without any obvious advantage (once again -- we already can weight importance of any particular package and not just with binary scales of "1st class"/"2nd class").

Reference installations would further widen the crack and I do not think that "broad consensus" would be achieved if such installations would mandate the "citizenship" of packages. Why would I bother packaging anything if upon occurrence of RC bug my package could be easily kicked out from the perspective release? To overcome this problem in my case I would demand having a "neuroscience" reference installation... and guess what people would end up doing if their reference installation proposals would not be accepted? expect even more Debian-derivatives.

So -- would we need reference installations and more testing -- YES. Should they be restricted to a very limited set -- NO.
Should they mandate package "citizenship" -- NO.
IMHO we better concentrate on further strengthening of QA (e.g. more of build time and as-installed testing suggested here). With improving on those ends we would reduce amount of RC bugs without sacrificing what makes Debian beautiful and making anything/anyone a 2nd-class.

to post comments

A proposal for an always-releasable Debian

Posted May 11, 2013 4:59 UTC (Sat) by dlang (guest, #313) [Link]

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.