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

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

> On 6 Oct 2015, at 10:29, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> On Mon, 2015-10-05 at 23:31 +0100, Lars Kurth wrote:
>> 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).  
> 
> That's my understanding, by forwarding it to the next level a maintainer is
> in effect acking it (in fact they would normally add a S-o-b per 3(c) of
> the DCO).

Interesting. It appears to me that in Linux the hierarchy fulfils two 
functions: 
a) it is a reflection of seniority 
b) it also acts as a queuing system of patches 

So basically, once a patch or a series in Linux is ACKED at the bottom of the 
tree, it just travels up the tree until it hits Linus. There are several 
hand-overs along the way, which either involve a re-review, scan, pass-through 
based on how much the source is trusted. As a contributor, you mainly deal with 
the bottom of the hierarchy and don't have to think much about what happens 
further up the chain. 

If you contrast this with our model: we basically have a situation where we 
have one big queue (xen-devel). And each maintainer has their own queue via the 
CC field and then manages their own queue. But the actual review and ACKs 
happen on xen-devel. A review is not complete until all stake-holders 
(maintainers and/or committers which are also maintainers) signalled they are 
happy. 

Committers check whether all ACKs are there (or sufficient) and also spend some 
time doing some manual coordination, to make sure that missing ACKs and reviews 
for series that are close, get completed.

If we consider, some of the survey data on back-logs, e.g.
- Active (aka activity in the last 7 days) : 78
- Ongoing (aka activity in the last 12 months): 403
it is probably fair enough to assume that at any given time there are somewhere 
between 50-250 series undergoing reviews (assuming that the figures from the 
study are too high). 

This makes it likely that for complex series we just hit scalability issues 
with this "flat" approach. If you assume
- ACKs from a range of different maintainers are required
- Maintainers use different strategies in prioritising what to look at
- The large number of reviews that are ongoing
statistically it would take longer to complete a review, if the number of 
series undergoing reviews was much smaller. 

It's kind of like shooting paint balls (not randomly, but with some degree of 
randomness) at pieces of paper that are fixed to wall and declaring a piece 
done, when it is covered with paint and the "inspector" (committer) declares 
it's covered well enough. At that point, the piece of paper is removed. The 
bigger the wall, the longer the process takes.

I recall, that someone said that the Linux model couldn't work for us, because 
the code structure can't be as easily mapped into the tree model. And we also 
don't want to change the work-flow significantly, as most maintainers seem to 
be happy with it.

I wonder, whether there is something else we can do to focus the attention of 
"paint guns" (sorry for the analogy) at smaller portions of the wall more 
synchronously. I have not really thought this through and just wanted to put 
this out as an idea. Assuming that we can fix the mapping issues with 
incomplete reviews from the tools, it seems conceivable that we can define some 
buckets of ongoing reviews (or section the "wall") and serve them up as web 
pages to influence what reviews maintainers prioritise.

Regards
Lars



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