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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

   = Possible Solution / Improvement =

While I agree that some aspects (like coding style issues) could be
taken care of by requiring submitters to have their patches be
checked by (not yet existing) tools/scripts, I think much of this is a
problem of enforcing discipline on oneself: Sloppiness in style,
according to my observation, frequently is accompanied by
sloppiness in the actual coding. While I think that suggestion may
be considered harsh, I'd like to throw up for discussion a cut off
on the number of iterations that may be submitted for a particular
series within a certain time (with a high threshold on exceeding
the limit for really minor adjustments). I would hope that making
people aware that the number of tries they have is limited, they
would start self-reviewing their changes more consciously.

And yes (to preempt respective responses), I'm aware that such a
rule may raise the bar for first time contributors. But those often
don't contribute large patches/series, and I don't think such a rule
would need to be enforced as strictly on small contributions (plus
newcomers could be granted some [limited] slack).

And of course, people should submit their code early, and follow
up diligently to review comments. Submitting a v1 half a year
before the freeze, and being at say v4 around freeze time (and
then perhaps even demanding the code to go in because "it was
submitted early") is about as bad as starting work on a big series
a month ahead of freeze.

Jan


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