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:19, George Dunlap <dunlapg@xxxxxxxxx> wrote:
> 
> On Mon, Oct 5, 2015 at 11:31 PM, Lars Kurth <lars.kurth.xen@xxxxxxxxx> wrote:
>> 
>>> 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.
> 
> My hope is that just having aired some of the concerns will help
> somewhat. People who have been silently frustrated with the status quo
> should now know that they aren't the only ones; and should be
> encouraged to bring up examples the next time they come up.  Hopefully
> also committers will be more aware of the effects of giving high
> degrees of duplicate review, and be more thoughtful about when they do
> it.

Agreed.

>> 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.
> 
> FWIW we do sort of have this already: the arinc scheduler, for
> instance, was completely self-contained, and so went in with actually
> very little review of the scheduling code itself.
> 
> Unfortunately, there are very few features which can be isolated to
> this degree.  The vast majority of features submitted recently touch
> core code which is used frequently (and so can't be isolated); and
> also includes a public interface, which is something that we have to
> be very careful to get right, because we are committed to supporting
> it for years.

I did not fully understand that this was the case: my hope was that core 
functionality may be more modular than it actually is. 

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