[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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 
breaks down into backporting fixes, backporting security fixes and dealing with 
the release

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 

George: points out that unless he remembers at the time he writes or reviews a 
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 
reducing the release overhead is independent from release cadence and process. 
should be doing this irrespective depending on the cadence.**

Juergen: We could ** look at 8 months (instead of 9)it is better from a 
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 
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.