Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On 14-Mar-00, 18:58 (CST), Craig Sanders <cas@taz.net.au> wrote:
> 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.
How do you know? We've never tried it. You and others say it would be a
disaster. I and others think it would help. Proof by assertion isn't.
> However, there is no reason to require everyone to help or even to
> care very much about frozen/stable.
Except that it is part of what Debian does. Joining the org implies at
least some interest in the goals. If you disagree with the goals, lobby
to change them.
> 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.
Why do you continue to insist that they can't contribute? They can test
installs, they can fix bugs, they can improve docs.
> 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.
Yeah, this release team should take on all responsibility for all the
other peoples packages. Beautiful. Never mind that the next freeze,
those problems *still* exist because the maintainer of the package
doesn't need to care about fixing bugs or following policy; after all,
it's "something for the release team to worry about".
> > > also, the issue is not "man-power", the issue is "man-hours" - i.e.
>
> 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.
Apparently you need to go back and read MMM again, and tCatB as well:
you missed the point that the reason that productivity does not vary
linearly with people has to do with how easily the tasks are done
in parrallel. 10 people *can* dig 10 holes 10 times as fast as 1
person. And what computing task *is* well done in parallel? Testing and
debugging. That's why the whole Bizzaar methodology works!
> 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 would go a hell of lot faster if 30 or 300 people would test the damn
things and report problems with their various hardware configurations,
and the choices/options they used in their particular install situation.
But no, you'd rather they uploaded yet another clock tool.
> 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.
There is nothing stopping anyone from making snapshot releases of
unstable. Mirror the archive. Burn a CD. Done. That's what a snapshot
is.
God forbid you make the snapshot on a day that perl is broken, of
course. Or dpkg. Or glibc. Damn unreliable Debian PoS.
I think you have a very narrow idea of what "most users" want.
> 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.
That's right, it has. If it's so important, why haven't people (you!)
gotten off your ass and done something about it? If you want to work on
the unstable stuff, I think the package-pool implementation would good
place to start.
> 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.
Your attitude, quite frankly, stinks. Your position is that that once
you've uploaded a package, you have nothing else to contribute to the
project. Instead, other people should babysit your packages to make
them work with the rest of the system.
Debian is supposed to be a team, a group of people working to create
something good and valuable. If we're not going to be that, we might as
well just the Red Hat contrib directory.
> > 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 they *really* feel the need to upload that icq client, and can't
until the release (or deep freeze), then they just might fix one (1)
release critical bug. Nobody is _forcing_ them to do it.
> 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.
Over time, yes. An any given instance in time, often not.
> 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.
Thus, unreliable and flaky. Craig, your definitions must be completely
different than mine. I thank ghod you don't manage any of my production
systems.
> 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.
That's a hell of lot stronger promise than "could completely hose your
system".
Steve
--
Steve Greenland <vmole@swbell.net>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Reply to: