Re: Advice with uncooperative maintainers
Andreas Barth <email@example.com> writes:
> * Goswin von Brederlow (firstname.lastname@example.org) [040812 06:25]:
>> Greg Folkert <email@example.com> writes:
>> > On Wed, 2004-08-11 at 20:16, Marcelo E. Magallon wrote:
>> >> On Wed, Aug 11, 2004 at 11:41:28PM +0200, Jérôme Marant wrote:
>> >> > > Two more options:
>> >> > > Hijack (which would be hijacked back imediatly I guess) or upload a
>> >> > > new package under a different name.
>> >> >
>> >> > Hint: this package is maintained by a ftp-master ;-)
>> >> Are you suggesting that an ftp-master is going to abuse his role to
>> >> veto a package he doesn't approve of? If that happens we have a larger
>> >> problem that some pitty sound server not working...
>> > I don't think he is insinuating that. I do believe that JM is referring
>> > the levity of doing an NMU, is much more grave when an ftp-master is the
>> > one that you are NMU'ing is one o'is packages. Best make sure all the
>> > "eyes" dotted, "tees" crossed and follow the proscribed route.
>> I think he ment more that uploading a fork of a package of an
>> ftp-master could have trouble getting through queue/NEW. Reason for
>> denial: duplicate.
> I hope that ftp-master will reject in any case. There is no need to
> duplicate packages in debian. If one package is broken, then fix it.
What is broken? Last I checked not following the latest upstream
version wasn't broken. If a maintainer does not do this and there is
disagreement about if it should be done (which fits this case)
uploading a second package following upstream more closely is a viable
option I think. Look at the packages with a foobar and foobar-cvs
flavour for example.
Sometimes duplicate packages are justified.
> BTW, neither a NMUer nor d-devel could force the maintainer of any
> package to take (or accept) a certain action. Only the technical
> comitee can do that, so if you disagree with the maintainer (and if a
> maintainer rolls back a NMU, this is definitly disagreement), you
> could forward this issue to the TC.