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

Re: A "progressive" distribution



I really don't think that a "progressive" branch is necessary.  The
problems involved in keeping track of three branches at one time and
trying to keep version dependencies in order between branches would far
out weigh any benefit that would be created by such a branch.  IMHO the
structure (stable, frozen, unstable) is more than adequate.

The problem that I see is that there is too much time between stable
releases.  I think that shorter and much more regular time periods
between freezes is necessary.  By fixing the number and date of freezes,
with say three or four a year, and letting everyone know long in advance
of the freeze it would allow developers to schedule when all bugs must
be removed by.  Also the fact that the time period would be much shorter
would make changes between stable versions less drastic and therefore
easier to handle.

Ed

"Bernhard R. Link" wrote:
> 
> After reading this nice diskussion with all it's aspects, I want to
> complete the mess and suggest a "distribution" called
> e.g. "progressive" beetween stable(frozen) and unstable.
> 
> As I understood the problem, at the moment, only the stable
> distribution is able to be distributed, while the unstable branch is to
> unstable and there's no distrubution in between. (To simplify I count the
> frozen as stable short before release here.)
> 
> When potate becomes stable, a branch called e.g. "progressive" could be
> created between the branches "stable" and "unstable". This branch (sorry
> for using this term, but I don't like distribution so much) would start
> with the modules from stable and subsets of unstable would be added, if
> they are usable. The term subset I use for  packages that contain together
> like one ore more basis packages (libc,xfree,perl,... or just something
> like emacs) and those packages depending on this basis package. (Note that
> I mean basis as basis of dependencies not basis of the whole or larger
> parts of distribution)  And usable shell mean, that this package can be
> used for average use without the need of Debian-like-tability.
> 
> With the next freeze, this "progressive" branch could be copied to
> "froozen" and new useable packaged from unstable would go to
> "progressive", while those in frozen are kept and only made more
> stable.
> 
> Doing this there would be a distribution in between, where new versions of
> products can reside and easily be used. Someone should be easily use a
> snapshot of progressive at an good moment to form a not-so-stable but
> up-to-date unofficial release, which could also be called less inoffical,
> if there is a common will for this.
> 
> Though some advantages this would cause at least two problems:
> 
> On the one hand this proposal would prohibit the current way of
> naming, because with any release a new distribution is created beetween
> stable and unstable, so some branch would change name and the old name
> would be used for a possibly totally other branch. So unstable( and
> perhaps progressive) had to be without name and just be "unstable".
> This coresponds to the loss of a cycle for the whole
> distribution. Changes would start in unstable and go through the phases of
> unstable, progessive and froozen before they become stable.
> 
> On the other hand would this proposal multiply the number of branches to
> up to four when there will be the next freeze and
> stable,frozen,progressive and unstable beeing all together. This made me
> the most headacke, but I think it's not so much of a problem, as many work
> to make the frozen version of his package will seriously prevent him from
> working so much on the unstable version, that this could become
> "usable". So most packages would be either the same in frozen and
> progressive or they would be same in progressive and unstable.
> 
> Hochachtungsvoll,
>   Bernhard R. Link
> 
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: