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

Re: Debian Roadmap

On Thu, Nov 20, 2003 at 10:55:00AM -0500, Ben Collins wrote:
> You're asking a loose nit group of some 1000+ volunteers who work
> independently to produce a "road map"? That's not very likely. Even if
> such a document were produced, it's no guarantee that we'll follow it,
> since each item would require someone willing to do the work.

A roadmap is no more difficult or abstract a concept to follow than a
"release".  The only reason we are able to release a version of Debian
is that we have somebody who has been officially granted the ability to
declare a bundle of code to be in a "released" state.  If we were truly
so loose-knit and independed that we could not produce or follow even a
relatively vague roadmap leading to a release, surely we can't claim to
have reached the goal a release.

> Debian hardly has release goals, and even those goals depend not only on
> individual developers with no forcible guidelines, they depend on
> outside groups like Xfree86, GCC, GNU/Libc, and the kernel developers.
> There's just no way to put down what will be done.

I don't believe that to be the case.  There are some relatively easily
identifiable areas that help to define when we are ready for a release.
Some of these are directly within the control of Debian developers (e.g.
debconf, debian-installer, etc) while others are not (packages from
upstream sources).  At the beginning of a release cycle, I think it is
entirely reasonable that maintainers of packages like glibc, the kernel
related packages, gcc, Xfree86, and some other important packages submit
to the release manager a plan for the next 6 to 9 months or whatever.
Something along the lines of "glibc 2.5 is likely to be released 6
months from now, and I believe that getting it into our next release is
a reasonable goal".  We then have some metric.  It very well may be that
we have to rethink our roadmap, perhaps reconsidering either the time
frame or the goal itself, but at least we have some objective

The obvious objection to my claim will be, "But who gets to decide what
constitutes an 'important' subsystem?"  Well, who gets to decide when a
release is ready for the "stable" label?  Somebody who has been
appointed to that position.  It's not unreasonable that the release
manager's duties be extended to fill this roll, but perhaps it's more
work than they're able to take on.  In that case, perhaps another
position could be created to perform these duties.  Obviously this
person would have to work closely with the release manager, but I
believe it could be done effectively without placing any significant new
burdens on him.


Attachment: pgpvS73YHtbGa.pgp
Description: PGP signature

Reply to: