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