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

Re: Questions to all candidates: Release importance, release blockers, release quality


I'm mostly in agreement with what Wouter expressed so I'll simply point
out what's different for me.

On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> On Mon, Feb 26, 2007 at 12:16:21PM +0100, Marc 'HE' Brockschmidt wrote:
> > * How important are regular releases for the project?
> Very. Individual people may be happy with testing or unstable, but large
> corporate users need stable releases in order to be able to use Debian.


> > * How important are regular stable point releases for the project?
> They are also important, albeit perhaps not as important as regular
> stable releases. What they provide is the convenience of having security
> updates all in place, and they have especial value for modem users.

Ack but they could become more important if we manage to provide newer kernels
once in the life cycle for example. I know several people plan to do that
for etch and I would like to give them my support.

> > * Should we fix up dak to allow point-releases for old-stable?
> No, I don't think that is very useful. Oldstable is there to allow
> people to transition to the current stable while not losing security
> support. It should not be used for new installations; and since I think
> the main advantage which stable point releases bring is convenience on
> new installations, there is no point in doing point-releases for
> oldstable.


> > * Could you list the issues that you think delayed the release of etch?
> >   Do you think that we need to restructure the release process for lenny
> >   to avoid these? If yes, how?
> I did not follow the release process closely enough to properly answer
> this. I hear the main reasons were the lack of a decent enough kernel,
> but do not know any details.

Obviously we also freezed later than expected. The kernel was a big
blocker this year but we also didn't reduce the RC bug count soon enough.

But I have no magic solution except "recruit more volunteers to keep more
packages bug free". And for this we need to be a more welcoming project.

> > * Do you think that a release of high quality is more important than a
> >   timely release? [ie: Should we switch from "when it's ready" to "when
> >   we said we would release"]
> I think both are of equal importance. Debian should not switch to
> time-based releases; however, having a general timeframe as we have done
> for etch certainly is helpful.


> It would be interesting if we could find ways to get lenny released at a
> point which is lying closer to the predicted date than will be the case
> for etch. However, we should not do this at all cost.

If we can aim to release every 18 months and effectively release every 22
months, it's ok. Nobody ask us a 100% predictable release. But I discussed
with important users of Debian and when they plan major deployment far
ahead of time then want to know which version is likely to be stable a
given future date. Those kind of projects can be late of a few months, but
they can't be late of a full year.

> That being said, I don't think any of this is the DPL's responsibility;
> the responsibility lies with our Release Managers.

Half-ack. The DPL should be in close contact with the release manager to
help them achieve one of the most important goal of the project.

Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :

Reply to: