Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.07.18 at 08:26, <jgross@xxxxxxxx> wrote:
> On 02/07/18 20:03, Lars Kurth wrote:
>>   * Too much start/stop of development - we should branch earlier (we mainly 
>> do this on the last 
>>     RC now). The serial period of development has essentially become too 
>> short. *Everyone* in the 
>>     room agreed that fixing this, is the *most important issue*.
> 
> While I'm really in favor of branching early I fear that this will even
> raise the burden on some few developers who need to backport fixes to
> the just branched off release candidate. An approach to solve this would
> be to accept a development patch only in case it is accompanied by the
> release backport.

I think that would depend on when exactly we branch and whether, as
we do now, we try to avoid doing intrusive commits until the release
was done. Generally backports to the most recent stable tree (even
after its release) are pretty simple.

The thing I'd be worried about if we branched really early (say at the
first RC) is that people would focus even less on the release branch,
but pay attention only to what they want in the next version. To be
fair, looking at "for-next" patch submissions, this hasn't been as bad
this time as it had been during the 4.10 freeze, but I'd very much
expect the situation to become worse again if we formally started
the next development period early.

Fundamentally the problem can as well be seen when looking at any
of the stable branches: The variety of authors there is significantly
more narrow than for what goes into master. I understand people
mostly care about their features, but there ought to be a certain
level of responsibility beyond that by everyone. For example, I'd
sort of expect it to be the rule rather than the exception that
people look at nearby code or code they clone, and address issues
they see. At the risk of repeating myself, a large number of the
security issues found results from paying attention to nearby code
(also during code review). Looking over the list of reporters there
very well supports my statement above regarding feature
submission authors vs bug fix ones.

Which reminds me of a related question: How do we define
maintainership? Is it really enough to ack a few patches here and
there to be considered a maintainer? To me, code maintenance
also (and perhaps first of all) means actively looking after the
code. And yes, I'm aware that an implication of the implication
here might be the undesirable situation of us having more
unmaintained code in the tree and/or even larger bodies of code
in even fewer hands. So it is (as almost always) a matter of
weighing pros and cons.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel