[Development] Maintainership of QtNetwork
andre.poenitz at mathematik.tu-chemnitz.de
Tue Nov 5 21:58:18 CET 2013
On Mon, Nov 04, 2013 at 08:49:45PM -0800, Alan Alpert wrote:
> >> > As some of you may know, Shane has a new job and therefore has a lot
> >> > less time to spend on QtNetwork. He, Peter and I have discussed how
> >> > we should maintain the module in the future. What we're proposing is
> >> > that Peter and I take over as joint maintainers since neither of us
> >> > has the time to keep on top of things alone. Anyone looking to help
> >> > out in this area should feel free to drop us a mail.
> >> This isn't a veto or anything, but having two 'equal' maintainers for
> >> the same area sounds odd to me. I mean, it's perfectly fine that you
> >> split up the workload, but the point of having a nominal maintainer is
> >> to have _one_ person to go to, and _one_ person who can decide if
> >> there's need ... It doesn't mean that the maintainer can't delegate
> >> his work though, up to the point that whomever he trusts can act as a
> >> de-facto decision maker, too.
> > Well, I am pretty much in the other camp. I see no problem here,
> > neither of the setup in general (better bus factor, less chance of
> > overload, something that rather should be encouraged...) nor with Rich
> > and Peter in particular.
> You're missing the point of having a hierarchy, deliberately assign clear
> bottlenecks for responsibility (and they shouldn't be used that often).
You are focusing on a secondary aspect while masking out the primary issue.
The goal of the project is to create a usable product.
Having a hierarchy might or might not be beneficial in achieving that goal.
So far the assumption was that having it bears quite some value, as it
helps to establish and to keep order. However, the hierarchy is not the
If two people, both with quite impressive track records in the project, ask
to share the responsibilities of one position, the question is not whether
it fits into the hierarchy, but whether it is beneficial for the project.
Answering that question might involve considerations of practicability, and
more, but theoretical considerations about the primacy of artifically
introduced bottlenecks are unlikely to help.
> Back from the general to the specific, I'm definitely happy with
> Richard and Peter stepping up if Shane no longer has time. It's better
> to have too many good maintainers for a module than too few.
> Since I think it'll be a long time until we hit a situation where the
> designated tie breaker rule will be needed, I'd suggest we vote them
> both in first and then tackle the general question of "shared
> maintainerships" separately.
I even agree.
More information about the Development