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
