On Sat, Mar 01, 2003 at 07:37:57AM +1000, Anthony Towns wrote: > > One release per quarter: Do you do security support for 4 versions in > > parallel, or do you require people to update 4 times per year? > > Four times a year? You realise that means we'd have already had two releases > since woody (end of October, end of January), and be almost halfway through > preparing for another one. The FreeBSD quarterly releases are nowhere near as heavy as our occasional releases. They're bigger than our revisions, but they still only do one really major release a year, if that. I think we could do something similar where maybe standard and essential packages get nothing but bugfixes, while optional and extra can get new features. Some guidelines would have to be developed to insure that nothing incredibly disruptive is changed during a minor release, but that's certainly possible. > You realise that we haven't had a releasable libc in unstable since > around August? So we wouldn't have a new libc in our next revision. No big deal. The one in woody is just fine. > Annual releases are an optimistic but probably achievable goal at > this point. A release every six months is stretching the bounds of > believability (sarge would be five weeks old and we'd be preparing its > first point release now if that were the case), but maybe not completely > breaking them. Quarterly releases aren't even remotely realistic. OK. I'll grant that. The FreeBSD core system (where the QA focus is) is really small, and there's far less QA done in the ports section. I certainly don't want us to release low quality packages. So how about this: We change the restrictions for what can get into a revision release. Or maybe we create a third type of release (call it a "minor" release for these purposes). If a package maintainer can justify to somebody (the QA people? An as yet undelegated group?) that a package offers useful changes and is minimally disruptive, then it is eligible for inclusion in a minor release. > For comparison, the freeze for hamm was about six months, for slink > four months and for potato seven months. The woody release was stalled > pending the security infrastructure work for almost an entire quarter. Those were all "major" releases, so I think that most of the QA and bugfixing that went into them could be carried through into a minor release, thus allow for a much shorter QA/bugfix period. It makes sense a freeze for a major release is longer, since more stuff changes. > Speeding up this stuff is a great idea, but the only way it's going to > happen is if people spend their time fixing bugs and doing development > work, not yammering to each other on mailing lists. I don't entirely agree with that. I think we need to make philosophical changes, in addition to technical changes, in order to speed our release cycle. I don't claim to have all the answers, but I certainly want to help find them. noah -- _______________________________________________________ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html
Attachment:
pgpJrL4Ftwpw8.pgp
Description: PGP signature