Re: Implementation of Developer's DB
Christian Schwarz <schwarz@monet.m.isar.de> writes:
> I'm still not convinced by your arguments. Of course, these packages
> are complicated (and another problem might be that we are the
> upstream developers of "dpkg" so we'll have to do the coding, too).
The same applies to the boot-floppies package (i.e. there is no
upstream source).
> However, the whole organization of the Debian project is based on
> the fact that we have about 150 developers, who all contribute and
> maintain different packages.
Uh, how? Just because it's the current status quo for the majority of
packages doesn't meant our whole organization is based on it.
> As long a single developer takes care of something, everything is
> fine.
Foo *blah*. Please take that back Christian and I'll try not to die
laughing. I can point you to tens, if not hundreds, of packages with
a single developer where everything is not fine.
> However, as soon as you need several developers to work on the same
> topic things get much more complicated.
No. Not at all; dpkg and boot-floppies are *already* complicated.
I've yet to see you show that the group maintenance has anything to do
with their complexity. (i.e. please show me a time when dpkg and
boot-floppies were less complicated *because and only because* they
were maintained by a single developer)
> (Just look how long it takes for a project like the `keyboard
> configuration project' to get some first results--that project is
> not focussed on a single package, but tries to "coordinate" between
> packages.)
[I haven't been following that project and can't comment]
> Note, that I'm not saying that the current situation is
> bad. Obviously, you'll never know how much time each volunteer can
> contribute the next days/weeks. We've solved this by allowing
> `non-maintainer' releases.
This is in no way relevant to how the maintenance of the boot-floppies
package works, and, though I have no first hand experience of it, I
suspect, relevant to dpkg either. The fact is there are different
people working on different parts of the package; e.g with boot
floppies, atm, Bruce is/was working on getting a working cut-down
libc6 and Enrique and Luis are working on a C dinstall. How does the
non-maintainer-releases paradigm help there? (Hint: it doesn't)
> The approach `one maintainer per package' is just a representation
> of our development model and the past releases have proven that this
> model isn't totally wrong.
Sorry, I disagree, it's our development model for the majority of our
packages, because it's well suited to the majority of our packages.
That does not and should not mean it's the only viable model and that
no package should use another.
> I'm not judging packages or maintainers because of bug reports.
Sure. Whatever.
> However, comparing the length of the bug list with the frequency and
> the date of the last upload gives some indication whether a package
> is `actively maintained' or not.
You're still ignoring the content of the bug reports.
> [ Stuff about dpkg not being actively maintained snipped ]
I'm not disputing the not-well maintained state of dpkg; however I
would dispute that's because of the group maintenance and I've yet to
see you give any proof that it is the cause of the problems. All I've
seen you say so far is the truly laughable "well every other package
with a single maintainer works okay".
> > If you got several people working on a package, why should one
> > person be responsible for the bugs of other people? That's silly.
>
> Not responsible for the bugs, but responsible for having the bug
> reports handled. (This could be, to fix the bug himself or to find
> someone else fixing the bug, etc.)
Group of Maintainers Q (A, B, C and D) are all working on separate
parts of a large project. Why should say, D, be responsible for
ensuring B's bugs are fixed. Surely that's B's job?
> BTW, here, responsibility does not mean we'll punish someone for any
> bugs.
One would hope not.
> Hey, we are a volunteer organization and we all want to have fun!
Fun is for lamers who can't handle real life. ;)
> However, as we are trying to build a high quality distribution and
> the different developers invest a _lot_ of their spare time, we'll
> have to accept that this requires some "responsibility" how we treat
> other developers, etc. of us all.
Sorry, but you've lost me here. What exactly do you mean by
responsibility? Isn't all you're saying that you're not comfortable
with
Maintainer: Group of Developers <groupQ@debian.org>
but are comfortable with
Maintainer: D <D@debian.org>
I've yet to see any link of that to responsibility.
> Putting ones name in the "Maintainer:" field is like saying `Hi
> folks, I'm taking care of this package for now. If there are any
> problems with this package, feel free to contact me and I'll see
> what I can do.'
But *why*? Why is it better to have "Maintainer: D" instead of
"Maintainer: Q"? It doesn't change how much time A, B, C or D have to
work on the package does it? With your preferred option, if D gets
busy, mail will go unanswered. With the current state of things, it
takes A, B, C *and* D to get busy before mail goes unanswered. Your
preferred option is *worse* for getting mail answered.
And btw this *does* happen in real life; in the boot floppies people,
there is no one person who is ``responsible'' for the entire package,
so anyone answers bug reports, and that means more bugs get answered
than if only Sven were ``responsible'' for the package. The same
thing applies to the new-maintainer alias; if things were run there as
you would seem to like them (one maintainer only), there would be
people waiting from 6 months ago to become a debian developer; as it
is with 4 of us, even if 3 of us get busy with RL there is still
usually one of us around to answer mail and deal with applications.
> But unless someone proves by example that this is true, we should
> not change policy WRT this question.
Sorry but you have yet to ``prove'' that group maintenance
intrinsically damages package maintenance. You'll need examples where
the odds *aren't* already stacked against the package in question.
Oh, and BTW, here's a simple question for you: was dpkg in better
shape before Klee and Ian started jointly maintaining it?
--
James - [To steal a phrase: conclusive proof that fights on
debian-policy *are* more enthralling than revision]
Reply to: