On Fri, Aug 02, 2002 at 03:07:51PM +0200, Raphael Hertzog wrote: > Le Fri, Aug 02, 2002 at 05:15:30PM +1000, Anthony Towns ?crivait: > > You might want to give some details so the "problem" can be examined. How > > many packages? For how long? Why? What other possibilities are there that > > might not have gotten them stuck? > Sorry I have no log of testing's evolution to be able to give you any > realistic stat for "how many" and "how long". Then _get some_. Don't make it up as you go along, do the research _first_. > But I can give some figures based on the actual update_output.html. I can give you some figures too: 33, 42, 978, 9.376. Numbers aren't any value unless they're actually informative. > We have 354 source packages that are stuck in unstable for more than 30 > days (calculated with a hacked grep-excuses script taken from > devscripts). And why are they stuck? Is there a good reason for them to be stuck? What're the other options in each case? Raphael, you've been complaining for months that I haven't applied some patches you want to the BTS. The reason I haven't is that I don't have arbitrarily large amounts of time to devote to Debian; please stop wasting the time that I do have. Go away. Stop waving your banner and trying to lead a charge until you have some actual idea where we need to go. Do the research, watch how testing behaves for a while -- personally, I'd consider three or four months to be a lower bound, a single day just after we've had a "testing isn't running" freeze is worthless -- then spend however long it takes *thoroughly* surveying every instance of the general problem you've found so you can give us a full list of alternatives that would've been suitable in each case. > > > Problem 2 : > > > ----------- > > > We upload almost everything in unstable : > > This is a statement, not a problem. > This is an introductory statement yes, the problem was described in the > paragraph below and it's a real problem. It's one of the worst source > of "stuck packages". So you've already decided what the cause is before you even bother to say what the problem is, eh? > Yeah, read my explanation to Santiago Vila, it's more a "potential > source of problem" or an area where we have "room for improvements". We have plenty of room for improvement. http://bugs.debian.org/wnpp, eg. > It's not something that can be easily predicted, only experience could > tell us. Then. Get. Some. Sheesh. Seriously: getting packages from unstable to testing -- which is to say, getting packages into releasable condition -- isn't trivial. It's not meant to be: writing good software is hard, and packaging it isn't much easier. Making a major change to a group of interdependent packages without breaking *any* of them is also hard, and you really *shouldn't* be surprised that it takes longer than making small changes or major changes that affect a single package. If you're claiming that's a "problem" that needs to be "fixed", you might as well write some letters to God about how unfair entropy is while you're at it. Sure, there are improvements that can be made, but by and large, they're going to be relatively minor tweaks. They're also not particularly crucial: sure, it'd be *nice* to do some of this better, but if we don't manage to do any of it any better, it's no great loss. Particularly compared to getting debian-installer functional, it's a completely insignificant issue. Worse, though, your posts are completely useless as a lead in to any useful discussion on this. So, again, please _stop it_. If you want to do something useful, go do the research so we can find out the real problems maintainers are facing and prioritise the most significant ones. Cheers, aj -- Anthony Towns <email@example.com> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Description: PGP signature