Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 05:27:26PM -0500, Ben Collins wrote:
> Well, it's really sad that you like to dredge up year old context for
> this thread to suit your mundane arguments, they have little context
> with what I was saying.
actually, it's really sad that you haven't learnt that closing down
'unstable' is a disastrously bad idea. you've been with debian long
enough now to have learnt that.
> > 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.
>
> Once can argue that the reason is because they don't know how they can
> help.
one could argue that, but one would be wrong.
> Everyone within Debian has a stake in frozen, simply by being a
> member, and every can help. There is nothing preventing that.
sure, everyone can help (but that doesn't necessarily mean that the
freeze/release process will go faster...in fact, for some tasks it is
guaranteed to slow it down). however, there is no reason to require
everyone to help or even to care very much about frozen/stable.
> > 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.
>
> First of all, you need to check your numbers. Last I checked there were
> ~350 official developers in the keyring.
last i checked we were approaching 500. irrelevant, anyway. 350 or 500,
it's still more than enough to prove my point.
> Right, so this proves my point in that we should encourage developers
> to put a priority on frozen and the next release cycle.
no, it doesn't prove it at all. adding many more people to the task
of getting the stable release out the door will not speed it up - if
anything, it will slow it down.
> And please stop refering to stable. That is not my main concern here,
> and I never brought it into this conversation.
do you have some kind of comprehension problem with the english
language? my references to the 'stable release' are obviously referring
to the work that needs to be done to get potato released.
> > 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.
>
> How would that help? That is simply a superficial thing.
>
> Calling it a "seperate project" would do nothing to improve the
> situation.
it is far from superficial. co-ordinating the activities of a small
group of 10-30 (estimated) people is a lot easier and a lot more
efficient than co-ordinating the activities of 300 or 500 people.
by "forking" the release as a sub-project, and granting complete
authority and responsibility to those who give enough of a damn to join
the release team, you can minimise the delays and interruptions caused
by the vast majority of developers who work on unstable yet have little
or nothing to contribute to the release process.
> Plus that creates havoc with changes made to the frozen release that
> aren't in unstable. So we get split bug reports and a lot of other
> crazy things.
that's something for the release team to worry about - after all,
they're the ones who are going to face the problems caused when it comes
time to do the next freeze/release.
i.e. there will be an inherent sanity-check on their changes, caused by
their desire to make future versions as easy to produce as possible.
> > 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.
>
> Ok, let's play word games. "Man-hours" is a direct result of "man-power".
no it is not. more precisely, the relationship is nowhere near as simple
as what you are trying to make out. does it just suit your argument to
play dumb or what?
the following should be elementary knowledge, especially to anyone in
the computer industry (who should have at least superficial knowledge of
the ideas in the _The Mythical Man Month_ by Frederick Brooks), but you
appear to need to have it pointed out:
having 10 times as many people does not mean you get 10 times as much
work done or even the same job done in 1/10th the time. e.g. if 1 person
can dig a hole in 10 minutes, having 10 people work on it does not mean
that you can dig the same hole in 1 minute. in fact, most likely that
same hole will take at least 20 or 30 minutes due to the hassle of
organising everyone and, even worse, everyone getting in each other's
way and interfering with their work.
> Everyone in Debian only has but so many hours than can put into the
> project, so increasing each developers time in the project is not an
> option. So we encourage developers to spend their time that they have to
> projects for the next stable release.
so how many people can work on the one problem (say, the boot-floppies)
at the same time? it *might* go faster if there were 2 or 3 people
working on it rather than just one, but it would *certainly* go a lot
slower if there were 20 or 30 or 300 people working on it.
> > it doesn't distract me at all. i mostly ignore it these days as it is of
> > little or no relevance to me.
>
> Safe to say, that is a really self-centered attitude. One which I hope
> that most developers don't have. Not a very team oriented situation if
> everyone felt that way.
no, it's not entirely self-centred. you miss the significant point that
in my experience (and in the experience of many other debian developers
and users), debian "unstable" is significantly better for daily use than
debian "stable". the obvious conclusion to be made from this experience
is that all debian users would be better off if debian unstable were
more readily available to them.
in other words, focusing exclusively on making a stable release is
irrelevant...we (and our users) would be far better off if we made
regular untested snapshot releases. at least then most of our users
wouldn't be 12 or 18 or 24 months behind, running obsolete software with
known bugs and known security holes.
> > 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
> > arbitrary falsehood.
> >
> > 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
> > date.
> >
> > 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
> > images.
>
> Another sad situation. Sad because you feel that it is better to forget
> the harder situations, and simply deal with the ease of unstable.
again, don't put words in my mouth.
what i said was that i want to see the real debian (aka "unstable")
become more accesible to the majority of our users. the way to do this
is by making regular snapshot releases.
for many of us - both users and developers - debian "stable" or "frozen"
is about as relevant as whatever RedHat's latest release is (or SUSE
or Caldera or whatever). we don't use it and, by the time any freeze
becomes stable, we haven't used it for at least 6 months.
> I'm glad you find it so easy to shove off the important work and leave
> your self in the midst of easier things like uploading to unstable
> whenever a new version of your package comes out. Everyone knows how
> hard it is to help with RC bugs and documentation, or test installs
> and file bugs. Who would want to do all that crap when you can stick
> with unstable where no one bothers you and your packages?
obviously, you would. and many other people. hopefully enough to make a
release. that's great - you're doing important and useful work.
if it turned out that not enough people would want to, then it wouldn't
be such a big deal...it would be an honest reflection of the project
members' interests.
if that pisses off some users then they are free to join the project and
work on the stable release alongside such diligent and dedicated workers
as yourself.
my bet, though, is that most users wouldn't care very much if snapshot
CDs were available. "unstable" works extremely well for many people,
and most people prefer reasonably up-to-date software over obsolete
software...especially if they don't have to spend hours or days
downloading it.
the simple fact is that no matter what we do, any 'stable' release is
going to be old. that is unavoidable. the absolute minimum time between
a freeze and the stable release is going to be 3 months....in practice,
it's going to be at least 6 months.
6 months (and even 3 months) is a long time on the internet, a long time
in the free software world.
the package pools idea will allow us to easily make snapshots to
cater for the vast majority of debian users, i.e. those who are
somewhere between the bleeding-edgers and the ultra-conservative users
of 'stable'. snapshots could be made by automatically picking all
'unstable' packages which have existed in the pool for, say, 14 days
without any serious bugs reported against them. this capability has been
touted as one of the advantages of the package pools ideas every time it
has come up over the last few years.
there have been many discussions about possible criteria for "promoting"
incoming packages from unstable to frozen to stable - e.g. automatic
after X days, automatic with veto, or even requiring packages to be
"endorsed" by vote. read the list archives for details.
> I never said that we should force people to work on unstable. My
> exact proposal was to not fork unstable at freeze, and instead wait
> till deep freeze (not release as you suggest). No one has to work
> during this time, they can do nothing if they don't want to help with
> frozen. So in a way, it is more like "if you want to work, frozen is
> the place to do it". With our current frozen cycle that means you
> either upload bug fixes (even minor ones, and a lot of times, new
> versions justify as a bug fix), or you don't do anything. The only
> thing you can't do is upload "new" packages.
your proposal, quite frankly, stinks. your position is that if people
won't or can't work on what YOU consider to be important then you don't
want them to work on anything at all...they should just twiddle their
thumbs and wait for 'stable' to be released before they are allowed to
contribute anything.
> Very sad that you wont be able to add another ICQ client to the +4000
> packages in the distribution already. Sorry for suggesting that.
if uploading a new icq client is all that someone can do, then what is
wrong with that? how does it hurt the release cycle for someone to work
on 'unstable' if the alternative is that they would not work on anything
at all?
if YOU don't want to work on unstable while the freeze is in progress
then that's fine, that's entirely your choice. leave others to make
their own choices and donate their own time and energy as they see fit.
> Heh, that's a pretty idealistic view. I think you misunderstand the
> usage of package pools. They are meant to give better seperation than
> out current "stable", "frozen", "unstable" distribution and allow for
> tagged package sets.
i am not limited by your short-sightedness. if you cannot see that
implementation of the package pools idea would greatly ease the
automated production of snapshot releases then that is your problem.
> They are not for "snapshots" like a CVS repository,
wrong. automating the production of snapshots has always been regarded
as one of the advantages of the various package pools ideas.
> which would do nothing to increase stability.
will you quit it with the bullshit that "unstable" is less stable than
"stable"? it's not. in fact, over time it is vastly more stable and
secure than the so-called 'stable' release.
the name "unstable" does not mean that it is unreliable or flaky. it
means that it is subject to rapid change, and that some of those changes
will (temporarily) cause incompatibilities or problems. caveat emptor.
similarly, "stable" does not mean that it is guaranteed to work or to
be bug-free. it means that it has been tested reasonably thoroughly and
that as far as we can tell, it works as an integrated system on a wide
variety of machines. caveat emptor.
> Using snapshots of unstable is no different than using unstable
> itself, which is what we have now.
duh!! i'm really glad you spotted that. i'm getting a bit tired of
pointing out the obvious.
yes, a snapshot release would be no different to unstable.
the sole reason for snapshot release is that the snapshot CD images
would be available to many more people - i.e. everyone who doesn't have
access to a fast, cheap net connection. they can pay someone to burn a
set for them, or burn a set at work or uni to take home (and possible
share with friends or linux club members), or they can pay a couple
of bucks per CD to one of the cheap CD houses like cheapbytes or lsl.
ideally, they would be able to subscribe to a snapshot service and have
them automatically shipped to them every month or quarter or whatever.
in other words, it would extend the benefits of debian 'unstable' to
most of our users, not just those with a fast net connection.
> > 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.
>
> Actually, I care about putting out a stable release. You seem to worry
> more about your own interests as opposed to the projects'.
your interests are NOT the project's interests. they are a subset of
debian's interests. my interests/preferences/priorities are at least as
much the "project's interests" as yours are.
the debian project is more than big enough to support a diversity of
interests. it is not an either/or proposition, it is perfectly possible
for debian to have frequent snapshots of 'unstable' PLUS less frequent
tested 'stable' releases.
> Please let me say again, I am really glad that this is not the general
> attitude from Debian developers. My concerns, and the concerns of
> anyone who decides to put time into Debian, should be the ones stated
> in our Social Contract:
>
> 4. Our Priorities are Our Users and Free Software
>
> We will be guided by the needs of our users and the free-software
> community. We will place their interests first in our priorities. We
> will support the needs of our users for operation in many different
> kinds of computing environment. We won't object to commercial software
> that is intended to run on Debian systems, and we'll allow others to
> create value-added distributions containing both Debian and commercial
> software, without any fee from us. To support these goals, we will
> provide an integrated system of high-quality, 100% free software, with
> no legal restrictions that would prevent these kinds of use.
>
> Didn't you have to agree to this to become a developer in the first place?
[yawn. such cheap shots are easily demolished.]
no, i didn't. that was written long after i joined debian.
i was one of the people who wrote the social contract and the DFSG. i
fully agree with them. i did then when we were writing them, and i still
do now.
i disagree with your narrow interpretation of what our "users'
interests" are. i believe our users' interests are best served by
working on 'unstable' AND making unstable readily available to everyone
through cheap snapshot CDs, rather than only being available to those
with fast & cheap net connections.
> IMO, getting out a stable distribution meets these goals. Ignoring
> frozen does not.
if you want to work on frozen, then good. it's a useful goal.
don't expect everyone to work on the same stuff you want to work on.
always keep in mind that this is the Debian Project, *not* Ben's Project.
craig
--
craig sanders
Reply to: