On Thu, May 19, 2016 at 11:42 AM, Raghavendra Talur <rtalur@xxxxxxxxxx> wrote: > > > On Thu, May 19, 2016 at 11:39 AM, Kaushal M <kshlmster@xxxxxxxxx> wrote: >> >> On Thu, May 19, 2016 at 11:35 AM, Kaushal M <kshlmster@xxxxxxxxx> wrote: >> > On Thu, May 19, 2016 at 11:29 AM, Raghavendra Talur <rtalur@xxxxxxxxxx> >> > wrote: >> >> >> >> >> >> On Thu, May 19, 2016 at 11:13 AM, Kaushal M <kshlmster@xxxxxxxxx> >> >> wrote: >> >>> >> >>> I'm in favour of a stable release every 2 months and an LTS once a >> >>> year (option 2). >> >> >> >> >> >> +1 >> >> >> >>> >> >>> >> >>> As Oleksander already suggested, I'm in favour of having well defined >> >>> merge windows, freeze dates and testing period. >> >>> (A slightly modified timeline from Oleksander's proposal follows) >> >>> For every 2 month window, >> >>> - 1 month of development (merge window). New features will not be >> >>> accepted post this period. >> >>> - At the end of the development period a release-candidate 1 is >> >>> tagged. >> >>> - A 1 month testing/bug-fixing window follows. This time is for >> >>> testing and fixing bugs found. >> >>> Feature development and reviews can happen during this period on >> >>> gerrit, but nothing gets merged. Merges will be held till the next >> >>> merge window. >> >> >> >> >> >> This means the branching is not done at the end of merge window and the >> >> patches will not be merged even on the master branch. Is that right? >> > >> > There will be no branching at all (except for the LTS release). We >> > have just 2 branches, >> > one LTS and one stable. >> > All features (even those partially developed) can get merged in during >> > the merge window. >> > During the stability window, the partially developed and unstable >> > features get disabled. >> > This requires us to properly implement a feature flags framework, >> > that allows features to be selectively compiled. >> >> Just to be more complete, if any urgent fixes are required for any >> released version, >> an emergency branch will be created from the tag for the release, >> which will only >> contain the required fixes. These fixes will have to land on the >> stable branch before >> being backported to a emergency branch. > > > I would prefer if this was relaxed a bit. Rather than placing a requirement > of a bug fix in a released branch to be backported it to LTS, I would prefer > having it in *next* release is ok(i.e merging in stable branch). The stable branch is the release branch. The fix needs to be in the branch, not necessarily in a release. > >> >> >> > >> >> >> >>> - At least 2 more release-candidates will be release once every >> >>> fortnight >> >>> - The final release-candidate becomes the release if it passes all our >> >>> tests. >> >>> >> >>> One of the 6 releases of the year will become a LTS release. >> >>> The 2 month window for this release will mainly be targeted at making >> >>> the release stable. >> >>> New features should be minimal for this release. >> >> >> >> >> >> I really like this point. Taking 3.8 as a LTS release this would mean >> >> new >> >> features for 3.14 release would not be encouraged. >> >> >> >>> >> >>> >> >>> During every 2 month window, the LTS release will get any required bug >> >>> fixes and stability improvements backported. >> >>> For fix to be backported it needs to be present in a stable release. >> >> >> >> >> >> +1 >> >> >> >>> >> >>> >> >>> ~kaushal >> >>> >> >>> On Wed, May 18, 2016 at 11:46 PM, Atin Mukherjee <amukherj@xxxxxxxxxx> >> >>> wrote: >> >>> > A bit late but better than never. My vote is for option 2. >> >>> > >> >>> > ~Atin >> >>> > >> >>> > On 05/18/2016 07:19 PM, Vijay Bellur wrote: >> >>> >> [Adding gluster-users] >> >>> >> >> >>> >> I would like to wrap this poll by the next community meeting on >> >>> >> 25th >> >>> >> May. Can you please weigh in with your opinions on the options >> >>> >> provided by Aravinda? >> >>> >> >> >>> >> Thanks! >> >>> >> Vijay >> >>> >> >> >>> >> >> >>> >> On Fri, May 13, 2016 at 4:16 AM, Aravinda <avishwan@xxxxxxxxxx> >> >>> >> wrote: >> >>> >>> Hi, >> >>> >>> >> >>> >>> Based on the discussion in last community meeting and previous >> >>> >>> discussions, >> >>> >>> >> >>> >>> 1. Too frequent releases are difficult to manage.(without >> >>> >>> dedicated >> >>> >>> release >> >>> >>> manager) >> >>> >>> 2. Users wants to see features early for testing or POC. >> >>> >>> 3. Backporting patches to more than two release branches is pain >> >>> >>> >> >>> >>> Enclosed visualizations to understand existing release and support >> >>> >>> cycle and >> >>> >>> proposed alternatives. >> >>> >>> >> >>> >>> - Each grid interval is 6 months >> >>> >>> - Green rectangle shows supported release or LTS >> >>> >>> - Black dots are minor releases till it is supported(once a month) >> >>> >>> - Orange rectangle is non LTS release with minor releases(Support >> >>> >>> ends >> >>> >>> when >> >>> >>> next version released) >> >>> >>> >> >>> >>> Enclosed following images >> >>> >>> 1. Existing Release cycle and support plan(6 months release cycle, >> >>> >>> 3 >> >>> >>> releases supported all the time) >> >>> >>> 2. Proposed alternative 1 - One LTS every year and non LTS stable >> >>> >>> release >> >>> >>> once in every 2 months >> >>> >>> 3. Proposed alternative 2 - One LTS every year and non LTS stable >> >>> >>> release >> >>> >>> once in every 3 months >> >>> >>> 4. Proposed alternative 3 - One LTS every year and non LTS stable >> >>> >>> release >> >>> >>> once in every 4 months >> >>> >>> 5. Proposed alternative 4 - One LTS every year and non LTS stable >> >>> >>> release >> >>> >>> once in every 6 months (Similar to existing but only alternate one >> >>> >>> will >> >>> >>> become LTS) >> >>> >>> >> >>> >>> Please do vote for the proposed alternatives about release >> >>> >>> intervals >> >>> >>> and LTS >> >>> >>> releases. You can also vote for the existing plan. >> >>> >>> >> >>> >>> Do let me know if I missed anything. >> >>> >>> >> >>> >>> regards >> >>> >>> Aravinda >> >>> >>> >> >>> >>> On 05/11/2016 12:01 AM, Aravinda wrote: >> >>> >>> >> >>> >>> I couldn't find any solution for the backward incompatible >> >>> >>> changes. As >> >>> >>> you >> >>> >>> mentioned this model will not work for LTS. >> >>> >>> >> >>> >>> How about adopting this only for non LTS releases? We will not >> >>> >>> have >> >>> >>> backward >> >>> >>> incompatibility problem since we need not release minor updates to >> >>> >>> non >> >>> >>> LTS >> >>> >>> releases. >> >>> >>> >> >>> >>> regards >> >>> >>> Aravinda >> >>> >>> >> >>> >>> On 05/05/2016 04:46 PM, Aravinda wrote: >> >>> >>> >> >>> >>> >> >>> >>> regards >> >>> >>> Aravinda >> >>> >>> >> >>> >>> On 05/05/2016 03:54 PM, Kaushal M wrote: >> >>> >>> >> >>> >>> On Thu, May 5, 2016 at 11:48 AM, Aravinda <avishwan@xxxxxxxxxx> >> >>> >>> wrote: >> >>> >>> >> >>> >>> Hi, >> >>> >>> >> >>> >>> Sharing an idea to manage multiple releases without maintaining >> >>> >>> multiple release branches and backports. >> >>> >>> >> >>> >>> This idea is heavily inspired by the Rust release model(you may >> >>> >>> feel >> >>> >>> exactly same except the LTS part). I think Chrome/Firefox also >> >>> >>> follows >> >>> >>> the same model. >> >>> >>> >> >>> >>> http://blog.rust-lang.org/2014/10/30/Stability.html >> >>> >>> >> >>> >>> Feature Flag: >> >>> >>> -------------- >> >>> >>> Compile time variable to prevent compiling featurerelated code >> >>> >>> when >> >>> >>> disabled. (For example, ./configure--disable-geo-replication >> >>> >>> or ./configure --disable-xml etc) >> >>> >>> >> >>> >>> Plan >> >>> >>> ----- >> >>> >>> - Nightly build with all the features enabled(./build --nightly) >> >>> >>> >> >>> >>> - All new patches will land in Master, if the patch belongs to a >> >>> >>> existing feature then it should be written behind that feature >> >>> >>> flag. >> >>> >>> >> >>> >>> - If a feature is still work in progress then it will be only >> >>> >>> enabled >> >>> >>> in >> >>> >>> nightly build and not enabled in beta or stable builds. >> >>> >>> Once the maintainer thinks the feature is ready for testing >> >>> >>> then >> >>> >>> that >> >>> >>> feature will be enabled in beta build. >> >>> >>> >> >>> >>> - Every 6 weeks, beta branch will be created by enabling all the >> >>> >>> features which maintainers thinks it is stable and previous >> >>> >>> beta >> >>> >>> branch will be promoted as stable. >> >>> >>> All the previous beta features will be enabled in stable unless >> >>> >>> it >> >>> >>> is marked as unstable during beta testing. >> >>> >>> >> >>> >>> - LTS builds are same as stable builds but without enabling all >> >>> >>> the >> >>> >>> features. If we decide last stable build will become LTS >> >>> >>> release, >> >>> >>> then the feature list from last stable build will be saved as >> >>> >>> `features-release-<NUM>.yaml`, For example: >> >>> >>> features-release-3.9.yaml` >> >>> >>> Same feature list will be used while building minor releases >> >>> >>> for >> >>> >>> the >> >>> >>> LTS. For example, `./build --stable --features >> >>> >>> features-release-3.8.yaml` >> >>> >>> >> >>> >>> - Three branches, nightly/master, testing/beta, stable >> >>> >>> >> >>> >>> To summarize, >> >>> >>> - One stable release once in 6 weeks >> >>> >>> - One Beta release once in 6 weeks >> >>> >>> - Nightly builds every day >> >>> >>> - LTS release once in 6 months or 1 year, Minor releases once in 6 >> >>> >>> weeks. >> >>> >>> >> >>> >>> Advantageous: >> >>> >>> ------------- >> >>> >>> 1. No more backports required to different release branches.(only >> >>> >>> exceptional backports, discussed below) >> >>> >>> 2. Non feature Bugfix will never get missed in releases. >> >>> >>> 3. Release process can be automated. >> >>> >>> 4. Bugzilla process can be simplified. >> >>> >>> >> >>> >>> Challenges: >> >>> >>> ------------ >> >>> >>> 1. Enforcing Feature flag for every patch >> >>> >>> 2. Tests also should be behind feature flag >> >>> >>> 3. New release process >> >>> >>> >> >>> >>> Backports, Bug Fixes and Features: >> >>> >>> ---------------------------------- >> >>> >>> - Release bug fix - Patch only to Master, which will be available >> >>> >>> in >> >>> >>> next beta/stable build. >> >>> >>> - Urgent bug fix - Patch to Master and Backport to beta and stable >> >>> >>> branch, and early release stable and beta build. >> >>> >>> - Beta bug fix - Patch to Master and Backport to Beta branch if >> >>> >>> urgent. >> >>> >>> - Security fix - Patch to Master, Beta and last stable branch and >> >>> >>> build >> >>> >>> all LTS releases. >> >>> >>> - Features - Patch only to Master, which will be available in >> >>> >>> stable/beta builds once feature becomes stable. >> >>> >>> >> >>> >>> FAQs: >> >>> >>> ----- >> >>> >>> - Can a feature development take more than one release cycle(6 >> >>> >>> weeks)? >> >>> >>> Yes, the feature will be enabled only in nightly build and not in >> >>> >>> beta/stable builds. Once the feature is complete mark it as >> >>> >>> stable so that it will be included in next beta build and stable >> >>> >>> build. >> >>> >>> >> >>> >>> >> >>> >>> --- >> >>> >>> >> >>> >>> Do you like the idea? Let me know what you guys think. >> >>> >>> >> >>> >>> This reduces the number of versions that we need to maintain, >> >>> >>> which I >> >>> >>> like. >> >>> >>> Having official test (beta) releases should help get features out >> >>> >>> to >> >>> >>> testers hand faster, >> >>> >>> and get quicker feedback. >> >>> >>> >> >>> >>> One thing that's still not quite clear to is the issue of >> >>> >>> backwards >> >>> >>> compatibility. >> >>> >>> I'm still thinking it thorough and don't have a proper answer to >> >>> >>> this >> >>> >>> yet. >> >>> >>> Would a new release be backwards compatible with the previous >> >>> >>> release? >> >>> >>> Should we be maintaining compatibility with LTS releases with the >> >>> >>> latest release? >> >>> >>> >> >>> >>> Each LTS release will have seperate list of features to be >> >>> >>> enabled. If >> >>> >>> we >> >>> >>> make any breaking changes(which are not backward compatible) then >> >>> >>> it >> >>> >>> will >> >>> >>> affect LTS releases as you mentioned. But we should not break >> >>> >>> compatibility >> >>> >>> unless it is major version change like 4.0. I have to workout how >> >>> >>> we >> >>> >>> can >> >>> >>> handle backward incompatible changes. >> >>> >>> >> >>> >>> With our current strategy, we at least have a long term release >> >>> >>> branch, >> >>> >>> so we get some guarantees of compatibility with releases on the >> >>> >>> same >> >>> >>> branch. >> >>> >>> >> >>> >>> As I understand the proposed approach, we'd be replacing a stable >> >>> >>> branch with the beta branch. >> >>> >>> So we don't have a long-term release branch (apart from LTS). >> >>> >>> >> >>> >>> Stable branch is common for LTS releases also. Builds will be >> >>> >>> different >> >>> >>> using different list of features. >> >>> >>> >> >>> >>> Below example shows stable release once in 6 weeks, and two LTS >> >>> >>> releases in >> >>> >>> 6 months gap(3.8 and 3.12) >> >>> >>> >> >>> >>> LTS 1 : 3.8 3.8.1 3.8.2 3.8.3 3.8.4 3.8.5... >> >>> >>> LTS 2 : 3.12 3.12.1... >> >>> >>> Stable: 3.8 3.9 3.10 3.11 3.12 3.13... >> >>> >>> >> >>> >>> A user would be upgrading from one branch to another for every >> >>> >>> release. >> >>> >>> Can we sketch out how compatibility would work in this case? >> >>> >>> >> >>> >>> User will not upgrade from one branch to other branch, If user >> >>> >>> interested in >> >>> >>> stable channel then upgrade once in 6 weeks. (Same as minor update >> >>> >>> in >> >>> >>> current release style) >> >>> >>> >> >>> >>> >> >>> >>> This approach work well for projects like Chromium and Firefox, >> >>> >>> single >> >>> >>> system apps >> >>> >>> which generally don't need to be compatible with the previous >> >>> >>> release. >> >>> >>> I don't understand how the Rust project uses this (I am yet to >> >>> >>> read >> >>> >>> the linked blog post), >> >>> >>> as it requires some sort of backwards compatibility. But it too is >> >>> >>> a >> >>> >>> single system app, >> >>> >>> and doesn't have the compatibility problems we face. >> >>> >>> >> >>> >>> Gluster is a distributed system, that can involve multiple >> >>> >>> different >> >>> >>> versions interacting with each other. >> >>> >>> This is something we need to think about. >> >>> >>> >> >>> >>> I need to think about compatibility, What new problems about the >> >>> >>> compatibility with this approach compared to our existing release >> >>> >>> plan? >> >>> >>> >> >>> >>> >> >>> >>> We could work out some sort of a solution for this though. >> >>> >>> It might be something very obvious I'm missing right now. >> >>> >>> >> >>> >>> ~kaushal >> >>> >>> >> >>> >>> -- >> >>> >>> regards >> >>> >>> Aravinda >> >>> >>> >> >>> >>> _______________________________________________ >> >>> >>> Gluster-devel mailing list >> >>> >>> Gluster-devel@xxxxxxxxxxx >> >>> >>> http://www.gluster.org/mailman/listinfo/gluster-devel >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> _______________________________________________ >> >>> >>> Gluster-devel mailing list >> >>> >>> Gluster-devel@xxxxxxxxxxx >> >>> >>> http://www.gluster.org/mailman/listinfo/gluster-devel >> >>> >> _______________________________________________ >> >>> >> Gluster-users mailing list >> >>> >> Gluster-users@xxxxxxxxxxx >> >>> >> http://www.gluster.org/mailman/listinfo/gluster-users >> >>> >> >> >>> > _______________________________________________ >> >>> > Gluster-devel mailing list >> >>> > Gluster-devel@xxxxxxxxxxx >> >>> > http://www.gluster.org/mailman/listinfo/gluster-devel >> >>> _______________________________________________ >> >>> Gluster-devel mailing list >> >>> Gluster-devel@xxxxxxxxxxx >> >>> http://www.gluster.org/mailman/listinfo/gluster-devel >> >> >> >> > > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
