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

[Juergen Gross <jgross@xxxxxxxx>]

On 12/07/18 11:24, Lars Kurth wrote:
> 
> 
> 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** 
> 

Ping? Anything new? I'd like to know the dates for 4.12...


Juergen

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