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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.10.15 at 00:31, <lars.kurth.xen@xxxxxxxxx> wrote:
>> On 5 Oct 2015, at 15:32, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> Of course
>> that doesn't rule out the wider scope maintainer requesting
>> changes despite the other's ack, but that's symmetrical: For a
>> change to go in, no maintainer should disagree (and in fact
>> reasonable disagreement by a non-maintainer counts too).
> 
> Isn't that merely replacing an active ACK with an objection. Of course for 
> this model to work well, we would need the equivalent of a time-out for an 
> objection. But then you could also say that no active ACK given by the 
> time-out period counts like an ACK. But then you guys deal with protocols of 
> this kind all the time and should know what is best.

Keir has always been advocating the "we can always revert", and
I support this model. Indeed there have been a few cases were
things got reverted because of late feedback.

> In fact some of the feedback from the survey suggests that the disagreements 
> that are highlighted after some time has passed cause the most grievances. 

I'm not sure I understand: How is late disagreement any worse
than immediate one?

>>> ! What is clear is that not just contribution growth is responsible
>>> ! for the bottleneck. It seems that we have *significantly* higher 
>>> expectations
>>> ! on quality today, leading to more comments and taking up more time. 
>> 
>> Which is a result from the quality issues we inherited from the time
>> when patches got committed without much review. The amount of
>> security issues is only one indicator. When I write code for a new
>> feature (which is rare enough) or review contributions, I pay close
>> attention to the code modified or needing taking into consideration,
>> frequently leading to me spotting bugs unrelated to the actual work
>> I do. While other committers and maintainers do so too afaict, the
>> majority of contributors act as if existing code is guaranteed bug
>> free; I've even seen them copy'n'paste buggy code.
>> 
>> The original model was certainly not unreasonable as long as Xen
>> was still more of a university/research project, but the transition
>> to one intended for wide production use should have happened
>> much earlier.
>> 
>> And, not to forget, the higher quality requirements also have a
>> connection to the growing size of the project, and the need to
>> keep the overall thing maintainable.
> 
> Not disagreeing. I don't think we ever had a discussion about this trade-off: 
> it sort of evolved over time, without being discussed explicitly. That may 
> well be the cause for a mismatch of expectations. 
> 
> 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.

As already kind of pointed out by Ian, doing so would lead to the
same problems we had and in some areas still have: Code added
with at best lax review gets named supported after a while
(perhaps simply on the basis of no problem sightings), and issues
found subsequently (which would likely have been found by proper
initial review) then end up being severe. Plus - the smaller the
feature, the more likely that we end up without any explicit
support statement, making the thing implicitly supported in at least
some people's eyes. It has been more than once that on the
security team we had a hard time figuring whether we could waive
the security aspect of a report because the affected code would
_seem_ to be unsupported.

Jan


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