Re: potato late, goals for woody (IMHO)
On 2000-05-06 at 11:49 +0200, Robert Bihlmeyer wrote:
> You're contradicting yourself. Since almost all projects we're
> depending on don't have hard schedules, we can't at the same time have
> hard schedules and release right after a significantly new version of
> xyz comes out.
That's true, but I was not suggesting that. Really, what I had in mind
was that the release cycle should have a rough target schedule largely
independent of external factors, such as every six months, but that this
could be tweaked a little to avoid awkward external interactions. For
example, if you have a reasonable expectation that there will be a major
kernel upgrade along the lines of 2.2.x to 2.4.x, then it would be foolish
to ignore this if delaying a month would let you get the new kernel in and
tested. This same reasoning process would logically apply to anything
else which consensus holds to be of pervasive or defining significance to
users, such as glibc or XFree or Apache. Also, as I pointed out, cutting
the time between releases would make the effect of something missing a
release much less damaging. The actual decisions would have to be made on
a case-by-case basis: personally, I might wait an extra month to get in a
major new kernel upgrade, but not an extra two months. The standard would
be common sense and consensus, but the target schedule would be a goal.
> > If we say now that we are going to target a freeze of woody about three
> > months after the release of potato, and then a release of woody three more
> > months after the freeze, then everyone can plan accordingly.
>
> Of course. But nobody can make the guarantee that these schedules will
> hold. If the deadline slips, will developers get kicked? Remember that
> these are volunteers, and Debian usually plays second fiddle to real
> life concerns.
Debian was managing a six-month release cycle some years ago. Obviously,
it is not fair to developers to "kick" them for missing deadlines, but it
is also not fair to the project if they do. If the approach I suggested
is tried and it doesn't work, then I guess something else will have to be
tried. But the present situation, where there are no real deadlines and
therefore there are resulting difficulties with long-term planning, is
self-defeating and unworkable.
I think it is reasonable to give developers three months or so to
integrate new packages and then three months more to squash bugs toward a
release. If people really cannot work within a three-month window because
of limitations of "real life," then I doubt that giving them a six-month
or even a twelve-month window is going to help the situation. Debian
developers are not employees to be managed, but there is a vast difference
between "We need this by Tuesday" and "We need this by October."
-- Mike
Reply to: