[Gluster-devel] [Gluster-users] Idea: Alternate Release process
Raghavendra Talur
rtalur at redhat.com
Thu May 19 06:12:53 UTC 2016
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).
>
> >
> >>
> >>> - 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
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160519/b1a61338/attachment-0001.html>
More information about the Gluster-devel
mailing list