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

Re: Granual release proposal



Eduard Bloch <edi@gmx.de> writes:

> #include <hallo.h>
> Aaron Isotton wrote on Fri May 24, 2002 um 03:48:26PM:
> 
> > 
> > If you divide Debian into many sections which are upgraded more or
> > less independently you don't have *a* new distribution, you have
> > dozens. I don't see what a new 'rc' branch would be good for; isn't
> > testing supposed to be used for what you said?
> 
> You do not understand. There won't be a dozen of distributions, there
> will be one stable series of packages. This would be a mixture of
> sections that were tested and became stable in their own.

I understand perfectly. But *now* there are exactly three
distributions: unstable, testing and stable. Dividing Debian into
sections that number will increase. Suppose some package not belonging
to 'sound' uses the sound architecture, and that between 'stable' and
'testing' of the sound section there is some major difference (like a
new version, or whatever). I suppose the package maintainer would have
to test his package against both sound sections. If a package has
three or four such dependencies the testing becomes longer and longer.

> 
> > Too many branches also increase the time it takes for a package to get
> > to stable.
> 
> Once again, there WOULD NOT be THE set of packages called "stable" that
> won't be changed until the whole thing is released. Once a section has
> passed it's internal testing period (in "testing" tree), the packages
> are moved to "working". When they did really work without
> release-critical problems in that "working" three, they are moved to
> "stable" and we have a new Stable subrelease: 3.1, 3.2, 3.3 etc. (Note
> that I would really use the second number for that purpose - with the
> speed of Woody release, we would have Debian 9 not before 2010.)

I still don't see the need for a 'working' branch. Before having
passed preliminary testing a package goes into unstable. Then it moves
into testing where it has to prove to be stable. Then it goes into
stable. In any case the number of branches is not sooo relevant,
IMHO. I just think that the less bureaucracy (sic?) is needed for
moving the packages around the better it is.

> 
> > > Keep dreaming. We need a real unstable tree to test new stuff. You
> > > cannot cook on small flame for long time.
> > 
> > Too big flames tend to burn things. If unstable were really unstable
> > only few people would use it, and many bugs would move straight into
> > testing.
> 
> He, I did not propose anything that would break the current
> bug-filtering scheme.

I don't understand what you mean. Maybe I was not clear enough. What I
mean is this:

If unstable is "really unstable", it will of course not work
reliably. Nobody wants to use an unreliable OS; there is Windows for
that. Thus it is good to keep unstable stable enough to be usable for
day-to-day tasks, even if not for a server or something like
that. That way there will be some real users and not only some
developers checking with pbuilder whether their packages build nicely
under unstable.

Aaron


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: