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

Re: Red Hat 5.0 Release date

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?


 - Jim


Attachment: pgp7eY3pVU5Fu.pgp
Description: PGP signature

Reply to: