[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal



Hi Bernhard,

I appreciate your comments and I fully agree with them, now that you
raised your questions.

On 28.09.2012 22:12, Bernhard R. Link wrote:
> * Arno Töll <arno@debian.org> [120928 18:48]:
>> Reasons to salvage a package
>> ----------------------------------------
>> The package is in clear need of some love and care, i.e. there are open
>> bugs,  missing upstream releases, or there is work needed from a
>> quality-assurance perspective; AND there is the need to upload the
>> package to deal with these  issues; AND at least one of these criterias
>> applies:
>>
>> * There is no visible activity regarding the package [5] for /six months/.
> 
>> [5] Activity may be defined in favor of the maintainer if in doubt. A
> 
> Why "may" ?

I think, this is due to the nature of my proposal of being a ...
proposal. If people think this is a good constraint, you're right then
no "may" should stand here.

>> maintainer may ask for help or welcome a NMU. This counts as activity
>> with respect to salvage criterias. If a package lacks uploads, there is
>> no visible bug triaging,
> 
> I think "bug triaging" is a word meaning different things to different
> people. How about "no reaction to bug reports"?

Fine with me.

>> and - if applicable - the source package's VCS
>> does not show commits this is an indication, a package lacks an active
>> maintainer.
> 
> The way that is written a package which had no new upstream releases,
> no bug reports and nothing else to react to for only half a year and
> then some new issues (like bug reports) would be an instant candidate
> for hijacking under salvaging rules. I'd say no visible activity when
> there was no need for activity can reduce the time of later non-visible
> but missing activity needed but should not reduce it that much.

I agree with your concerns here. Well spotted. I am going to think a bit
how to formulate that having your concerns in mind. Of course I do also
invite everyone to suggest better formulations.

>> * A previous NMU was not acknowledged, and at least another issue
>> justifying another NMU is pending for /one month/ [5].
>> * The last upload was an NMU and there was no maintainer upload within
>> /one year/.
> 
> Does this include "asked for" or "welcomed" NMUs?

I think the overall tone of my proposal is to be in favor of the
(current) maintainer when doubts exist. We should not penalize someone
asking for help, or welcoming a NMU for fixing a problem. Having that
said, I do not think this would be a problem in reality. If a maintainer
is responsive and invites other people to NMU his own package, he could
as well just agree to accept someone else as a (co-)maintainer upon
request.

>> * The package blocks a sourceful transition or the implementation of a
>> release goal for /six months/ after a transition or release goal bug was
>> filed against the package in question.
> 
> Some clarification would be nice here. There can sometimes be quite
> longstanding bugs that later can be elevated. (And I think a bug being
> minor for some months and only elevated for a week should not yet
> count).

Also a valid concern. But I'd like to avoid bug severity ping pong
("downgrading a bug severity to normal to bypass a salvage criterion
which may apply in X months starting as of today").


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: