Re: speeding up the release cycle (was Re: Debian's problems)
I suggested a similar system a while back on IRC, and I think on -devel. Mine
was propogating packages right the way down to "stable", though. The problem
that was pointed out with my idea was that developers would feel they had to
maintain multiple versions of packages, separate to each other.
With the current system, whereby no new features may be introduced to frozen,
this _may_ be unworkable - and developers may end up maintaining multiple
versions of packages. This is especially true if the package is a library or
some-such, required by other packages.
The clear distinction of "unstable" is good in that major change can take
place, and people expect it, and thus handle it well. (err.. well, they handle
Right now, I'm thinking along the lines of having debians base system handled
as it is - making sure all developers involved with that are responsive and
get things done.. and for applications, etc. have a scheme like yours.
On Mon, Sep 13, 1999 at 11:55:36AM +0200, Jens Ritter wrote:
> There have been various proposals to speed up the release cycle.
> Maybe something like this could work:
> We could have a frozen branch in the archive all the time.
> A package can only get there, if
> a) the maintainer uploads a known good version to it (by tagging it
> for frozen) and
> b) the package does not have a release critical bug against it.
> If a release critical bug is opened, the package will be removed and
> cannot get back there without a testing period (?). Maybe some checks
> must be passed before a package gets in (?).
> If the developers are as cautious to upload there as they are to
> stable, this will yield a frozen of high quality and will make the release
> process easier:
> 1) There is always a release candidate.
> 2) We always see how far it is.
> 3) Great transitions are easier to manage.
> 4) Known bad packages do not have to be removed.
> 5) This will set the "goal" for all package maintainers.