Re: Red Hat 5.0 Release date
Aside from the fact that you have ignored the testing team in your
schedule (I don't really have a problem with this if you can put a better
team in its place), This schedule has far too many milestones that are far
to close together. Several of your important milestones are less than 5
days appart. Experience with the testing team suggests that this is enough
time to do one simply round of boot disk testing and little else.
As to the overall schedule, it seems to me that if we can get to code
freeze by the first of the year (you have a similar milestone here) that
we can release by Feb 1.
My feeling about the last release and its vast improvement over 1.2 was
that it was primarily the result of our first attempt at a Managed testing
proceedure. While we have a long way to go with the organization of the
testing team, pulling a global reorganization of the release proceedure at
this point will not be helpful to this effort.
While your schedule would probably work in a tightly controlled effort, I
don't think it will work here.
Sorry ;-)
On 20 Nov 1997, Jim Pick wrote:
>
> 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
>
>
>
Dwarf
--
_-_-_-_-_-_- _-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
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: