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.
Suggestion:
- 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
guidelines:
- 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
avoided.
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
unstable.
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.
cu
Adrian
--
"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: