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

Re: [OT] lazy maintainers



You have missed two points in your hurry to let NMUs "improve" Debian.

1. Maintainers _are_ responsible for their packages. NMUers have no such
responsibility.

2. Communication with the assigned maintainer is the responsibility of
anyone wishing to make the package better, including NMUers.

When the NMU is made without telling the maintainer, there are no end of
problems that result. When the maintainer can be contacted, and is
communicative, the best way to make an MNU is to submit a patch to the
maintainer! You are required to do so anyway, so why not save a step.

While I'm working on the correction of a list of bugs, I'm much more in
favor of receiving a patch, than a notification that the package was just
uploaded by some-developer.debian.org. My time for maintainance is always
short. I prefer not to waste it by tracking down loose objects left around
by someone wishing to "help".

The concept of the "lazy maintainer" is a myth/strawman used to weaken the
real strength of Debian, which is maintainer autonomy. This is what
creates the consistency of the distribution.

This is what lets Herbert maintain consistent Kernel packages.
This lets Branden do the right things for X, over loud objections.
This allowed me to hold consistent key bindings for ae, despite everyone
else having their own ideas.
It allows every maintainer the control over their package that is needed
to act responsibly. You can not be held responsible if you don't have
control.

Anthony, your statements suggest that another maintainer can upload a
package that makes changes the official package maintainer objects to,
without asking for consent. It implies that such an upload would only
be done to improve the package and thereby improve Debian. That just
doesn't sound like a good thing to me at all...

Luck,

On Thu, 9 Aug 2001, Anthony Towns wrote:

> On Wed, Aug 08, 2001 at 08:28:37AM -0500, Jared Johnson wrote:
> > > A suboptimal package has already been uploaded. Myth may not be able
> > > or willing to make any improvements on it right now, but Kitame appears
> > > to be able to. As long as Kitame's not going to screw up Myth's future
> > > uploads, why shouldn't Kitame upload? Who exactly loses out?
> > Except that Myth is able and willing to make improvements, and is doing
> > so; he just hasn't uploaded them, which is his decision... at least as
> > long as it doesn't screw a release all to hell.
> 
> So what? It doesn't matter at all what anyone's doing at home, it matters
> what's uploaded. If Kitame's uploading something that's useful to people,
> that's a good thing. If Frank (Myth)'s working on stuff on his machine
> that'll eventually get uploaded and whip the pants off of Kitame's
> uploads, that's even better. There's no reason why they can't both happen.
> 
> > Sounds nice, but I wouldn't really like someone packaging the same
> > software as me and uploading it as package-foo simply because they
> > didn't like the way I did things.  
> 
> Then, well, get over it.
> 
> Technical objections matter. Whether it makes you feel as good as daisies
> and ice cream or not, doesn't really. If you've got a real reason not to
> upload it, then that'll apply to Kitame too. If it's just because you
> don't feel ready to make an upload yet, well, that doesn't necessarily
> apply to anyone else. If you've got 7 outstanding release critical bugs,
> you really shouldn't be remotely surprised if someone else decides to
> try making the damn thing work. [4 against mozilla, 1 against each of
> mozilla-browser, mozilla-dev and mozilla-xmlterm]
> 
> None of which is to belittle Myth's work on his packages. You don't
> have to take NMU's as a criticism or as insinuating that you're not
> fulfilling your duties, or anything of the sort; you can just take it
> as an indication that someone else values your package enough to go out
> of their way to improve it a bit.
> 
> Cheers,
> aj
> 
> -- 
> Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
> I don't speak for anyone save myself. GPG signed mail preferred.
> 
> ``_Any_ increase in interface difficulty, in exchange for a benefit you
>   do not understand, cannot perceive, or don't care about, is too much.''
>                       -- John S. Novak, III (The Humblest Man on the Net)
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> 
> 

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-                                                                    _-
_- aka   Dale Scheetz                   Phone:   1 (850) 656-9769     _-
_-       Flexible Software              11000 McCrackin Road          _-
_-       e-mail:  dwarf@polaris.net     Tallahassee, FL  32308        _-
_-                                                                    _-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
              available at: http://www.polaris.net/~dwarf/




Reply to: