Re: Regarding unresponsive Debian maintainers
On Tue, May 24, 2005 10:27, Tollef Fog Heen wrote:
> No, it is not always positive. Co-maintainence means you have a way,
> way higher overhead at maintaining the package. I don't have to coordinate
> uploads, checkins and so on with myself, for packages with comaintainers,
> I do.
It does not have to be if you manage it the right way. One can think of
several solutions where you don't have high overhead. The type of
co-maintenance depends per package and per developer, but I'm positive
there is a good way to be found for any package.
Examples:
- A situation where the maintainer has the full control, and
co-maintainers are a kind of "helpers". Two forms of this:
1) The maintainer has full control over uploads, the co-maintainer(s) only
do bug-triage, or commits to the repo.
2) An option is that the co-maintainer only uploads when the regular
maintainer does not, ie is away for a week, or has indicated to be too
busy.
This of course requires the main maintainer to be active, the
co-maintainers here serve to reduce the load on maintaining and as a
second set of eyes.
- You can have a situation where the maintainer in general does all the
work, the co-maintainer just watches and only jumps in when the maintainer
is temporarily unavailable (eg on a holiday, overloaded or missing).
- When you known you can have quick contact with your co-maintainer,
co-ordinating uploads is really easy (eg on irc, jabber or down the
hallway), so here overhead is very minimal. For my packages I coordinate
all uploads with the comaintainer because I have to (as a sponsor), but I
notice that this doesn't take a lot of time at all.
- The package is large and multiple (co)maintainers can do uploads, this
needs more coordination but for larger packages this is time well spent.
- A good situation is also where the co-maintainer is someone from
upstream. The maintainer knows about Debian and its policies, packaging
and the like. The upstream person follows up on bugreports, knows which
have been fixed already, can provide patches from upstream or can fix the
problem upstream right away.
Concluding, I think the overhead can be minimal, is outweighed by the
general improvement in package quality I expect.
regards,
Thijs
Reply to: