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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

I think this proposal is a little bit too complicated and not straightforward 

Clearly we have two different situations:

  * Maintainer is not active and we want to orphan a particular package.
    (just to orphan without adoption)

For this case filing a bug "please orphan this package" with CC to QA team 
seems reasonable mostly because MIA may be an overkill (what if maintainer 
just don't have enough time with the absence of co-maintainers? Also consider 
the case of prioritising when active maintainer may be working hard on more 
important issues).
Also MIA procedure (if applicable) may take too long -- it is not unusual when 
it takes 6 months or more to complete MIA checks and orphan all packages.

If "please orphan this package" bug is answered (or closed) by maintainer it 
clarifies the situation immediately.

Obviously anyone can update the bug with objections in which case we need some 
form of consensus to proceed. I would leave the decision to QA team as they 
are handling orphaning anyway.

If bug was unanswered for let's say two months the package is free to orphan 
by QA team. I believe one month won't be enough: maintainer might be without 
connectivity while changing internet providers, attending funeral overseas, 
being on long vacation, on maternity leave, relocating, changing jobs etc. 
Such reasons can easily keep maintainer offline for a month.

This will work if QA team won't hesitate to orphan in obvious cases.


Another (second) situation:

  * Maintainer is not active and somebody intended to take over the package.

I think proposal is addressing this case in order to protect package 
ownership. I believe generally we should trust developers (DDs) and avoid 
unnecessary bureaucracy. If DD is going to snatch the package without waiting, 
asking or following the procedure it would be a case for technical committee 
to investigate.

Practically speaking taking over the package often bypasses orphaning.
Either developers decide between themselves or new maintainer declares (her|
him)self as such.

The question is whenever we want package to be orphaned first, which I believe 
is unnecessary as long as new maintainer publicly announce ITA.

Also I think we should trust DDs to decide how long to wait for maintainer to 
reply. One month seems reasonable but it depends: timing may be important 
before freeze or if package is blocking other packages. Proposal can recommend 
to wait one month, ideally two.

As for DMs or non-members they would have to find sponsor to review their work 
anyway so we don't need a procedure to protect package ownership from 
hijacking by non-DDs.

I like the idea of filing ITA against the package in question. It clearly mark 
the intention to work on the package and notifies the maintainer 
automatically. It doesn't have to be called "ITA" -- we can call it "co-
maintainership intent" or whatever.

Consensus 3 to 1 will be only needed if there are any objections but that's 
common sense. In obvious cases a single developer's decision should be just 
enough for adoption.

I believe we're all respect each others work and our intentions are good so we 
need only little clarification how to adopt a package respectfully.
For example I would mention to keep old maintainer in Uploaders unless 
(she/he) agreed to retire from maintenance.

All the best,

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: