Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 09:23:42PM -0600, Steve Greenland wrote:
> 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.
because if developers had to wait 12 or 18 months to get their new stuff
into debian then there would be very few developers who would bother.
that constitutes a disaster. it would be the death of debian.
> > 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.
i am glad you recognise that it is only *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.
i do not disagree with debian's goals. if i did then i wouldn't be here.
> > 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?
i don't insist that at all. quite the contrary, i insist that they
continue to contribute in whatever way they see fit, including the
option of uploading new stuff to unstable.
> They can test installs, they can fix bugs, they can improve docs.
not everyone has the time, patience, inclination, skills, desire or
whatever to do these things.
if somebody wants to work on these things, then that's fine.
if somebody wants to work on unstable, where is the problem?
> > 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.
wrong. they take on the responsibility for the RELEASE. if that means
that they feel they have to make a change to somebody else's package
then so be it, they should have the right to do so. delegate complete
authority to the release team to do whatever they feel is necessary to
produce a high-quality release version of debian.
if the maintainer of a changed package agrees with their decision then
they will incorporate the changes into their version of the package. if
not, then there is a dispute which will eventually need to be resolved.
big deal, shit happens, deal with it on a case-by-case basis.
> 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;
that might happen in a tiny minority of cases, but it's hardly likely to
be the normal case.
there's no need to paint it in such black & white terms, either. there
are legitimate grounds for a package maintainer to disagree with the
release team, without wearing those insulting labels.
> after all, it's "something for the release team to worry about".
if the maintainers and the release team are doing their job properly
then this will rarely be a problem. in the few cases where it does
become a problem then we deal with it in the usual way - have a
discussion or flamewar on debian-devel and eventually reach consensus
(or at least, adapt policy so that the current ambiguity is resolved)
> 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!
testing packages is not the only delay in the release cycle. for
example, the boot floppies were a significant delay this time around.
that's not surprising at all, they usually are...there's a lot of new
development and a lot of work in making sure all the new base packages
and new kernel work properly as an install set.
even if everything in the freeze/release cycle were perfectly
parallelizable, that would still be no justification for closing off
unstable. not everyone has the ability or the desire to contribute to
frozen - they should be allowed to contribute to unstable as they always
have been.
> > 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.
ultimately, snapshot releases will even speed up the freeze->stable part
of the release cycle as packages will be tested more thoroughly.
more packages would be tested by more people on a much wider variety of
systems if they were available in snapshot CD images for a few months
before the freeze.
> But no, you'd rather they uploaded yet another clock tool.
DO NOT PUT WORDS IN MY MOUTH.
your "argument" for want of a better term is obviously so poor that you
have no choice but to misrepresent mine to make your "points".
i would rather that people uploaded new and/or upgraded packages of
whatever they feel like working on, rather than sit idle and do nothing
while frozen is being worked on. i.e. business as usual.
> > 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.
so why do you have a problem with infrastructure (i.e. package pools in
one form or another) which makes it easier to build a snapshot image?
do you have some kind of aversion to automating tedious and
time-consuming tasks?
> > 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.
and fuck you too! how dare you fucking misrepresent my position and
twist what i said in such a reprehensible manner?
if you don't fucking understand what i'm saying then shut the fuck up.
> 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.
we have something good and valuable. debian unstable is that, all by
itself - and vastly better than RH.
debian is not ONLY the stable release. debian is much better and bigger
than just that.
> > 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.
at any given instant, it usually is perfectly stable and safe.
the times when it has been unsafe constitute a tiny fraction of its
existence.
> > 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.
no, that does not make 'unstable' unreliable or flaky. it is just a
fact that you must be aware of, a risk that you can choose to take
or not...one of the many factors that will influence the decision to
upgrade or not.
> Craig, your definitions must be completely different than mine. I
> thank ghod you don't manage any of my production systems.
are you not capable of figuring out that *all* upgrades need to be
tested on unimportant machines before being performed on important ones?
if so, then i'm glad that you're nowhere near any of mine.
anyone who keeps their production servers in sync with 'unstable' knows
that - or ought to know that. test the upgrade on a workstation or some
other unimportant machine first.
pre-testing upgrades is essential whether you are upgrading to the
latest stable release or upgrading to whatever happens to be in stable
right now/.
this kind of testing is (or should be) standard operating procedure for
ANY major change to any system.
> > 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".
that "could completely hose your system" promise is STILL there with
stable, just as much as it is with unstable...it's just a little less
obvious. we do not guarantee quality with stable, any more than we
guarantee it with unstable.
craig
ps: i really can't figure out what the fuck you're arguing about. nobody
has suggested that we not work on frozen and produce a stable release.
this sub-thread started because BenC made his usual comments implying
that debian unstable should be closed during the freeze, or that nobody
should be working on unstable. i disputed that because it is a severely
brain-damaged idea.
--
craig sanders
Reply to: