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

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

On Thu, Oct 25, 2012 at 6:50 PM, Arno Töll wrote:
> On 25.10.2012 21:09, Michael Gilbert wrote:
>>     2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
>>          the package into a better maintained state.
> Please let's not go that road. Mixing-up the concept of a bad maintained
> package and the concept of NMUs together does not help. They do not
> belong together, and only blur both concepts, so that we only can loose.

The term "better" probably led to that interpretation.  By "better", I
mean improving the situation in an under-maintained package, not that
the packaging was somehow "bad."  That wording can be improved to
clarify that confusion.  How about:

     2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
          an under-maintained package into a more maintained state.

> You NMU because you aren't the maintainer, that's the "Non Maintainer"
> in "Non Maintainer Upload" and a fundamental difference. Developer's
> reference clearly states for good reasons that the concept of NMU is
> house-keeping in someone else's house. It's not your house (yet), so
> please respect that. We have too many people already, continuously
> ignoring NMU guidelines and are uploading NMUs with cosmetic changes
> (e.g. 3.0 conversions) instead. Let's not endorse this.

As I've said many times now, the liberal NMU would not be a license
for packaging style changes.  In fact, no NMU is allowed to make those
changes (the fact that people are doing it is apparently a social
issue, and solutions to those are hard).  It is instead more of a
license to go ahead and fix real issues with the package including new

> However, what you are proposing is right that: Make your footprints in
> someone else's package first, and find out later if someone complains
> loud enough. That's everything but respectful and eventually not going
> to help finding a way to head over a package to a new maintainer in a
> way which is a not prone to conflicts.

That is why the 10-day delay and bug report patch is important.  The
salvager prepares their changes and gives the existing maintainer
those 10 days to review and possibly reject them.  If the maintainer
does reject them, hopefully he does so in a constructive manner
indicating how to prepare an appropriate upload to meet his/her

If that process somehow breaks down, only then does the Tech committee
need to get involved.  But at least at that point, there is real
activity that they can judge.

Best wishes,

Reply to: