Re: Water and Fire (was: MIA, Incompetent and holiday-loving maintainers)
Frank Lictenheld wrote:
Your preferred viewpoint seems to be that of an organisator, an
optimizer. You want to make quicker, better releases of Debian[2]
Yep. Well, the reason I started getting involved is that I use the damn
thing. And from my point of view there have been few specific packages
which really bother me or cause me trouble (kudos to the many developers).
Some things which have bothered me are:
* Despite its Social Contract, Debian is not 100% Free Software, and
currently isn't even trying to get close;
* Documentation is generally really disorganized and it's hard to find
key information;
* It's very difficult to have an even moderately up-to-date Debian
system which is also stable;
* Those packages which have really bothered me have been in states where
I would have preferred them to not have been available at all;
* When choosing between alternative packages for some purpose, there are
often good, up-to-date ones, and bad, out-of-date, badly maintained
ones, but from the display in dselect, I can never tell which I'm
installing;
....
In addition, organization is undoubtedly my strong point. I work
top-down (in the engineering sense) very well and I like it. I work
bottom-up (in the engineering sense) OK, but it's certainly not my
preferred method of operation, because it's not what I'm best at. I
mean, look at my first GCC project: rewriting the top-level build system!
I'm glad you're working from a different angle, one which doesn't really
fit me. :-)
and you're trying to point out people that are hindering this goal.
I'd rather point out *things* which are hindering the goal, but some of
the more important things appear to be behaviors, and that starts
getting into people. :-P
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.
"First, do no harm," eh?
I don't usually want to 'judge' people. I admit that I am judgmental
when it comes to people who don't seem to really care whether Debian's
Social Contract is clear, and those who don't seem to care whether it is
followed -- I think if they really don't care, allowing them to do
anything is worse for the project than doing nothing. (Most such people
however probably do care and are just confused in some way.) But I
probably come across as a lot more judgmental than I actually am about
other things; see below.
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.
Do you mean "pissing people off"?
I know I have a tendency to come across as hostile and confrontational;
I apparently do so even when I mean to be completely neutral or even
positive, and apparently when I actually do mean to be hostile, I can be
incredibly harsh. I've been working on this for years; trust me, I'm
better than I used to be. :-/
I will come clean about one thing. In my mind, I have classified a
certain amount of the stuff I have done regarding Debian in the last few
months as "nagging". Of course, nobody likes being nagged. I asked
myself, "Will nagging actually do any good?" I actually expected it not
to do any good, since in other arenas I've rarely found that it works,
and it certainly doesn't work on me. I simply wanted to have a record
of the failure of nagging before suggesting other things. But as far as
I can tell, nagging Debian Developers *is* usually effective.
Interesting. :-)
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.
I actually haven't advocated kicking people out very often.
I *have* advocated taking packages away from people, a *lot*. This is
because of two theories which I've been working from, which looked to me
(on unscientific observation) to be true. If I'm shown to deeply wrong
about either, I'll change what I'm trying to do!
* Unmaintained packages are generally better maintained when they are
*without* a listed maintainer (QA as maintainer) than *with* one --
because anyone who cares feels free to put in the effort for a while,
and with a maintainer they don't.
* Often no package at all is better than a really poorly maintained
package. (I bet I'll get a lot of flak for this claim, but as a user I
find the mixing of 'junk' packages in with the rest very irritating and
troublesome. "More packages" does not mean "Better Distribution" to me.)
Only a maintainer (or a group of maintainers) can maintain a
package.
This is of course trivially ture, though it may put the cart before the
horse. Someone once said something like, "You're the maintainer if you
maintain the package, not if you have your name on it."
A NMU is for small fixes that have big consequences and that
have to happen soon.
Which are common enough, unfortunately. :-P In fact, this thread
started because I made a list of such issues.
but your demand for more quicker NMUs
is IMO flawed
I don't demand it. In general, I don't even think it's a good idea. (I
do think it's probably a good idea for the type of fixes mentioned
above, and I documented why I think there are a lot of such issues.)
I also noted that the need for NMUs is directly related to the
performance level of "listed" maintainers. I don't see a simple
solution for the problem, but I figured understanding the relationship
clearly was worthwhile.
(Note: I talk about the "normal process" here not
freeze processes or related things).
Isn't 'testing' meant to be 'releasable at all times'? Doesn't that
mean a sort of 'constant freeze', in a certain sense? :-O
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.
I agree in theory. However, I accept the fact (repeated very often on
this list ;-) ) that maintainers often do have other things to do, and
cannot be expected to always fix all bugs, even important ones with
simple fixes, immediately (within, say, a week). But for any problem
with a simple fix there is probably *someone* in the community of Debian
Developers who *can* fix it within a week. That sounds like a valuable
and proper function for NMUs. :-) And I tried to help with this
straightforwardly, in a non-hostile manner, by collecting a list of
packages for which this seemed appropriate.
And lets enhance the maintainance of packages, not
the speed of NMUs (to repeat: yes, this is _not_ the same).
Of course it's not, but more timely (I'd rather not say 'faster' since I
was talking about delayed uploads!) NMUs might (or might not!) help the
maintenance of packages.
I don't think we're actually that far apart in opinions, although we
clearly have different methods of operation. :-)
Reply to: