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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 03/07/2018, 08:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

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

I think no one is talking about RC1. My expectation would be around a month or 
so after the freeze (aka half-way during the freeze period). In practice we 
seem to be opting for the last or second last RC today.
    
    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.

That is understood: if the project leadership agrees, then this is no issue, as 
committers essentially are the gate keepers for what goes in. So in other 
words, if committers are mainly focussing on getting a release out, necessarily 
even if master is open during hardening, development would still be slower than 
before. I don't think any contributors would have an issue with this.
    
    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.
    
What would speak against elevating the more active maintainers to committers 
(maybe on probation for a fixed time period, not yet responsible for THE REST). 
Would this help in your view?

Regards
Lars
    

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