On Sun, Feb 18, 2001 at 12:11:09PM +1000, Anthony Towns wrote: > Contacting first, waiting for permission, etc are polite and desirable, > but you don't *have* to wait for weeks in between, especially for packages > with RC bugs and with the freeze approaching. Also, you are allowed to > fix non-RC bugs and such too. > OK Here's a prime example. lcdproc currently in stable and unstable as lcdproc_0.3.4-3. It hasn't been updated in over a year. Current maintainer is Brian Bassett <brianb@debian.org>. I've emailed him at least 4 or more times at a few email addresses over the past couple of months with no reply. Lcdproc is now upto version 4 something. Now I could just NMU as this would fix a couple of bug in BTS, but to fix the upstream bugs I need to jump to version 4 of lcdproc which has moved to a client server model. It therefore makes more sense to create a multiple binary package with lcdproc-server and lcproc-client. Which complicates things. Now I've actually packaged all that up since I use it myself. But what's the correct way to go about things. Do I NMU, a bit dificult since I want to split up the package do I take it over or what etc etc. I think we need some sort of procedure in place where package automaticaly gets orphaned maybe something like this. a) Somone notices a package hasn't been updated in say over 6 months but there has been alot of upstream development and there are bugs against it in BTS. b) They email the maintainer. Wait a month. Email again wait a month. c) Place a prospective abandonded package warning against the package in BTS d) If the maintainer still does nothing about it in another 2 months then put the package up for adoption. I think this sort of thing is going to be a recurring problem as we get more and more developers. -- John Ferlito Senior Engineer - Bulletproof Networks ph: +61 (0) 410 519 382 http://www.bulletproof.net.au/
Attachment:
pgpIRoGpm6KhB.pgp
Description: PGP signature