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

Re: so what? Re: Debian development modem

On Mon, Jun 08, 1998 at 01:22:26PM +0100, Ian Jackson wrote:
> We must decouple our development tracks much more.  I propose that we
> resolve never again to plan a release with is not fully backward
> compatible with the current stable version.

Agreed!  Those of us who have been talking about possible suggestions for
changing the way releases are handled all seem to agree that changes should
be phased in.

> We should abandon the idea of `release goals'.  Instead, if someone
> thinks a thing definitely needs doing by the time of a release, they
> do it.  If it doesn't get done then we release anyway.

I don't see anything MAJOR in the plans for 2.1 that could not be done this
way.  It seems though like a good plan.

> So, in detail:
> Every three months (fixed date) we copy the current `unstable' into
> `frozen'.  At this point `stable', `frozen' and `unstable' should all
> stay interoperable both in source and binary form.

This still doesn't address the problem of packages that really aren't ready
to be released.  That's kinda why we were suggesting unstable be a pool for
packages in development.  If they're ready for release, move them to frozen. 
That way nobody's package is being "left out" of a dist because of a bug,
but rather being moved into a release after a fair amount of time if the
package is ready in the author's opinions.  (I was suggesting the bug system
be used as part of that since the authors have control over the priority of
the bugs against their packages)

> Bugfixes must be applied to frozen, and important ones to stable too.
> After one or two months of beta frozen should be stable enough to
> release.

Is this not how things are done wrt frozen and to stable now?

> If it's not fine with you then let's not hold up the releases -
> instead, go and fix those packages.

This is the biggest reason for Guy and co's suggestion about making unstable
a pool in which packages start and move out of--so no package can hold up a
release.  If the author believes the current version of a package is not yet
stable enough for release, the last stable version would be used.  This
requires that we don't break backward compatibility, but for all the other
reasons we had before we should keep things as compatible as possible

Attachment: pgpxluQvUFGFg.pgp
Description: PGP signature

Reply to: