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 <[EMAIL PROTECTED]>. 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/
pgpsN05Zbk41x.pgp
Description: PGP signature
