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

Combined reply to Jan and Roger
Lars

On 03/07/2018, 11:07, "Roger Pau Monne" <roger.pau@xxxxxxxxxx> wrote:

    On Mon, Jul 02, 2018 at 06:03:39PM +0000, Lars Kurth wrote:
    > We then had a discussion around why the positive benefits didn't 
materialize:
    > * Andrew and a few other believe that the model isn't broken, but that 
the issue is with how we 
    >   develop. In other words, moving to a 9 months model will *not* fix the 
underlying issues, but 
    >   merely provide an incentive not to fix them.
    > * Issues highlighted were:
    >   * 2-3 months stabilizing period is too long
    
    I think one of the goals with the 6 month release cycle was to shrink
    the stabilizing period, but it didn't turn that way, and the
    stabilizing period is quite similar with a 6 or a 9 month release
    cycle.

Right: we need to establish what the reasons are:
* One has to do with a race condition between security issues and the desire to 
cut a release which has issues fixed in it. If I remember correctly, that has 
in effect almost added a month to the last few releases (more to this one). 
* One seems to have to do with issues with OSSTEST
* <Please add other reasons>

On 03/07/2018, 08:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
     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.

  You didn't get one of my main points then: It is _contributors_ whom
  I'd expect to focus more on stabilization (in general, not just during
  freezes).

You are right: I misunderstood. You talked about people, which is ambiguous.
I am wondering how we can encourage different behaviour. Have to think about 
this. 

Lars

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