Re: [Xen-devel] Survey Results - Part 1 : Improving Xen Project Governance and Conventions

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-10-05 at 08:32 -0600, Jan Beulich wrote:

> > ! It appears to me that the idea of nested ownership, would maybe be clearer
> > ! and better set expectations. It is also consistent with the expectation
> > ! of "meritocracy". This may in turn may better set expectations
> > ! for contributors. It is unclear, whether we need to change governance at 
> > ! this stage: maybe a good starting point would be to work together on
> > ! "A guide (or best practices) for maintainers" and maybe clarify some 
> > things
> > ! in the MAINTAINERS file in parallel. We could also work together on a "A 
> > ! guide  (or best practices) for committers". It may well turn out, that 
> > the 
> > ! latter is slim, if we can separate the hats committers wear more clearly. 
> > ! If then there are discrepancies, we can still change the governance, if 
> > ! needed. 
> 
> Well, we already have ways to express nested vs non-nested
> maintainership in ./MAINTAINERS - via the X: prefix. Maybe we
> should make broader use of it. Despite seeing all the responses
> and comments I still think that (at least as far as I'm concerned)
> maintainers are equal, i.e. a more narrow scope maintainer's ack
> is sufficient for a change to go in, regardless of X: use. Of course
> that doesn't rule out the wider scope maintainer requesting
> changes despite the other's ack, but that's symmetrical: For a
> change to go in, no maintainer should disagree (and in fact
> reasonable disagreement by a non-maintainer counts too).
> 
> By formalizing nested maintainership and requiring ack-s from
> each one in the hierarchy we will just further slow down things.
> If a maintainer doesn't trust a sub-maintainer, the question
> needs to be raised whether the sub-maintainer was nominated
> prematurely, or whether conditions changed after nomination
> that warrant reverting that state.

I don't think it is a matter of trust, just that the support for some
feature/subsystem is just one part of a larger whole and while the
maintainer of that feature might be entirely trusted/empowered WRT that
area it still interacts with the larger whole. Unfortunately this is not
always expressible at a file granularity.

Taking libxl as an example, the are certainly features in there which have
a specific maintainer whose ack is all that is needed WRT that feature, but
some patches also need to be considered in light of the larger whole of the
entire library e.g things like:

 * API consistency
    * consistent function naming in the public API
    * common argument patterns
    * use of error codes
    * not breaking API stability
    * suitability for on going support as a stable API
 * Coding Style issues
    * the error handling idiom
    * memory allocation idiom
 * Interactions with the rest of the library
    * the asynchronous operations framework
    * ...

Now arguably any maintainer of a piece of libxl ought to be familiar with
all of that. But, personally I don't think that is very reasonable either
as a burden for those feature maintainers or particularly as a strategy for
ensuring the library remains coherent.

I included "the asynchronous operations framework" deliberately because it
is a quite complex thing which I don't think we can expect all maintainers
who support code within libxl to be intimately familiar with.

Even for the more "every day" stuff I listed above I think it is not
uncommon that the majority of the complexity for some feature is in the
hypervisor, but that it needs exposing up through the toolstack. The
maintainer of that feature mayor may not own it all the way up to the
toolstack level but it would be quite reasonable for them to do so, but
they still may not be completely up to speed on all the above.

Some care is needed on behalf of the "library reviewers" in terms of not
stepping on the toes of the feature maintainer wrt code which is only
relevant to the feature and/or making it clear when one is raising an issue
with that hat vs. just being another 3rd party who the feature maintainer
is free to ignore. This conversation has certainly made me more aware of
this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel