On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote:
> Several ideas have been floating around for years on how to improve
> this situation, of which I'd like to mention three. While I've here
> used the number of bugs as the measure of a package's quality,
> the same ideas might help with other aspects, like getting new
> upstream versions packaged soon after they're released.
> * Team maintenance. If a package is maintained by a team,
> there are more people sharing the work. When a team works
> well, more people look at the package, and finding and
> fixing problems is more effective. There is less work per
> person, so things don't lag as much. A well-working team
> is a good thing.
> As an example, the Debian GNOME team seems to work really
> well. Transitions to the next upstream version happen
> quite smoothly these days.
OTOH, sometimes "team maintenance" means "no one takes responsibility for
the package." I've dealt with release critical bugs on packages where the
Maintainer field pointed to a "team" mailing list, there were several
Uploaders listed for the package, and the bug sat unattended for well over a
month for no apparent reason.
I've also *been* part of maintainer teams where all the members of the team
were busy people, and bugs tended to linger because they were somebody
else's problem.
Anyway, I agree that team maintenance can be a force for good.
I also agree with the rest of your mail, including the call for a more
proactive QA team.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/