Re: Updated status of GNOME in potato

[Chris Waters <xtifr@dsp.net>]

Michael Alan Dorman <mdorman@debian.org> writes:

> Chris Waters <xtifr@dsp.net> writes:
> > Debian stands for quality, not speed.

> Unfortunately, of late the Debian gnome packages have been neither
> good nor timely.

Not being good is a problem; not being timely is NOT!  They've been
neither good nor purple -- so let's paint them all purple!  Makes just
as much sense!  :-)

> For instance---and not to pick on anyone in any way, I don't even know
> who this involves, this is just what happened to occur to me as an
> illustration---more than a month ago, the maintainer of gdm uploaded a
> new version that simply didn't work, and then promptly disappeared.

Nothing to do with anything I said -- that was a problem with a) a
broken package, and b) a disappearing maintainer.  *Those* are the
sorts of things that we do NMUs for.  NOT the fact that the version in
the archive is a week or two out of date!  This example only goes to
prove MY point, insofar as it has *any* relevance to the discussion.
The package should not have been uploaded until it had been tested!

> Finally, I'm *not* proposing some dumbass rush to do a shit job just
> to say we did it.

Funny, that looks like EXACTLY what you're doing!

Personally, I *only* rush to update *broken* packages!  (Figuring that
not-quite-right is still better than completely-wrong.)

If the version in the archive is working, I will test a new version
for *as long* as it takes to satisfy me that it's *as good* as what
it's replacing.  You know why?  Because I *care* about our users, and
figure that it's better to leave them with something that is *known*
to work than it is to give them some up-to-the-bleeding-edge broken
just-released junk.

> I think achieving parity in a timely fashion for this significant
> milestone in GNOME development would be a nice gesture towards some of
> those pesky users we have to satisfy.

And how about the OTHER users?  The ones that want quality and
reliability?  Are we going to totally ignore them just because a
handful of whiners complain if we fall a week behind the latest
up-to-date untested crap?

> However, in that instance, you can expect me to do some NMUs of your
> packages because, *I* have decided, for this particular segment of the
> distribution, that I feel some responsibility to our users to make
> this happen in a timely fashion.

If you NMU my WORKING packages before *I'm* satisfied that the new
version is ready, I will simply re-upload the old version, with an
epoch if necessary.  Because *I* feel some responsibility to our users
to make sure that we have solid, reliable software for them.

People NEED software that works.  People DON'T need up-to-the-second
software -- they just want it (and only a few of them really care).
So don't lay this BS on me about how you care so much more for our
users than I do, because that's a complete crock!

Heck, most of the people that *I* know who are using Debian are using
Slink, and have no interest in upgrading until new CDs are available.
I even know one who got Bo, and is sticking with it until he gets a
new machine, on the "if-it-ain't-broke" principle.  Which pretty much
blows your whole "they need new packages the second they're available"
theory all to pot!

Now, if you want to complain about disappearing or inattentive
maintainers, that's fine, and very justifiable, and I'll support you
100%.  But two wrongs don't make a right: overzealous uploading is
just as bad as apathy!  It's like trying to fight heroin addiction by
giving out free amphetamines.  It doesn't work that way.  :-)

Once again, I say: Debian is about quality, not speed, and we should
take the time to do it right!  If you have any *relevent* comments,
I'd be more than glad to hear them, but silly stories about broken (or
insufficiently purple) packages do *not* qualify.

cheers
-- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr     | this .signature file.