Re: [Xen-devel] [xen 4.6 retrospective] [bad] review load near freeze point

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.08.15 at 18:04, <lars.kurth.xen@xxxxxxxxx> wrote:
>> On 28 Aug 2015, at 16:21, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> 
>>> B) Not enough coordination amongst committers
>> 
>> Can you be more specific (perhaps with examples) about this one?
> 
> A few concrete example were several of Vitaly's series (I will let him point 
> out a couple of examples, as he raised this one).
> Anyone else who has such examples?
> 
> I have seen a few, but would need to get back and investigate. in particular 
> the fault-line seems to be around patches that affect both hypervisor and 
> tools. Th feedback was that there can be weeks between hypervisor and tools 
> portions of a series being reviewed, leading to lost elapsed times.

But I'm pretty convinced this isn't because of bad coordination between
maintainers (not committers btw), but because of a lack of bandwidth.
Just because reviewers for one side have the cycles doesn't means the
ones on the other side have too.

>>> == 3) Earlier hard freeze for large and risky patches ==
>>> 
>>> Another thing we could do, is have an earlier freeze point for large and 
>>> risky patches. Aka, anything of a certain size or high risk has to go in 
>>> earlier than the hard freeze, allowing for some re-work or tidy up between 
>>> that early freeze point and the final one. It could would act as a filter 
>>> and 
>>> create some focus. As such it should help with A) and B). Whether we allow 
>>> exceptions, between those two "freeze" points is an open question.
>> 
>> This sounds reasonable if we can come up with not too fuzzy a
>> definition of "large or risky" (if we leave this to the maintainers'/
>> committers'/release manager's discretion, there's always going to
>> be arguments about this).
> 
> Agreed. Without thinking this through much, here are some ideas
> 1) Large could be defined in terms of characters changed, number of files 
> touched, number of patches, ...
> 2) Risky is a lot harder. One way of looking at it may be: if some patch is 
> of a certain size, but only at revision X (say 3), then it is likely to be 
> risky

Specifically no - imo normally patches shouldn't require more than a
couple of iterations. I said that in my original mail: The quality of
submissions often isn't good enough, or else we wouldn't have to go
through so many cycles.

> The question is whether we need to consider risky at all: if the main 
> problem is review capacity, then probably starting with size may suffice

Agreed. Albeit you certainly realize there are small patches hard to
review (and possibly quite risky) and large patches that are pretty
trivial to approve.

Jan


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