Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 09:02:50AM -0500, Ben Collins wrote:
> On Tue, Mar 14, 2000 at 10:01:15PM +1100, Craig Sanders wrote:
> > On Mon, Mar 13, 2000 at 09:08:43AM -0500, Ben Collins wrote:
> > > We are knee deep in a release cycle. We should not be expending our
> > > resources on woody right now.
> > speak for yourself. not everyone in debian has your priorities. more to
> > the point, your priorities are not the only valid ones.
> > many people can (and ARE!) contribute a lot to woody, without impacting
> > on frozen in the slightest.
> Direct impact yes, indirectly though, we are short on needed resources for
> getting potato release ready.
you miss two important points. the first is that the release is not
everyone's highest priority. the second is that some people have nothing
to contribute to frozen/stable, so discouraging (or preventing) them
from working on unstable is counterproductive.
both of these points are proved by the fact that we have over 500
developers yet, according to your own words, "we are short on needed
resources for getting potato release ready". if everyone, or the
majority...or even a substantial minority, had your priorities then that
would not be the case.
in any case, simply adding more people to the project won't make it
happen any faster. what WILL make it faster is to fork off the stable
release as a sub-project of debian, and give the release team absolute
authority over the release, with the right to make NMUs of any package
and make any other changes for any reason they see fit. as with any
other debian initiative, any developer (or user) would be free to work
on it or not as they please.
also, the issue is not "man-power", the issue is "man-hours" - i.e.
how much time any of the people doing the important jobs can devote to
debian. most of them have full-time jobs or are full-time students and
are working on debian in their spare time. the really imporant tasks
can't be sped up by some kind of time-sharing arrangement.
> > then "fork" the stable release so that those who want to focus on it
> > exclusively can do so without being distracted by those attracted by
> > the shiny new toys...and those who want to work on new stuff don't
> > have to be distracted by the test & freezing cycle. and some people
> > will happily work on both.
> Sorry that getting the next stable release out the door is such a
> distraction. I'll try to see if there is some way we can keep this
> messy part of Debian out of your way.
it doesn't distract me at all. i mostly ignore it these days as it is of
little or no relevance to me.
like many others, i am perfectly happy with the real debian (i.e. the
"live" development version aka "unstable") as it has served my needs
extremely well on production servers and workstations for 5+ years.
in other words, empirical evidence over the years has shown that the
distinction between stable and unstable is not only irrelevant, it is an
this same empirical evidence has also proved that 'stable' is LESS
stable and reliable and secure than 'unstable'. the few debian boxes
which i know of that have been compromised were cracked BECAUSE they
were still running stable and had older versions of various programs
which had known security holes. the main reason they were still running
stable is because they didn't have fast, reliable internet connections -
i.e. if regular snapshot CDs were available, they would have been up to
i would like to see the real debian become more accessible to the
general public, and the way to do that is to make frequent snapshot CD
> I don't recall saying anything about forcing. Maybe you mistook
> "encourage" for "force".
no, i didn't. i simply put your current remarks in context with other
statements of yours in the past, where you have been an advocate of the
insane idea that unstable should be closed down between the freeze and
> Not my issue though, I still think we need to encourage people to work
> on frozen until it's completely out the door.
fine, keep on with the "encouragements". just keep the "should"s and
"should not"s in check. they are shrill and irritating.
> Package pools are not an end all and frequent snapshots and less
> frequent stable releases are only doable when we have people working
> on it.
one person can do a snapshot release in a day or so - that's the
point...it's an untested snapshot of unstable as it is at that moment in
time. use at your own risk, just like unstable....and just like 'stable'
- we don't after all, offer any guarantee for stable.
there's no need to even make new base/install disks for a snapshot
release - the old ones from the previous stable release will be
adequate...just install those and then upgrade to the snapshot.
the stable releases will, of course, still take time to test and to
produce new boot-floppies. however, that time will be reduced because
some of the testing will already have been done by people using the
> Since you think that encouraging people to work on it is not ok,
do NOT put words in my mouth.
> Any way, package pools wont come till after potato, since it is (and
> should be) still the first priority right now.
for you and some others, it is the first priority. for other people,
including myself, it is a vaguely interesting but still irrelevant
activity performed by those members of the debian project who care
enough about it to work on it.