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

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

> On 5 Oct 2015, at 15:32, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
>> ! 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.

Maybe the best approach would be for people to come forward with examples. But 
I can't make that decision for them.

Alternatively, the code review data may provide some more insights when done. I 
shared what I have for now in a separate thread. The plan is to have a more 
detailed report for the next Advisory Board on Oct the 20th, with an analysis / 
executive summary. We can then look into investigation areas and/or create 
tooling that allows us to do regular reporting.

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

I don't think we were ever really clear what whose ACK is or should be 
necessary and/or sufficient. 

I think that that notion would frame the concept of a hierarchy more clealry: 
it would be good to understand what happens in practice today and whether 
current practice is consistent across the community.

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

Isn't that merely replacing an active ACK with an objection. Of course for this 
model to work well, we would need the equivalent of a time-out for an 
objection. But then you could also say that no active ACK given by the time-out 
period counts like an ACK. But then you guys deal with protocols of this kind 
all the time and should know what is best.

In fact some of the feedback from the survey suggests that the disagreements 
that are highlighted after some time has passed cause the most grievances. 

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

That is a very valid point: some of this was also raised in another part of the 
survey (part 2, which tries to explore whether maybe there are trust issues).

I am not sure whether the hierarchy would require everyone to ACK. As far as I 
understand Linux does this without (but I suppose the ACK is replaced by a pull 
request the next level up the hierarchy, which sort of is like one).  

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

Not disagreeing. I don't think we ever had a discussion about this trade-off: 
it sort of evolved over time, without being discussed explicitly. That may well 
be the cause for a mismatch of expectations. 

I also think that for some areas of code (e.g. if experimental and sufficiently 
modular) a more relaxed approach may well be acceptable until it is more widely 
adopted. Maybe we can also link this to the "Feature Lifecycle Maturity" 
proposal I made a while back.

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