Re: Debian P2P Team
Hi,
On Fri, Aug 28, 2009 at 05:14:57PM +0200, Andrea Veri wrote:
> Actually there isn't a specific problem, I just think working as a team
> might improve the quality of packages when, for istance, a MIA
> maintainer leaves his package orphaned for long time without having no
> one looking at it.
I think it decreases the quality of packages if a MIA maintainer leaves his
package orphaned and everyone, including the maintainer, assumes that the
team will step in.
I also have found that for team-maintained packages, I felt less and less
responsible for packages after receiving mails that told me that they had
"fixed" some deliberate choice I made. The same people hell-bent on having
every package team-maintained will not stand idly by if a stanza for a
shared library package is commented out because the ABI is unstable.
> This way the fact to have a team behind all packages
> might reassure users about having their problems fixed without any
> consistent delay.
Please let's not forget that users running unstable are expected to be able
to diagnose and work around problems themselves. There is no value in
adding quick hacks to get rid of bug reports.
Teams make sense if most of the packages in the group follow the same
structure, for example perl packages, and maintainers are essentially
exchangeable because one does not need to understand how the software in
question actually works. Grouping packages by "field" does not work so
well, because there is overlap between fields, and individual packages
within a group are fundamentally different. In fact, I find that having
distinct maintainers for packages that integrate with each other is a
definite advantage because it requires people to actually communicate to
each other about interfaces and transition strategies.
> Well, I don't think we should call this a true 'workflow' change,
Yes, it is. I need to switch to the team maintenance tool of the month when
otherwise I could just call dpkg-buildpackage.
> operating as a team can make things easier for everyone, above all for
> maintainers who are pretty busy and unable to provide new revisions in a
> small period of time.
New revisions are not always good. I'd rather see a maintainer skip a
revision because they did not manage to find the time to test it than have
bleeding edge software that has not been looked at by anyone who actually
uses it.
Simon
Reply to: