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 06/07/2018, 17:42, "Lars Kurth" <lars.kurth@xxxxxxxxxx> wrote:

    Hi all, (I also moved the AB to BCC)
    
    I summarized the discussion in 
https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/edit?usp=sharing
 
    
    I may have missed some things or misinterpreted them, but it looks as if 
consensus is emerging in some areas. I would like to discuss what we do for the 
4.12 release at next week's community call. As far as I can see we have a few 
options:
    * Go on as we are
    * Move to 9 months, until we fixed the underlying issues - the problem is 
that unless we get some sort of commitment 
    * Skip a release as a one-off: Set ourselves some goals that must be 
achieved in this cycle around testing - this will need some commitment from 
vendors
    
    Regards
    Lars
    
That discussion took place yesterday, including some people who were not at the 
design session, but not the complete list of people. Thus, I am copying the 
notes into here as well (and the google doc), such that everything is in one 
place.

Juergen: raises the point that keeping the release cadence at 6 months is very 
unfair on Jan
who has raised many times that the workload resulting from having to maintain 
so many
release branches would be too high. After running 6 monthly releases for some 
time, this
has in fact come true, when at the time Jan’s concerns were dismissed. The 
overhead
breaks down into backporting fixes, backporting security fixes and dealing with 
the release
mechanics.

Jan: raised the point that hardly anyone responds to calls for back-ports and 
if so, only send
change-sets and Jan do the backporting. Jan also says he suspects that people 
may not
respond to backport requests, because that would require them to backport the 
patches.

George: points out that unless he remembers at the time he writes or reviews a 
patch,
whether it is back-port worthy.

George and Andrew raised the idea that we could maintain a list of pending 
backports and
assign backport tasks to people.

Jan: maintaining releases as a single person is the most efficient way of doing 
it. A single
person doing all trees is most efficient, but then we need to restrict the 
number of trees. And
2 releases per year are too many.

Andrew: suggests that an even/odd releases model with different support cycles 
would solve
this. By doing this, we would retain the discipline of doing releases.

Juergen: this would however impose the release overhead

Andrew: agrees that we need to reduce our release overhead regardless, but this 
issue is
orthogonal from the release cadence.

**Staying at 6 months we would either have to find someone who would like to 
carry the
maintenance load, or move to a longer cadence. Also we need to make it clear 
that
reducing the release overhead is independent from release cadence and process. 
We
should be doing this irrespective depending on the cadence.**

Juergen: We could ** look at 8 months (instead of 9)it is better from a 
scheduling
perspective (working around public holidays).** ​ With an 8 month release 
cycle, the release
occurs at only 3 different dates during the calendar year, rather than the 4 
dates with a 9
month cycle. This makes planning easier for selecting dates that avoid public 
holidays. 8
months is also closer to the 6 month cycle for those preferring shorter 
cadence. An 8 month
cycle would not increase the number of concurrently supported branches when 
compared
with a 9 month cycle.

**ACTION: George will put together a survey for the committers outlining the 
issue and
trade-offs and then go from there** 

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