Hey Rohit, On Aug 6, 2014, at 9:08 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > The proposal thread warriors Rajani, Daan, Leo and others can comment and > advise [on git flow]?
Hah, “thread warrior", I like that :-) Cloudstack right now has, erm, some challenges when it comes to continuous integration and producing releases. Part of that is lack of (CI) resources, part of that is lack of discipline, part of that is lack of knowledge on how to best do these things, a big part of that is that cloudstack is a more complex software project than most so things that work elsewhere don’t work out of the box here. In the end the best advice for workflow is always along the lines of 1) figure out how your tools can assist you the best to do the work you need to do 2) use those tools in a way everyone on the team understands 3) document recommended ways of working, but do not get in the way of the person doing the work 4) prefer slow but steadily evolving processes to radical change Git is one particularly powerful tool, and more of the community learning more about its power and then applying that power to the cloudstack tree is a good thing. Votes at apache are pretty crude tools to gauge consensus, it should be a goal of communities here to need them as little as possible. You are in a happy place when halfway through some [PROPOSAL] it turns out you’ve together already done all the work being proposed and the thread can just fizzle out. Vetoes are perhaps the crudest tools available to a committer. They introduce a lot of friction into the consensus-building work. Vetoing a change to how git is (to be) used is an, erm, interesting approach, because in the end to cast a veto obliges you to know so much about git that you can plausibly defend that veto. It also obliges all other committers to educate themselves about both sides of the story, to assess whether to accept or challenge the veto. So, yesterday was a very interesting day for the cloudstack community. Seeing a veto on this stuff surprised me a lot. We have now forced ourselves to resolve something that’s difficult to resolve quickly and is normally best resolved one step at a time. So, how do you do _that_? Well, for starters I suggest simply abandoning the [VOTE] and the associated -1s; resolving vetoes ‘properly' takes too much energy. Next, retract the [PROPOSAL]. Next, abandon thoughts like “I’m -1 on a whole range of things”, or “we must solve everything before we can change anything”. I think those are really counter productive. Then get back to consensus-building small steps at a time. As for git flow. I’d advise to abandon it. (Like most of the internet...) I strongly believe using cherry picks as the basic tool for (release) branch management is one of the worst choices you can make. It’s an ok approach with svn pre 1.5 (arguably better with svn than with git), but git has merge/rebase/—ff-only/—no-ff/-i and a whole lot more DVCS power that’s all there to help out with this stuff. I strongly believe cloudstack needs to change this practice. Unfortunately I don’t know how to do _that_ well while taking only one small step at a time, so this is a change that breaks the above rule #4. If you must break that rule, better to do it as far away from a major new release as possible (i.e. now is a particularly good time). If you know lots about distributed version control and are a git expert I believe you don’t need git-flow. I see git-flow as training wheels, a mechanism to help people that are not seasoned git experts (like most of us) to get to grips with a better way of doing things. For me personally, I know quite a bit about git by now, but I am not at the point yet where I want to do everything without those training wheels. I thought that git-flow could really help our team here: since it is so extensively documented, tool-supported, and pretty widely used, it is a healthy place to start from and can really help build a lot of knowledge and branch/merge confidence quickly. But it seems that it won’t help at all...it’s probably too big a step to take at once, and so now it’s introduced unneeded friction. Whoops! So, throw it out. I don’t mind :) But. Please. Can. We. Just. Stop. Cherry. Picking!!! :-D [1] cheers, Leo [1] IANAL. YMMV. Product may contain nuts. Using 'git cherry-pick' when there are actual cherries to actually pick is fully endorsed by LSD Enterprises LTD. Picking things other than cherries voids warranty. LSD Enterprises LTD provides the Advice on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. [2] [2] Don’t Panic.
