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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.08.15 at 17:05, <lars.kurth.xen@xxxxxxxxx> wrote:
>> On 12 Aug 2015, at 09:00, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>>> On 04.08.15 at 14:52, <lars.kurth.xen@xxxxxxxxx> wrote:
>>   = Issue / Observation =
>> 
>> Maybe my memory regarding the 4.5 release has faded, but I'm
>> having the impression that 4.6 was quite a bit worse. This was at
>> parts due to the sheer number of patch series and their sizes,
>> but also because frequently they took quite a bit more than just a
>> couple of iterations.
>> 
>> Some of this is (as mentioned on past discussions) caused by too
>> little review involvement of non-maintainers (the need of which
>> exists because of limited bandwidth maintainers have for doing
>> reviews), but I think there are also quality issues here (see below).
> 
> This also came in the retrospective at the developer meeting, on Wed the 
> 19th. I believe that the following items contributed to this (I want to cover 
> the "not enough review capacity" and "quality issues" separately).
> 
> A) Too many things happening around the freeze
> B) Not enough coordination amongst committers

Can you be more specific (perhaps with examples) about this one?

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

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

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

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

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

Jan


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