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.) - 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. 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. The timing of the 9 mo cycle could be chosen to strategically avoid holiday periods. E.g, Feb 1, May 1, Aug 1, Nov 1 (hard to miss both Dec and Aug, unfortunately). Thoughts? Counter-proposals? sage -- 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
