On Fri, Feb 12, 1999 at 11:29:28PM -0500, Michael Stone wrote: > 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. I don't know enough about what Branden's been doing to X to comment on this, personally. A lot of it could've been avoided if the split hadn't happened, sure. But it was just a package split, why should that have caused problems. Hindsight is great, isn't it? > 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? The base system changes. The stuff that needs to go on the boot-floppies changes, and that means other things have to be removed. Remember that the first slink rescue disk didn't fit in 1.44MB because of the extra stuff that had been added to just the packages need to boot a rescue disk. We're also supporting Apt with slink, and main no longer fits on a single CD. There's also been some improvements to the documentation on the boot-floppies, and I've no idea what else. (YMMV, this is just from what I've surmised from the lists. I haven't done a slink install, personally) > 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. I agree whole-heartedly with this, though. You might like to subscribe to debian-testing, which has occassional "what's left to be done" threads, and which is also fairly low-volume. > > 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? If "incremental" is "new upstream releases of a bunch of packages, and not much else", it is be definition, but if it's more than that, it's cries of "gee, we'd better not set goals, or plan to do too much or it'll be hamm all over again." Or we get cries of "why did you make such a big change, now you're holding up the freeze!" We were going to have FHS compliance for slink. We were also thinking about PAM. These have now been pushed back to potato. Are they going to get pushed back to woody [0], too? Cheers, aj [0] Or whatever. -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. ``Like the ski resort of girls looking for husbands and husbands looking for girls, the situation is not as symmetrical as it might seem.''
Attachment:
pgpB58FSc9XtI.pgp
Description: PGP signature