On Thu, Dec 6, 2018 at 12:54 PM Simon Urli <[email protected]> wrote:
> Hi all, > > I'm ok with the first proposal to reduce at 11 releases instead of 12. > I think it allows indeed to better polish the latest release and avoid > lot of stress at the end of the year. > > Now on the implem I'd agree more on your last mail, ie: > > > stopping the dev at end of November (i.e. N.10) and then do a first > bugfix release (N.10.1) for mid December and a last bugfix release > (N.10.2) from Mid December to early January (2nd or 3rd of Jan). > > than with your first one: > > > * Release N.9 at end of Nov > > * Release N.10 at end of first week of Jan. Note: N.10RC1 would be > > released mid December (about 17th of Dec to have 3 weeks of RC). > > * Release N+1.0 at end of February. Start of N+1.0 work > > > So +1 for 11 releases, the 11th released at the end of november and then > december is completely used for bugfixing releases. > +1 as well. Thanks, Marius > > My 2 cents, > Simon > > On 06/12/2018 11:17, Vincent Massol wrote: > > Hi Edy, > > > >> On 19 Nov 2018, at 19:15, Eduard Moraru <[email protected]> wrote: > >> > >> Hi, Vincent. > >> > >> +1 for the general goal of avoiding needless holiday stress. > >> > >> Now, on the details, there is something I'm struggling to understand: > >> * I see that we have 2 options for finishing N.11: > >> A) In the middle of December (i.e. 10.11RC on 10th of Dec -2w- and 10.11 > >> Final on 17 Dec -1w-), similar to what we did for 9.11.x (9.11RC1 was on > >> 11th of Dec 2017 and 9.11 Final was on 18th of Dec 2017) > > > >> B) At the beginning of January (i.e. 10.11RC on 17th of Dec -3w- and > 10.11 > >> Final on the 7th of Jan 2019 -3w-) > >> ** I would personally prefer A) in order to "close the books" before the > >> holiday season and start fresh in January. Anyone working during the > >> Holidays can start on N+1.0 or work on bugfixes for N.11.1. > >> * In both cases, N+1.0 should be same at the end of January, not > February. > >> ** Why would it have to be end of February, and thus lose a release, as > >> mentioned in your "Cons" section? > >> ** I get it if it comes as a new proposal to double the length of N.0 > to 2m > >> instead of 1 (for which I'd be +0, since I prefer less exceptions, if > >> possible), but I don't get it if we see it as a consequence of how we > >> handle holidays. > >> > >> Side note: While trying to understand how all of this works, I can't but > >> help to notice how the week-based calculations don't add up, since a > month > >> is 4.3(3) weeks long and everything planned around weeks is bound to be > >> distorted when you look at it by months. IMO, it would make more sense > to > >> reason in terms of months (synchronized with our 12 releases cycle) and > say > >> things like "last Monday of December". Not sure how easy it would be to > >> work with... just food for thought. > > > > Some comments: > > > > 1) We already work by months, see > https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki10.xCycle. When we > plan a given release we adjust (a bit more days or a bit less days) so that > it’s released before the end of the month. > > > > 2) If I sum up your proposal A) it’s about saying that the last release > would be shorter than the other ones. Say half a month vs one month (we > can’t guarantee 3 weeks vs 1 month IMO since there can be delays for the > previous release, people on early holidays, etc). > > > > Pros and cons of option A vs option B: > > > > * More logical, feel nice to have 12 releases for 12 months and to > “fully” finish the N cycle before new year starts (in practice it’s false, > see below). > > * More stressful, little margin for error and less time for the last > release > > * No time at all planned for the bug fix release we need to do for the > LTS. That’s the biggest issue for option A and what we saw in practice over > the past years: we start the new cycle at beginning of Jan and at the same > time we have to do the bug fix release for the LTS. In practice this > usually means that N+1.0 has little progress in it. > > > > Note that what we did in the past was slightly different: > > * We planned for 11 releases (and not 12). > > * We said that the end of the year (last month) was 2 stabilization > releases of 2 weeks each (no RCs). > > > > IMO if we want to fully finish by end of year we need to include at > least one bugfix release for the LTS before the end of the year, which > means stopping the dev at end of November (i.e. N.10) and then do a first > bugfix release (N.10.1) for mid December and a last bugfix release (N.10.2) > from Mid December to early January (2nd or 3rd of Jan). > > > > I am under the impression that option B) (the one I proposed) would be > less stressful. It comes at the expense of 1 release less but I’m not sure > that this would be a huge issue. > > > > @Devs: what would you prefer? > > > > Thanks > > -Vincent > > > > PS: We need to hurry to decide if we want to put this in place in the > coming days… Might be too late already for some options. > > > > > >> > >> Thanks, > >> Eduard > >> > >> > >> > >> On Mon, Nov 19, 2018 at 6:13 PM Vincent Massol <[email protected]> > wrote: > >> > >>> Hi devs, > >>> > >>> Some devs mentioned it’s too hard to release the N.11 release since it > >>> happens around Christmas every year. > >>> > >>> Here’s a proposal: > >>> > >>> * Shorten the cycle to 11 releases instead of 12. > >>> * Release N.9 at end of Nov > >>> * Release N.10 at end of first week of Jan. Note: N.10RC1 would be > >>> released mid December (about 17th of Dec to have 3 weeks of RC). > >>> * Release N+1.0 at end of February. Start of N+1.0 work > >>> > >>> Pros: > >>> * No release during Christmas, yeah :) > >>> * More time to prepare the first LTS bugfix release, i.e. N.10.1, which > >>> can be done during the month of January. > >>> * More time for the first released of N+1 (i.e. N+1.0). This is > important > >>> since that’s the release where we can do heavy refactoring and it’s > not bad > >>> to get some more time. > >>> > >>> Cons: > >>> * One less release > >>> > >>> WDYT? Do you see other cons? > >>> > >>> Thanks > >>> -Vincent > >>> > >>> > > > > -- > Simon Urli > Software Engineer at XWiki SAS > [email protected] > More about us at http://www.xwiki.com >
