On Sat, Jul 03, 1999 at 08:48:46PM +0200, Richard Braakman wrote: > Some issues of release management are being discussed again, so I thought > I'd speak up and give my views. > > What I would like to see is two releases per year, with a freeze time > of about one month each. This gives five months per release for > development, of which perhaps one month will be spent on pre-freeze > issues. <AOL>I agree</AOL> > What we have right now is releases that take about a year, with half > of that time spent in freeze. By the time we make a release, it is > almost outdated already. > > For potato, I'd be happy enough if we get a shorter freeze, even if > the total release time is not reduced. Once the freeze process is > under control, it should be easy to get faster releases. <AOL>I agree</AOL> > The main reason right now for not freezing is the large and rising > number of release-critical bugs. We're over 200 already, and the > number is going up rather than down. The boot-floppies also need > work. I would suggest refrigeration for the moment. Traditionally when we freeze we tell people not to upload new versions of software---not even new versions of stable software---unless important bugs are fixed by doing so. What I'd like to see is NEW software not being automatically accepted for potato. This to keep new packages from making it harder to get the bug count down. Hopefully this will help people concentrate on fixing bugs. > I have two plans for dealing with the release-critical bugs. > > The first is to contact each maintainer of such a package, and ask > what's up, and collect these reactions in the weekly report. This > approach has helped before, with the hamm release. Josip Rodin has > volunteered to do this :) > > The second is to go ahead and mark a number of packages as "will be > removed" if their bugs are not fixed before the freeze, and then > arrange for the weekly report to not count them, and list them in > a separate section. These are the packages that would have been > removed from frozen now, if we'd had an old-style freeze. This will > let us concentrate on bugs that will actually slow down the release > process. (Nothing stops you from rescuing a package by fixing its > bugs, of course.) Might I suggest a third? For an example of the problem, look at afterstep. Nice windowmanager. There are newer versions of it out there, new stable versions. The maintainer hasn't packaged them but has been promising he will for more than a month. The package is a nightmare. Lintian all but panics. The package conflicts with another package but doesn't declare its conflict (and in fact shouldn't conflict at all..) The new versions of menu don't even WORK with its dated menu format and the standards version on the package is I think 2.4.0. More still, it has a pile of release critical bugs against it. The package has come up before. The maintainer has not responded to any email on the subject. At this point if I don't hear from him soon, I'm figuring I'm not GOING TO hear from him. The waiting game is probably pretty much pointless at this point for afterstep. I could wait weeks and probably all I'd get out of it is "I'm working on it..." if I even get that much. Sure he's working on it. And IWJ is working on dpkg too right? In such cases developers should be able to NMU these packages without worrying about complaints of package hijacking. Although in the case of afterstep, hijacking it doesn't seem like such a bad idea... -- Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First! ------------------------------------------------------------------------- "Bruce McKinney, author of of Hardcore Visual Basic, has announced that he's fed up with VB and won't be writing a 3rd edition of his book. The best quote is at the end: 'I don't need a language designed by a focus group'."
Attachment:
pgp9IgdKO5ljE.pgp
Description: PGP signature