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

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
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: