Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react
On Fri, 26 Oct 2012 16:56:02 Bart Martens wrote:
> On Fri, Oct 26, 2012 at 08:06:57AM +1100, Dmitry Smirnov wrote:
> > If bug was unanswered for let's say two months the package is free to
> > orphan
> Some prefer no delay, some prefer one month, some prefer two months. I
> originally wanted one month, but I got convinced by others to drop the
For merely orphaning minimising delay is not too important because if there is
an active maintainer ready to adopt the package it is a "salvaging" procedure.
For example if package is not maintained for years we can certainly wait for a
month or two before orphaning even though there may be no need to wait that
> Now my opinion is that I trust the DDs reviewing the ITO to judge
> the package's situation before sending an ACK or NACK. One possible
> judgement on an ITO can be "NACK until 2 months have passed or the
> maintainer has agreed to orphan the package". Another possible judgement
> on an ITO can be "ACK because this package has clearly not been maintained
> for years, so please proceed without further delay".
I'm convinced that acknowledging is ambiguous and unnecessary.
First, what do you expect DDs to acknowledge -- the fact that package needs
attention (this should be obvious already) or their approval of salvager?
Assuming they're not familiar with salvager's work getting and acknowledgement
might be as hard as finding a sponsor.
Also this will rely on developers constantly reviewing ITA requests in other
Most certainly this will increase delay and the complexity of the procedure
which might work only for popular packages with high visibility.
I think in usual case we can expect no response for salvaging requests.
Also without timed delay acknowledgements may be very unfair if few DDs voted
for salvaging and therefore salvager got a green light without waiting for
Michael Gilbert's proposal to start salvaging with NMUs makes more sense as it
allows to proceed gently and demonstrate motivation and willingness to work on
the package. From non-DD prospective couple of successful NMUs will confirm
salvaging intent and capacity better than random ACKs.