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

Re: Re: MIA, Incompetent and holiday-loving maintainers (was: Request for NMUs.)

Martin Michlmayr wrote:
I have done much work on this in the past, orphaning over 300
packages.  However, I have not had the time yet to act upon
Nathanael's summaries he posted to -qa.  I will hopefully do that
soon, though.
Yes, thanks and good for you! I guess nobody else feels comfortable doing this sort of thing though. It really shouldn't be just you alone, especially since you should be involved in the process of delegating work to others.... :-/

I'm a little too aggressive in some of those; probably because I'm spending all my time looking at the busted packages. :-P

Martin Mitchell is obviously MIA, but nobody's bothered to orphan
his packages yet.

I orphaned a bunch of his packages (those which were in a really bad
shape) in September.  I'm considering orphaning the rest.  However,
you underestimate the complexity of the problem.  While Martin totally
ignored all the messages I sent him and didn't even react to me
orphaning some of his packages, he was uploading other packages.
Yeeech. That's really disturbed. Did the uploaded packages actually fix the bugs in them?...

There's a nasty pattern which seems to show up occasionally where a maintainer only uploads to say "new upstream version", and never fixes any bugs (never even reports them upstream). I will not name names since I don't have any at the moment. :-) But that's not exactly maintainership, and more importantly it doesn't make for releasable packages. :-/

makes it a hard decision to orphan all his stuff, when he's doing some
work.  At the same time, even though he made uploads, most of the
packages were still in a bad shape.
Including the uploaded ones?

Yeah, there's some types of substandard work that are really worse than no work at all. With no work at all, it's *clear* that it's not being maintained -- it can be assigned to QA and pretty much any developer can feel free to make any changes s/he wants, or even to propose removing it as too buggy to support.

With occasional sloppy work which doesn't do much good, the package sort of gets stuck in a 'bugs not fixed' mode, because non-maintainers don't feel comfortable making substantial shanges.

This is not to criticize occasional work which actually *does* help, although Requests For Asssistance are certainly in order on packages which remain buggy in that sort of manner.

In another message you wrote:
Anyway, there's a README which gives some more information about this
problem.  See http://qa.debian.org/~tbm/mia/README

What *should* be the standard for NMUs? I see from this that it's a definite question.

Currently, most developers seem to have adopted a deferential system something like this: * wait until the bug has been open/patched for several weeks without a maintainer fix
* ask the maintainer if it's OK to NMU
* wait another week for a reply
* if the maintainer says he'll do it, wait another month...

Obviously, this is not effective with maintainers who say they will fix things and don't get to them; it means that bugs remain for many months longer than they need to.

It's not even effective with maintainers who are just busy and welcome NMUs, because of the long 'wait-for-permission-or-silence' period.

Perhaps it would be better if this attitude was taken towards RC bugs with patches in the BTS:
* Wait 24 hours to see if the maintainer accepts or rejects the patch.
* If not, NMU (delayed) ASAP.

:-/  It would likely get stuff fixed faster in some cases.  I dunno.

Anyway, the problem with 'absentee' maintainers is actually very tightly linked to the NMU issue. When a maintainer just sort of vanishes for more than a month, the best way to keep their packages in order is to NMU them routinely for all bugs.

However, people don't want to encroach on the maintainer's job, and since the maintainer didn't say s/he was going away, people tend to wait and see if the maintainer will deal with it for at least a month; then start asking and waiting for maintainer replies; then eventually get around to NMUing after two or three months.

So a maintainer who doesn't reply to bug reports for a month or more tends to have his packages in bad shape for at least several months. :-/ Even when they don't really have to be.

If NMUs were common, quick, and encouraged, the absentee maintainer problem would be less critical (only those missing for years would really cause massive trouble, and that due to lack of new upstream versions). And of course less maintainer absenteeism would mean fewer NMUs needed. Of course, there are other good improvements (co-maintainership; appointing surrogate maintainers during vacations; etc.) possible too.

Another unfortunately common maintainer 'attitude problem' is the bug accumulation problem. That is "I'll fix this trivial-to-fix bug when I fix the other XXX bugs, and it's not worth uploading until I do." This leaves trivial-to-fix bugs open for months or even years longer than they need to be. It's simply the wrong way to operate. :-/ However, it seems to be firmly stuck in some people's heads. Remember the mantra: release early, release often? It applies here. I have no idea how to fix this mental block, however.

Incidentally, packages.qa.debian.org is an *invaluable* resource. Every developer should check each of his or her packages there routinely. I don't know how anyone handled anything before it. ;-)

Reply to: