Re: Red Hat 5.0 Release date
Jim Pick <jim@jimpick.com> writes:
> [1 <text/plain; US-ASCII (7bit)>]
>
> 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.
Probably. I think this question was directed at Richard Braakman, who
has been doing an excellent job of keeping track of yet to be
converted packages.
I went through the list and did my one outdated package and a bunch of
orphaned ones. I was trying to allow developers more time before
doing non-developer releases of the other packages.
If everyone did 2-6 packages this weekend, we could easily get that
"230" number down to something managable.
> 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.
FWIW, RedHat went the other way, their first libc6 beta was missing
anything that they didn't have compiled for libc5 yet. We really
should have done the same thing and not allow packages in until they
were converted. That would have put pressure on people to do the
conversion.
> 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.
One big issue is boot floppies. Another is FTP install, which hasn't
worked right for years.
> 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.
We could have our testers start testing upgrades from bo right now,
I'm sure there are still a few issues to work out.
[Schedule deleted]
> So what does everyone think? Is this workable?
Sounds good to me.
Steve
dunham@cps.msu.edu
--
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: