Bruce Perens <bruce@debian.org> writes:
> Let's not treat this as if we were in competition with Red Hat.
But we are, sort of... if Red Hat gains momentum in the Free Software
community, and Debian slows down or stops (because we can't get our act
together), even I'd seriously consider switching...
> How many packages are still not ported?
I'm not sure, you tell me. You're the project leader - your release
engineering lieutenant ought to have been giving you progress reports.
I don't see what's really, really wrong about making a hybrid libc5/libc6
release. We should aim for making most things libc6, if at all possible.
Maybe even having a week we dedicate to making non-maintainer releases.
Let's put things on a fast track. Ian's improvements to the bug system
allow us to be organized enough to do that. I think we could pull off a
Jan. 31 release date. Not before then, because of the holiday season.
The last release cycle was way too long. We should compress the testing
window and organize it much more. We badly misused the important testing
concepts of 'frozen' and 'release candidate'.
Proposed schedule:
Dec. 1 - Finalize testing and release plan.
Dec. 15 - New packages freeze. New packages can still be uploaded, but
they get placed in a directory for 2.1 release. Bugfixes and
non-maintainer releases can still go in, of course.
Testing begins. Start off by breaking distribution into parts,
and assigning testing teams. Try to involve all the developers
in this. Testing isn't too hard. Each package should be tested
by at least 5 developers. Try to get at least one person who can
test upgrading from a bo system for each package.
Let's use the bug system:
a) Start by filing a Critical bug against every package with
the title "Untested" - include in the body of the bug the
5 testers assigned to do the testing
b) Each tester files a testing report against the "Untested"
bug. When the 5th "pass" report is filed, somebody closes
the critical bug.
c) No uploads which don't fix bugs - so we don't undo the work
of the testing team
Jan. 10 - Developer testing ends. Release team takes over.
All bugfixes are due. Past this time, ownership of the release
goes to Release team. Automated uploads are disabled. All
bugfixes and non-maintainer releases must go directly to the
Release team.
The release team makes a todo list, and posts it daily.
Decisions are made for all packages that still have critical bugs.
Some may need non-maintainer releases, organized by the Release
team. Many packages will need to be pulled from the release
(left in unstable, but not put into frozen).
Jan. 15 - Release team makes 'frozen' release for testing. All developers
are encouraged to upgrade any 'stable' systems they have. General
call for users to help with testing release. Release team can
make updates.
Jan. 25 - Frozen becomes 'Release candidate'. No more bugs should exist.
The Release team cannot make bug fixes without restarting test
period. They can, however, withdraw non-base packages. If a
critical security bug appears (ie. in XFree86, or the kernel), the
release must be delayed. If a security bug appears in a
non-essential package, that package will be removed and left for a
maintenance release.
Jan. 31 - No disaster should have been allowed to happen, so we can safely
release 2.0.
So what does everyone think? Is this workable?
Cheers,
- Jim
Attachment:
pgp7eY3pVU5Fu.pgp
Description: PGP signature