[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release management



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: pgp8p6OaRti8v.pgp
Description: PGP signature


Reply to: