On Thu, 2016-12-01 at 15:46 +0000, Ian Jackson wrote: > There is a recent case where: > * The maintainer has done nothing to the package for many years, > other than infrequent (and usually short) emails to NAK > contributions from others; > * Several times, proposed updates have been prepared by contributors > but blocked by the maintainer; > * There are new maintainers ready and waiting, with a new package > ready for upload to sid for stretch; > * Now that the TC is involved the maintainer has written many emails > explaining their decisions to NAK uploads, but TC members are > clearly unconvinced on a technical level that those decisions were > right. The points are technical decisions someone has to adjudicate on, however if occurred to me this one could be handled differently: > * The package is years out of date compared to upstream, afflicted by > bitrot, and many users are asking for the new version; Why not have a formal rule that says if a package in Debian is out of date for more than one release cycle any DD can package it under a different name, after going through the usual ITP procedures coupled with a bug report to the original package citing the ITP and a delay? It's not like we don't do the parallel versions bit now - squid / squid3, exim / exim4 and so on. The original packager isn't powerless when this happens as he can stop the procedure in it's tracks by simply upgrading his package within the delay period. We already have done something like this with live-build-ng / live- wrapper. It wasn't a pleasant process but it did produce a decision that allowed everyone to move on. That included Daniel. He chose to stop maintaining live-build, but he also could have continued with his package and let popcon decide, or he could have taken another look at whatever features the CD group wanted.
Attachment:
signature.asc
Description: This is a digitally signed message part