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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> 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.
 
> 
>> C) Poor communication: the community didn't read Wei's emails on the change 
>> of the release process and was surprised by it
> 
> How is people not reading mails poor communication?

At some point we have to draw a line. It's understandable that someone may 
forget about an announcement made a few months back. If the same reminder comes 
every month and people don't read these mails, then they only have themselves 
to blame. 

>>>  = Possible Solution / Improvement =
>>> [...]
>> A few other possible solutions, which may help alleviate the freeze point 
>> crunch may be:
>> 
>> == 1) Highlight any changes to the process in the release manager's 
>> boilerplate in every release mail ==
>> 
>> This would fix C)
> 
> Would it? People not reading mails means people not reading mails.

See above. At least, we would have done our best. It would also cover us for 
the case, where someone started following the list *after* we made a change 
such as the hard freeze.

>> == 2) Get rid of freeze extensions altogether ==
>> 
>> This should shorten the stressful period a little; albeit the effect may be 
>> that the stress may start somewhat earlier and help with A)
>> Even though in the short term, this may not immediately lead to contributors 
>> planning to get patches in at the beginning of the release cycle, in the 
>> long 
>> run, this should do it. 
> 
> I think there's always going to be reasons for making exceptions.
> We may be able to further limit their amount, but I don't think it's
> realistic to exclude them altogether.

I just put this out there. Maybe the case, is for making them more exceptional.

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

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

>> == 4) Better upfront planning of what is desired to be in a release. In 
>> particular for larger patches. ==
> 
> Yeah, as you say multiple times further down - this can be tried, but it's
> not clear whether this actually can work well. The main coordination
> effort should anyway inside larger contributing entities, since no matter
> how close a release is, submitting multiple large series (almost) at once
> is always going to cause frustration if dealing with the submissions is
> limited to very few people.

Agreed. I am not sure this would always work. 
But we could prompt larger contributors to highlight their priorities in the 
earlier development update mails, and track that information.
At the very best, it sets expectations earlier that there is a limit to what we 
can do close to a freeze

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