[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposal: regular bug squashing parties and weak freeze

Below is a suggestion how I think some progress could be made towards 
the release of Debian 3.1 and how I'd be willing to help.

All I want is a "yes" or a "no, we have a better plan" answer from the 
release manager and his assistants.

- a weak freeze of unstable in the near future
- regular bug squashing parties with 5day-NMUs

Where I'd be willing to help:
I will organize weekly or bi-weekly bug squashing parties with a 
meeting in IRC (perhaps connected to local bug squashing feasts anywhere 
in the world).

What is a "weak freeze"?
Opposed to a normal freeze that disallows all new upstream code (except 
for bug fixes), a weak freeze should follow roughly the following 
- only low-risk changes to packages
- stay inside an upstream stable branch
- no big changes to the packaging
- completely new packages only when they are likely to be bug-free
Roughly spoken, a new upstream version that contains only bug fixes is 
OK, but a new upstream version that adds tons of new features should be 
These are only rough guidelines, the maintainer of a package should 
know best about the risks of new upstream versions.

Couldn't you fix bugs without a freeze?
Without a freeze, fixing bugs isn't such effective since the number of 
new bugs caused by new upstream versions and big changes to packages is 
pretty high.

Why start with freezing unstable and not with freezing testing?
The last years have shown that the quality of testing is strongly 
depending on the quality of unstable.
To avoid releasing Debian 3.1 with bugs that were fixed ages ago in 
unstable, every freeze of testing would require one or more persons to 
check _all_ packages where the version in testing is older than the one 
in unstable whether the version in unstable contains important fixes.
If unstable is in a good state, testing is ideally identically to 
Even if the "real" freeze will be in testing, it will be shorter if most 
of the problems are already sorted out.

What should be done at such bug squashing parties?
- work on fixing RC bugs
- work on fixing non-RC bugs
- identify MIA maintainers and orphan their packages

Isn't it enough to focus only on RC bugs?
RC bugs are an important metric for checking whether a set of packages 
is ready for being released, but even if the number of RC bugs in 
packages in testing would magically drop to 0 today, the packages would 
still be months away from the quality Debian users are used to in terms 
of package quality and working upgrades.



       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply to: