On Sat, Feb 13, 1999 at 01:27:19PM +1000, Anthony Towns wrote: > First, if we don't spend much time between release cycles, the only > times you can upload *anything* is during the freeze or "just before" it. What I'm referring to is the tendency for people to rush anything in just before freeze, with the expectation that they can make it work later. In other words, people seem to upload intentionally buggy new releases just before freeze so they can put stuff into frozen as a 'bugfix' instead of a 'new release'. > Second, have a look through the remaining release-critical bugs. The > majority are a bunch of irritating little things against packages that > aren't related to major changes in anything and there are a few bugs, > notably the boot-floppies ones that simply don't get worked on outside > of the freeze, and just plain take a while to get right. But when I asked last week what was holding up the release, I was told that a big part of it was the non-i386 archs. Some of that is just keeping up with the volume of packages, and some (if I understand rightly) is working on the patches for X -- which had some major changes just before freeze. And why did the boot-floppies change so much? They worked in slink, right? Was it something that _had_ to be done before we could ship slink, or was it something that we just didn't want to wait another year for? > If you're planning on saying "okay, we're in the slink freeze now, that > means it's not long until the potato freeze -- anyone who needs to do > major development had better start now", which seems the only way to > avoid the former problem, you're going to have less people caring about > fixing release critical bugs, which will make freezes take yet longer. Several people have volunteered to work on release critical bugs. AFAIK, there's not really anything to do. (If something does need to be done, please shout it out.) I think the no-bug-fix argument is a red herring; I don't think it's really unfixed bugs that are holding us up. I have to say that's part of what I find exasperating about this process: if someone said that in order to release slink we need to do x, y, and z, people could work on x, y, and z. But what we have instead is a vague idea that we're not ready to release with no concrete tasks to divy up. > And, personally, I'd be happier taking four months to release something > that had real improvements, rather than just another incremental release. It has to be one or the other? We can't even try to make real improvements on a regular basis? Mike Stone
Attachment:
pgpqfWXpat1Yd.pgp
Description: PGP signature