Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
> Maybe an example will help get us on the same page. Russ seems to
> have the impression that my proposal is somehow a license to push
> unwanted changes at a maintainer. That is not true.
> Let's consider mlocate as a hypothetical:
> - The contributor wants a new upstream for better hurd support
> - He prepares an nmu of that new upstream (making sure to not modify
> the maintainer's build setup and packaging style)
> - He convinces a DD that this is worthwhile to sponsor, and that DD
> decides that he is willing to take the social risk involved if
> something goes wrong
> - The DD uploads the package to DELAYED/<whatever we agree is long
> enough> and sends an nmudiff to the mlocate bts
> - The maintainer gets the mail, cancels the upload, and says to the
> contributor "for me hurd support is not enough to take the risk of a
> new upstream upload"
> - In this case, the contributor would probably say ok that's fine, and
> not push it further
> - But if he really thought it was that important, he would take it to
> the Tech Committee, and in this case, the committee would most likely
> side with the maintainer's opinion
In this scenario the contributor should have talked to the maintainer before
requesting a sponsor.
| Have you clearly expressed your intention to NMU, at least in the BTS? It is
| also a good idea to try to contact the maintainer by other means (private
| email, IRC). If the maintainer is usually active and responsive, have you
| tried to contact them? In general it should be considered preferable that
| maintainers take care of an issue themselves and that they are given the chance
| to review and correct your patch, because they can be expected to be more aware
| of potential issues which an NMUer might miss. It is often a better use of
| everyone's time if the maintainer is given an opportunity to upload a fix on
| their own.