On Fri, Sep 22, 2017 at 3:28 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > Here is a concrete proposal for everyone to summarily shoot down (or > heartily endorse, depending on how your friday is going): > > - 9 month cycle > - enforce a predictable release schedule with a freeze date and > a release date. (The actual .0 release of course depends on no blocker > bugs being open; not sure how zealous 'train' style projects do > this.) Train projects basically commit to a feature freeze enough in advance of the expected release date that it's feasible, and don't let people fake it by rushing in stuff they "finished" the day before. I'm not sure if every-9-month LTSes will be more conducive to that or not — if we do scheduled releases, we still fundamentally need to be able to say "nope, that feature we've been saying for 9 months we hope to have out in this LTS won't make it until the next one". And we seem pretty bad at that. > - no more even/odd pattern; all stable releases are created equal. > - support upgrades from up to 3 releases back. > > This shortens the cycle a bit to relieve the "this feature must go in" > stress, without making it so short as to make the release pointless (e.g., > infernalis, kraken). (I also think that the feature pressure is much > lower now than it has been in the past.) > > This creates more work for the developers because there are more upgrade > paths to consider: we no longer have strict "choke points" (like all > upgrades must go through luminous). We could reserve the option to pick > specific choke point releases in the future, perhaps taking care to make > sure these are the releases that go into downstream distros. We'll need > to be more systematic about the upgrade testing. This sounds generally good to me — we did multiple-release upgrades for a long time, and stuff is probably more complicated now but I don't think it will actually be that big a deal. 3 releases back might be a bit much though — that's 27 months! (For luminous, the beginning of 2015. Hammer.) > Somewhat separately, several people expressed concern about having stable > releases to develop against. This is somewhat orthogonal to what users > need. To that end, we can do a dev checkpoint every 1 or 2 months > (preferences?), where we fork a 'next' branch and stabilize all of the > tests before moving on. This is good practice anyway to avoid > accumulating low-frequency failures in the test suite that have to be > squashed at the end. So this sounds like a fine idea to me, but how do we distinguish this from the intermediate stable releases? By which I mean, are we *really* going to do a stabilization branch that will never get seen by users? What kind of testing and bug fixing are we going to commit to doing against it, and how do we balance that effort with feature work? It seems like the same conflict we have now, only since the dev checkpoints are less important they'll lose more often. Then we'll end up having 9 months of scheduled work to debug for a user release instead of 5 months that slipped to 7 or 8... -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
