[Gluster-devel] [Gluster-users] Idea: Alternate Release process

Kaushal M kshlmster at gmail.com
Thu May 19 06:18:13 UTC 2016 

On Thu, May 19, 2016 at 11:42 AM, Raghavendra Talur <rtalur at redhat.com> wrote:
>
>
> On Thu, May 19, 2016 at 11:39 AM, Kaushal M <kshlmster at gmail.com> wrote:
>>
>> On Thu, May 19, 2016 at 11:35 AM, Kaushal M <kshlmster at gmail.com> wrote:
>> > On Thu, May 19, 2016 at 11:29 AM, Raghavendra Talur <rtalur at redhat.com>
>> > wrote:
>> >>
>> >>
>> >> On Thu, May 19, 2016 at 11:13 AM, Kaushal M <kshlmster at gmail.com>
>> >> 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 at redhat.com>
>> >>> 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 at redhat.com>
>> >>> >> 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 at redhat.com>
>> >>> >>> 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 at gluster.org
>> >>> >>> http://www.gluster.org/mailman/listinfo/gluster-devel
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> _______________________________________________
>> >>> >>> Gluster-devel mailing list
>> >>> >>> Gluster-devel at gluster.org
>> >>> >>> http://www.gluster.org/mailman/listinfo/gluster-devel
>> >>> >> _______________________________________________
>> >>> >> Gluster-users mailing list
>> >>> >> Gluster-users at gluster.org
>> >>> >> http://www.gluster.org/mailman/listinfo/gluster-users
>> >>> >>
>> >>> > _______________________________________________
>> >>> > Gluster-devel mailing list
>> >>> > Gluster-devel at gluster.org
>> >>> > http://www.gluster.org/mailman/listinfo/gluster-devel
>> >>> _______________________________________________
>> >>> Gluster-devel mailing list
>> >>> Gluster-devel at gluster.org
>> >>> http://www.gluster.org/mailman/listinfo/gluster-devel
>> >>
>> >>
>
>

More information about the Gluster-devel mailing list