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