Exactly Rajani, and other solutions are possible. The issue is not how branches are called ;)
On Wed, Aug 6, 2014 at 8:29 AM, Rajani Karuturi <rajani.karut...@citrix.com> wrote: > I am just wondering if the shift to a new develop branch is causing the > problems. Its a simple branch shift and should be no different from the > current master. > > may be we should leave the master as is and create a ‘stable' branch which > would act like master in git-flow ? > > ie) > ACS master -> develop in git-flow > ACS stable -> master in git-flow > > > ~Rajani > > > > On 06-Aug-2014, at 10:56 am, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > >> Hello devs and especially committters, >> >> I see some -1s coming by, days after the vote was closed. That is >> disturbing as it means we accepted a proposal that will not be >> supported by the community. So let me try to find that support in >> hindsight; >> >> The argument of Animesh that we are shifting the burden from one >> branch to another is real and present danger. I share his concern. It >> is not the only feature of this proposal and in it self does not >> warrant a -1. It does not worsen the situation at hand or add to our >> workload in any way. If there is no advantage to you and no >> disadvantage either then why -1 something that others do find useful? >> This is 'kind of' a rhetorical question. It is a real concern, however >> though not the biggest at this moment. >> >> branching is recommended but as people are rightfully wondering >> "should I make a branch for a single line fix". I would, probably but >> maybe not always. That doesn't mean you must. In case you are making a >> fix on a release then yes you do. It is how the git-flow workflow >> goes. >> >> Committers can merge and commit where ever they feel the need. That >> doesn't exempt them from thinking if it is a good idea. It doesn't now >> and it won't in the future. Doing what your boss tells you to do can >> be a crime! >> >> Reverting something should only be done when the code that is a >> culprit has been identified. Reverting a big change or even a bunch of >> changes is a cowards way out. We shouldn't do it now or using gitflow. >> It is not really related to git flow or its use. So we shouldn't >> penalize developers that didn't cause a problem or ones that did. We >> should help them help us make a better system. >> >> The question of why this process isn't implemented on master is valid. >> It could. It isn't however. It is a choice the authors of gitflow >> made. I think it is not really the time anymore to be nitpicking about >> this. Unless we find a very valid reason to alter the accepted >> proposal we should all try and implement it as good as possible. I >> have been RM for 4.4.0 and one thing I don't want anymore is people >> share a 4.4-forward to cherry-pick commits from. It caused me a lot of >> headaches. >> >> The release is what drives the merges back to master according to >> git-flow. We can decide that we define a number of prerelease dates at >> which we merge as well. We don't have to do it at that date but can >> decide to do that the next day or week as well. This would kind of >> resemble Alena's #1 (as opposed to the more pure gitflow #2). An >> argument for #2 is that I don't think every customer greps the rpms >> for some release. I know our operators at Schuberg Philis investigate >> the code and check it out from git. They like to compare release and >> look at the latest easily. just checking out master would be very >> convenient for them. Of course they can check out a branch as well. >> But I doubt if they know exactly what to checkout then. I usually see >> them just look at the latest for a branch. >> >> All in all, I am very skeptic on whether this will work as planned. It >> is us who need to work neatly and only if we do that we can help >> ourselves with improving our process. I do feel that the present way >> of working, mainly the use forward branches but in general the lack of >> using branches to test individual changes, is hindering us in doing >> releases. The proposal at hand is very good but can only work if >> supported by the people that need to work with it. It doesn't do our >> release process for us. We still need to do it and not just program >> some code and check it in. That will never work in any process. Your >> code is not done until somebody somewhere finds it worth running it in >> a production environment. So let's keep discussing and educating each >> other. >> >> done ranting, feel free to react or contact me in person >> Daan >> >> >> On Wed, Aug 6, 2014 at 3:15 AM, David Nalley <da...@gnsa.us> wrote: >>> On Tue, Aug 5, 2014 at 7:44 PM, Erik Weber <terbol...@gmail.com> wrote: >>> >>>> On Wed, Aug 6, 2014 at 12:55 AM, Prachi Damle <prachi.da...@citrix.com> >>>> wrote: >>>> >>>>> I fail to understand how will this model help us with the maintenance >>>>> releases? >>>>> >>>>> >>>> That's what gitflow support branches is for. >>>> I find this quite descriptive: >>>> >>>> https://groups.google.com/forum/#!msg/gitflow-users/I9sErOSzYzE/AwVH06CuKT0J >>>> >>>> >>>> >>>>> For CloudStack we also keep working on prior releases and ship out >>>>> maintenance releases. >>>>> I suppose we will be cutting the maintenance releases from the release >>>>> branches? So we will have to keep around the release branches for that >>>>> purpose. >>>>> >>>>> >>>> I've asked earlier, but what is the policy on old releases? How long do we >>>> support them? >>>> >>>> >>> Today (e.g. subject to change) we claim to support as a community the two >>> most recent feature releases. (for instance, we just stopped support the >>> 4.2.x line with the release of 4.4.0, and currently support 4.3.x and >>> 4.4.x) We support those feature releases with bug fix releases that contain >>> no additional functionality. >>> >>> --David >> >> >> >> -- >> Daan > -- Daan
