Re: [MirageOS-devel] [win-pv-devel] [PATCH v5 3/3] Significant changes to decision making; some new roles and minor changes

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

Hi all,

I am kind of stuck on this one and wanted to pick up the discussion again. 
Apologies that it took so long.

To to summarise, we all are agreed on most sections of the proposal,
with the exception of decision making across projects. One option is to
just apply what we agreed on and leave the area which is not agreed as is.
However, that is still quite a bit of work, and won't solve the underlying
problem.

Ian's comments below summarise the situation quite clearly.

> On 2 Dec 2016, at 19:06, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Fri, 2 Dec 2016, Lars Kurth wrote:
>> On 01/12/2016 22:36, "Stefano Stabellini" <sstabellini@xxxxxxxxxx> wrote:
>> 
>>> On Thu, 1 Dec 2016, Ian Jackson wrote:
>>>> Lars Kurth writes ("Re: [PATCH v5 3/3] Significant changes to decision
>>>> making; some new roles and minor changes"):
>>>>> Maybe Ian has some views on what is better from a theoretical
>>>> viewpoint:
>>>>> Voting mechanisms are a bit of a hobby of his
>>>> 
>>>> The underlying problem here is that the reality is that the Xen
>>>> Project's by-far most important subproject is the hypervisor; that it
>>>> seems that the governance probably ought to reflect that; but that it
>>>> is difficult to do this without special casing it or providing an
>>>> objective metric of the hypervisor subproject's size.
>>>> 
>>>> I don't think it is possible to square this circle.  Our options are:
>>>> 
>>>> 1. Explicitly recognise the hypervisor subproject as special.
>>>>   (This could be done by creating a new `superproject' maturity
>>>>   category, or simply by naming it explicitly.)

I think that option is somewhat problematic.

>>>> 2. Do some kind of bodge which tries to reduce the impact of the
>>>>   potential unknown management practices of other subprojects
>>>>   (particularly, that they might appoint lots of leaders).
>>>> 
>>>> 3. Restructure the hypervisor sub-project.
>>>> 
>>>> The current proposal is (2) and has the virtue of not incentivising a
>>>> subproject to appoint lots of leaders simply to get more votes
>>>> overall.  But it is still rather weak because it has to treat the
>>>> hypervisor subproject as only one amongst many, so hypervisor leaders
>>>> are under-powered and fringe leaders over-powered.

Agreed.

As an additional note, I would like to highlight that it also has the
advantage of being consistent with the already agreed per-sub-project
leadership model. 

And that the proposed model - although not perfect - is better than what
we had before.

>>>> Another way to deal with this would be to split the hypervisor
>>>> subproject (3, above).  For example, we could create subprojects for
>>>> some subset of minios, osstest, xtf, various out-of-tree tools,...
>>>> (many of which would have only one leadership team member).

I am assuming that would mean:
- leave the proposal as it is
- in addition create a new sub-project, say "Hypervisor Infrastructure"
  or "Hypervisor Support Infrastructure" (we can debate the name later)

That would re-balance the original proposal and give hypervisor 
maintainers / committers more weight (which mostly also are in the 
hypervisor project leadership team) and thus address Stefano's concerns.

>>>> That would mean that the hypervisor-focused maintainers would get
>>>> additional votes via their other "hats".  (They would still get a vote
>>>> in the hypervisor subproject, if they have a hypervisor leadership
>>>> position too.)
>>>> 
>>>> This is perhaps less unnatural.  It still leaves fringe leaders
>>>> somewhat over-powered: this time, leaders of more-hypervisor-related
>>>> (or some such) fringe things, rather than leaders of
>>>> less-hypervisor-related fringe things.

If we look at the current repos, which could fit into there, aka
mini-os, osstest, raisin, livepatch-build-tools & xtf we would end up with the
following leadership team.

Ian Jackson (osstest)
Andrew Cooper (xtf)
George Dunlap, Stefano Stabellini (raisin) 
Ross Lagerwell, Konrad Wilk (livepatch-build-tools) 
Wei Lui (mini-os)

So it makes this very similar to the hypervisor project leadership team,
with the exception of Jan. There might be areas such as xtf, which Jan
could be potentially interested in. And if ARM support comes along for xtf, 
that would also give us a route in this direction. We could also include
others such as Doug Goldstein, who have been stepping up on some build
and quality related initiatives. 

We would have to formalise who is part of the leadership team, and who 
does what. But that would be a good idea anyway in my view.
 
>>> Istinctively, I don't like the idea of splitting up the hypervisor
>>> project in multiple projects.
>> 
>> We could split out the following git repos: mini-os, osstest, raisin,
>> livepatch-build-tools, xtf
>> In terms of contributions per release, there is more activity than Windows
>> PV Drivers, which are a separate project.
> 
> I see what you meant now. That could be OK.

I think that is the cleanest and simplest approach in my view and would 
unblock this proposal.

With this in mind, do you think, this would work?

Best Regards
Lars
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel