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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 15 Feb 2017, Lars Kurth wrote:
> 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?

Yes, I think it would work

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