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

Re: [OT] lazy maintainers



On 08 Aug 2001 21:08:15 +1000, Craig Sanders wrote:
> On Wed, Aug 08, 2001 at 04:01:17AM -0500, Jared Johnson wrote:
> 
> > Doing an NMU without the maintainer's consent and without the
> > maintainer being MIA is one of the more evil evil evil things a debian
> > developer can do.
> 
> why? what's so evil about that? debian isn't a turf-war game of "mine,
> mine, mine".

debian isn't a turf-war game specifically because debian developers
respect each others' imagined jurisdictions.

http://www.debian.org/doc/developers-reference/ch-nmu.en.html

Do I even need to point out that this makes it painfully clear that it
is off limits to do an NMU without the maintainer of the package giving
explicit permission or else being MIA for a long time?  It also states
that during the freeze fixes to serious bugs and security problems are
accepted, yet even then an NMU'er should try to reach the current
maintainer.  Myth is not MIA.  Myth has not given any permission.  We
are not yet frozen.  Myth hasn't even participated in a turf-war, he
hasn't even responded to this pathetic thread at all.  Kitame, on the
other hand, has simply told debian-devel that he plans to NMU mozilla on
account of alot of people wanting it.  This is simply unacceptible.

> being maintainer of a package doesn't mean that it is your PROPERTY, it
> means that it is your DUTY.

And according to the debian constitution debian developers have the
right to do this duty if they're able.  They don't have the right to
usurp each others' duties without consent or neccesity, even if alot of
sid users think it's a good idea.

> if a package maintainer, for whatever reason, is unwilling
> or unable to perform the task he volunteered for (i.e. maintain a
> particular package) then he should NOT get in the way of anyone else who
> is willing to do the work.

Myth is neither unwilling nor unable to maintain it; in fact, he is
maintaining it.

 
> IMO, it's sitting on a package and doing nothing with it that is evil.

Myth isn't sitting on any package, he's developing a package.  Not
uploading a suboptimal package is not evil.

> > From there some ignorant fellow voiced his approval of kitame's
> > attempt to knowingly hijack another maintainer's packages, and
> > some others piped in their agreement with the completely falacious
> > assumption myth is lazy and that a point-release in the 0.9.x series
> 
> it's got nothing to do with whether myth is lazy or a bad maintainer
> or whatever. he's not, he does a good job, BUT he has reasons for not
> uploading new versions of mozilla right now.
> 
> fine, we should respect his decision. he doesn't have to upload a new
> version and no-one can force him to (or should even try)
> 
> but we have someone else who is willing to do what myth is unwilling
> to do. problem solved. nobody, and that includes myth, should obstruct
> that.

bzzzzzt wrong, as i showed above.

> > is so important that debian policy and procedures should be ignored to
> > get it in a week earlier.
> 
> it's not a matter of a week, or even a few weeks.
> 
> if history is anything to go by, it will be many months.

History is nothing to go by.  The issues which obstructed mozilla's
post-M18 versions from being uploaded are now non-issues.  If most
people aren't informed of the issues which are now preventing upload of
the new pakacages, perhaps it's because Myth is too disgusted with their
disrespectful comments about him, or perhaps because he's busy working
on making the packages better.

> craig
> 
> ps: personally, i think if this doesn't get resolved soon then kitame
> should just avoid the controversy and make a new package called
> mozilla-kitame which provides, replaces, and conflicts with mozilla.
> it's not a perfect solution (versioned dependancies don't work with
> virtual packages) but it's better than nothing.

FTP masters probably would not so much agree with this; and I'm glad,
because I also disagree with it.  It's basically hijacking the package
and sticking a different name on it, with the added bonus of creating
problems.  The debian constitution gives debian developers the right to
make technical and non-technical decisions regarding their work.  Other
developers can't just override these decisions without consent or damned
good reason (reasons which are outlined in the Developer's Reference and
are not present in this case), even if they change the name of the
package first.

Cheers :)

-- 
Jared Johnson
solomon@futureks.net

GPG Key ID: DF 28 CD 64

-----BEGIN GEEK CODE BLOCK-----
Version:  3.12
GCS/C d+(-)>-- s:+ a18 C++++$ UL++++>$ P+>++++ L+++ E--- W+ N+ o? K-
w--- !O
M-- V-- !PS !PE Y PGP- t+ 5-- X R-- tv- b+ DI>+ !D G e>++(>+++) h-- r*
y-(>+++)
------END GEEK CODE BLOCK------



Reply to: