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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-10-16 at 11:33 +0100, Lars Kurth wrote:
> > 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 

More of increasing size of "umbrella of influence/authority". Which very
likely does correlate strongly with seniority though, true.

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

Sounds about right.

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

FWIW, completely anecdotally, my QUEUE-4.7 mail folder, which where I am
currently dragging any incoming patch series which I think might at some
point require attention currently has 101 distinct threads in it, some of
which are resends etc. 

If I commit something I drag all the associated threads into my 
genericxen-devel folder). I do occasional gardening of the folder too, but there
will be some amount of stuff which has been committed by someone else or
which is otherwise "done" still sitting in there.

So I would guess that I currently have maybe 100/N series currently "on my
radar" in one way or another, where N would be the average resend count
(some smallish integer I would guess).

Also as some anecdotal data about abandonment, my old QUEUE-4.6 folder
still has 90 threads in it. I switch folder around the time of the freeze
(and queue things which might be subject to a freeze exception in the old
one etc) so those are either things which I didn't spot being committed,
are abandoned or which have been reposted with the repost going into QUEUE
-4.7 and I've forgotten to retrieve the old version from QUEUE-4.6 into
QUEUE-4.7 (which I normally try to do). I'm not quite as diligent about
gardening the non-current folders though, so assume more cruft has
accumulated.

(Aside: I was thinking recently about a tool which given a Maildir and one
or more git trees would say "this looks like it might have been committed"
so I can do less gardening, this is not a request for anyone to write such
a tool though ;-))

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

There's some truth in that analogy I think ;-)

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

FWIW that's the case for some aspects of Linux too.

e.g. linux/arch/*/xen is sort of considered part of the "Xen subsystem"
along with e.g. linux/drivers/xen and not part of the linux/arch/{x86,arm}
subsystem.

Patches are still posted to both but AIUI the relevant maintainers have
arrived at a mutual understanding that stuff which doesn't stray outside of
the arch/*/xen can generally go in via the xen tree without an ack from the
arch maintainers and that the maintainers are trusted to use their
judgement as to when this might not be appropriate and not abuse it etc.

Which ultimately just comes down to allowing maintainers to use their
judgement and to talk to each other to come to a mutual understanding etc,
rather than being forced to arbitrarily follow the filesystem (or any
other) hierarchy.

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

If such a thing could be done without too many false positives and without
too much need for manually poking things by maintainers then I can see that
being a valuable, yes.

I can imagine that even just a list of "in fight" series without any sort
of mapping to maintainers or tracking of which acks it still needs etc
would potentially be valuable (won't really know till we have it though).

Ian.

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