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

Water and Fire (was: MIA, Incompetent and holiday-loving maintainers)



Long mail follows... in probably bad English

On Wed, Dec 31, 2003 at 03:41:12PM -0500, Nathanael Nerode wrote:
[many thoughts about NMU and MIA and related stuff]

Hi Nathanael.

Always interesting to read your mails on the various mailing lists,
especally because your approach of joining this project is so different
from mine but we are around here for a similar time now (and we're
both no DDs yet).

When I say different I mean that you're seeming to try a top-down
approach. You're seem to very active in tracking RC bugs and MIA
maintainers and pointing with your forefinger on people you think they 
deserve it[1], while I'm interested in partly the same fields 
(QA for example) but going more for a bottom-up approach: Doing
small things first, learning about history, traditions, people
and then going on to other jobs.

Both approaches have their advantages and disadvantages.

This said as an introduction for a more general answer to your
thoughts in the parent mail.

Your preferred viewpoint seems to be that of an organisator, an
optimizer. You want to make quicker, better releases of Debian[2]
and you're trying to point out people that are hindering this goal.
A valuable contribution but I just wanted not to let stand your opinion 
alone (And some of the following statements must not actually
contradict your position).

Two things (that are fully my personal opinion) we/you should not 
forget: 

a) Debian should be about people making good software together 
not about good software made by some people. So lets not forget to
have fun while we're doing it (if there are any DDs out there that
_only_ do this here because they are paid for it, I feel with you)
This leads to the conclusion that pissing of people is seldom the best
way to do things. Nearer to a release this perhaps changes slightly...
This leads to some more conclusions: 1) QA work is often the decision between
kicking someone out or getting someone back in. The first is
easier in most situations but not always better. 2) You often can't
motivate someone to work by qouting guidelines or executing
procedures but by appelling to their honor as maintainer[3].
3) If you try to judge one thousand different people from
different countries, backgrounds, motivations with some simple
guidelines you will make faults. Better let the faults not be
worse for the project than doing nothing. etc.

b) Only a maintainer (or a group of maintainers) can maintain a
package. This sounds simple, but there is one simple conclusion
from this: More NMUs are not generally better than few. Let not
forget this: A NMU is for small fixes that have big consequences and that
have to happen soon. Nearly every effort that is spent to resolve an issue
that causes a package to be NMUed is better invested than the effort
to NMU it. So your demand for more people tracking maintainers and
packages is good[4] (but see a)) but your demand for more quicker NMUs
is IMO flawed (Note: I talk about the "normal process" here not 
freeze processes or related things). A NMU often only cures a symptom,
not a problem. A NMU does nothing for the improvement or the "evolution"
of a package, it just fixes a single symptom of brokeness. So our
goal should probably not be to promote more NMUs until a package
is orphaned but to make the time shorter and the process more reliable
until a package is orphaned (and yes, this partly contradicts with what I
said in a), this is what it makes complicated)

Summary: Our goal should not be "good software" but "good software
we created together because we love to make good software and it is
fun to do[5]". And lets enhance the maintainance of packages, not
the speed of NMUs (to repeat: yes, this is _not_ the same).

[1] sorry if this is a German only symbol
[2] who doesn't want this?
[3] but we need perhaphs better procedures for the case where this
doesn't help
[4] and to be one of them in the future is one of my long-term goals
as a (not-yet-)DD
[5] together with hard work...

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/

Attachment: pgpn42CZg0gae.pgp
Description: PGP signature


Reply to: