On Sun, Aug 09, 2009 at 01:04:36PM +0200, Luk Claes wrote: > Hmm, you do know that it's your job to hand that list (including all the > reverse deps of reverse deps ...) to the release team including the > necessary dep waits so we don't have to reschedule them till all succeeded?
Well, to be frankly honest, I don't actually _want_ you guys to blindly schedule blanket binNMUs for the lot of these. I'd much rather that it shook out all the packages that were as neglected as this was when I had adopting it thrust upon me unexpectedly, and that the relevant maintainers either take some action themselves to remedy things, or that it becomes clear that they are also abandoned and other project members will be free to act on that as they may care to. As a first round, I'd really prefer that the only binNMUs come as requests from the maintainers of those packages, who _know_ they are in good order, and don't care to immediately remove their own .la files, and that a simple rebuild will in fact suffice for them for now. If we take a cursory look at this lot, surprise, surprise, we see that libsndfile already has its own RC bug, open since March, and a bug requesting that its own .la be fixed or removed, since it's broken and dragging in unneeded dependencies. And libarts1c2a has its own grave bug, also open since March, with no response whatsoever from its maintainers. So no, I wouldn't recommend that those packages be binNMUed, I'd suggest their maintainers either fix them, be replaced by maintainers that will, or orphan them honourably and drop them in the QA pile. YMMV, and that's your call with an RM hat on. > There is a reason we advise to only remove a .la file once it's (almost) > not used anymore... Actually, vorlon suggested an even better way, that I wasn't aware of when I initially decided this, and that I probably will use for the next one I drop that has a lot of rdeps with maintainers that it would be impossible to coordinate a transition with. But as hindsight on this particular case is clarifying, it seems like this has quite a good chance of being a Good Thing for the quality and preparedness of squeeze for release, iff we don't just blindly mask the problems it identifies with a series of blanket, quick-fix, binNMUs. But that bit's your job to decide. My original plan was to look at what stragglers might remain after the package maintainers had their own chance to do new uploads. I know that at least all of the former pkg-xiph lot are currently in the process of being adopted by new maintainers. It seemed silly to race against them with binNMUs when all indications were that they'd be uploading new packages very shortly too. Sorry if I ham-fisted things in a way that made your job harder, but I decided this with good faith intentions for improving the quality of the squeeze release, and so far I'm not really seeing any signs that it is failing at that, despite some temporary pain in unstable for a few things, and perhaps some now-scheduled binNMUs that should in fact not be binNMUed at all ... If you have other suggestions, I'll be happy to take them on-board for the next time I have to decide things that affect your team's work. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org