[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: Why not use testing-proposed-updates?



On Sun, Feb 03, 2002 at 01:13:56AM +0000, Adam Olsen wrote:
> On Sun, Feb 03, 2002 at 12:55:13AM +0000, Robert McQueen wrote:
> > In a previous message you suggested 'why not just fix up the unstable
> > package'... as the initial write-up said, this is not always so easy. A
> > new or beta version in unstable might have all manner of bugs, where the
> > one in testing has a build error with a one-line patch or something. If
> I think this is the real problem.  Testing and SID aren't really
> seperate distros.  They'd be better named SID-New and SID-Tested.  In
> fact, maybe I should propose renaming them, because they'd be that
> much clearer...

Was that sarcasm?

I certainly hope it was, becuase if it's not it's completely and utterly
adrift from anything approaching reality.

The problem we're having is not that that woody, sid, testing or
unstable are bad names. It's not that the places to upload things to
is unclear. It's not even that people who are able to contribute aren't
allowed to. The problem we are having is that people simply aren't fixing
the bugs we have.

Take, for example, glibc. A security related bug was found in it in mid
or early December. A fix for potato eventually came out mid January. A
fix for woody/sid came out at the end of January, but unfortunately
didn't work on two or three architectures. Simple patches were sent to
the maintainer a day or two after the broken upload, and a week later,
Ben's made a new upload, which, hopefully will actually work. This is
to say that it's taken us almost least two months to come out with a
security bug fix to *libc* for heaven's sake.

Or, alternatively, take base-passwd as an example. It had a security bug
filed in early/mid December too (123345), which was eventually fixed in
mid/late January. Unfortunately that fix was broken, and a new version
that didn't corrupt /etc/passwd came out a few days later. Unfortunately
it too has a security related bug (130735) which has been open for over a
week now without any sort of real investigation in how to fix it. There's
rumours that Wichert's doing some work on it, and there may be a fix in
a few days.

If you need a third example, look at rsync, the security update to which
didn't end up working properly (131247, 130924). In this case, Red Hat
managed to work out a fix, and, again, Wichert's working on an upload of
the Debian package that incorporates that fix.

Now, quite frankly, if you really, sincerely, want Debian to do a better
job of releasing (whether making it more frequent, or higher quality,
or more current compared to upstream releases) then *help working on
fixing our RC bugs*. Run "apt-get remove mutt" (or the equivalent), and
spend a few hours actually trying to understand some of the bugs that
are in the RC bug list, and *FIX* them. Don't downgrade them. Don't whine
about them. Don't propose dropping the architecture they apply to. Don't
wonder if that sort of behaviour should even be supported. Don't complain
about how they obviously require someone smarter. Don't worry about how
this might, hypothetically, not be possible for some things, or harder
than it might need to be. Don't mutter about how you don't care about
such-n-such a package. JUST *FIX* THEM.

The most important part of releasing a good piece of software, is coding
it. We aren't doing that either quickly or well at the moment.

It really is that simple.

Some example known bugs, for all of which I'll expect to see patches or
uploads before the next post in these moronic threads:

	apache 130696, 130717, 131104
	apmd 130129, 131415
	cgiemail 129104
	craft 114333
	cvs 131153 131688
	dmalloc 131222 131871
	epic4 125784
	g77 129573
	gdm 130558
	gmc 103102
	gnome-admin 128086
	gnotepad+ 130477
	grip 131686
	insight 119720
	iproute 131695
	kdelibs3 130479
	kdenetwork 127869
	libpaperg 131335
	lyx 131303
	ntpdate 117162
	radvd 108486, 116038, 116405
	rproxy 116746
	slocate 128477
	snort 131730
	squid 129262
	sudo 131592
	xmms 130196

Now yes, it's true, you, personally, probably don't use most of those
pacakges.  Fine. Get the ones you do use fixed, right now. If they're
too hard, fix some of the others, and hope that someone else will do
likewise for whichever of your favourite packages he doesn't use. And yes,
it's probably true that some of those bugs don't need to be fixed before
release, either because the testing version's not broken or because we
can drop the package. That doesn't matter: the bug needs to be fixed
sometime and now is better than later.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

The daffodils are coming. Are you?
      linux.conf.au, February 2002, Brisbane, Australia
                                --- http://linux.conf.au/

Attachment: pgpZb9XC7bxx0.pgp
Description: PGP signature


Reply to: