On Thu, Sep 18, 2014 at 6:19 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > On Sep 18, 2014, at 5:08 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > >> David, >> >> What do you plan to do after branching in terms of merge-back and or >> cherry-picking. We are discussing here (Schuberg-Philis + Rohit + Ian + >> Wido (+ Sebastien)) that we would like to branch after getting master >> stable and then when the real release work is underway branching of 4.5. >> All new feature development in the meanwhile would have to go in its >> respective branches until master is released again. >> >> thoughts, my dear RM? > > Yes, about we consider master the release branch and don't create a 4.5 > branch. > We declare feature freeze and we only take in bug fixes that need to come in > through bugfix/hotfix branches that you merge. >
I think considering master the release branch will work for 4.5.0 - I am not sure if it would have worked with previous releases or not. It's not the effect on master that worries me; I think the effect will actually be good. It's that the perpetuation of silos of code and keeping those silos mergeable can become a lot of work. In short; long term we need a dev branch somewhere.Our QA cycles are so long right now that we'll end up with one of two conditions - n feature branches that won't merge cleanly, and need n developers to spend copious amounts of time on keeping their silos updated OR feature developers will learn that it does little good to develop early, so they'll wait till the last possible moment to push a feature. The problem is worse for non-committers - getting their feature committed to a feature branch and then being unable to maintain it. > Folks developing features can do so on their own branch (that they can rebase > on master right now), and they pull in the same bugfix/hotfix. > > This has the benefit of stabilizing master and getting it into a releasable > state. Then when 4.5 is released, the features can be merged back and we can > create a clean 4.6. > > Currently master is never releasable, and the effort going into our release > branches don't all make it back to master. Hence all our releases are based > on unstable work. As a community we don't currently have what it takes to run > a QA effort to stabilize a release branch. > > We can switch that around, make our releases based on an already stable > (released) branch and develop future features based on that released product. > > To re-iterate: > > *To make that switch we can delay 4.5, stabilize master (as if it where 4.5) > with clean merging of bug fixes branches. Devs can bring in those same > changes on their own branch to stay in sync with the stabilization process. > > *Once master is stable, we pretty much have our 4.5 but all other branches > should have benefited from it. > > *We can then start creating 4.6 by merging the features that are ready > > *We then adopt a gitflow'esque model for patching master/4.5 and trickling > all that down to all branches. > > *When 4.6 is ready we merge back into master…. > > *We get closer to a linear development model with the same confidence in each > release. > So this requires some non-trivial investment by folks into keeping feature branches up to date. The divergence possible in 1-3 months of our QA cycle is not trivial just from bug fixes is not trivial. That said; I think that this is a step in the right direction; but I think long term it will need to be coupled with lots of automation and testing, and strict behavior around enforcing quality. This likely means that we'll need a small army of quality fascists who take a serious interest in quality, and are liberal with vetoes and reverts until we get something that automates gating on quality. --David > -sebastien > >> >> On Thu, Sep 18, 2014 at 4:32 AM, David Nalley <da...@gnsa.us> wrote: >> >>> Hi folks, >>> >>> 4.3.1 is out the door now, so I am trying to get things lined up around >>> 4.5.0. >>> >>> Please consider us in feature freeze right now - and my plan is to >>> branch 4.5.0 this coming weekend. I'd like to see us hit code freeze >>> by end of October. Right now, we have 4 blocker bugs and 63 critical >>> bugs for the 4.5.0 release, so we have plenty to fix. >>> >>> If any of these elements cause you concern, please say so. >>> >>> --David >>> >> >> >> >> -- >> Daan >
