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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 6 Oct 2015, at 11:26, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> On Mon, 2015-10-05 at 08:32 -0600, Jan Beulich wrote:
> 
>> 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.

I am not sure whether this is really that different to other projects. In many 
ways what you listed is "architectural and stylistic coherence", which is 
something you'd expect someone more experienced to pick up, which in this case 
would be the libxl maintainer (or committer). Or maybe we can divide this up 
more clearly amongst co-maintainers for libxl, to build in some redundancy.

Or us something like "X: libel error handling idiom ... person" in MAINTAINERS

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