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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.10.15 at 13:27, <lars.kurth.xen@xxxxxxxxx> wrote:
> | This causes discomfort even to me who has been working on the project for
> | almost 3 years. In practice it is not causing too much trouble for me 
> | personally, as the committers I work with never use their committer status
> | to trump my decision -- they are willing to commit patches they don't
> | agree with. But, I do understand that other contributors have had issues
> | with this.

I'd be curious of examples of this.

> | Yes, currently maintainers have no right, so why do we still need to review.
> | There should be right and duty for maintainers.

And quite a bit more so for this.

> ! We do appear to have some issues in this area, which will need to be 
> explored
> ! further. In particular because the earlier questions Q1.1 - Q1.4 imply
> ! that some sort of hierarchy based on seniority is not seen as a problem by
> ! a clear majority of respondents. I am not quite sure how to go about this, 
> ! as this is clearly an emotionally charged issue. Setting expectations 
> better, 
> ! may help, but I doubt it will fix the root cause. This, taken together with 
> ! answers to Q1.7 does also worry me: it implies a degree of inconsistency
> ! in how we work, that could be the root cause of any dissonance that was
> ! highlighted by the survey.

Agreed, but without being more specific about the issues (which
may make it unavoidable to name names) I don't see a way forward.

> ! 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.

> ! What is clear is that not just contribution growth is responsible
> ! for the bottleneck. It seems that we have *significantly* higher 
> expectations
> ! on quality today, leading to more comments and taking up more time. 

Which is a result from the quality issues we inherited from the time
when patches got committed without much review. The amount of
security issues is only one indicator. When I write code for a new
feature (which is rare enough) or review contributions, I pay close
attention to the code modified or needing taking into consideration,
frequently leading to me spotting bugs unrelated to the actual work
I do. While other committers and maintainers do so too afaict, the
majority of contributors act as if existing code is guaranteed bug
free; I've even seen them copy'n'paste buggy code.

The original model was certainly not unreasonable as long as Xen
was still more of a university/research project, but the transition
to one intended for wide production use should have happened
much earlier.

And, not to forget, the higher quality requirements also have a
connection to the growing size of the project, and the need to
keep the overall thing maintainable.

Jan


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