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

[George Dunlap <dunlapg@xxxxxxxxx>]

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.

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

 -George

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