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