On 12/07/18 11:24, Lars Kurth wrote: > > > On 06/07/2018, 17:42, "Lars Kurth" <lars.ku...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
