> -----Original Message----- > From: Nate Gordon [mailto:nate.gor...@appcore.com] > Sent: Monday, August 18, 2014 7:36 AM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Adapting git workflow for release branches > > +1 This is at least is a step in the right direction. I don't think this > goes far enough, but I'm not going to stand in the way of making forward > progress and nothing in this proposal seems to be a bad idea. > > I would also encourage those who are against this to think about if this > proposal at least moves us towards your ideal solution. If you look at most I am not sure it's towards the "ideal" solution or not. I think all we agree that current code quality control has issues(no CI, no code review). If the assumption is true, then how we gonna solve the issues? There is proposal to add gerrit as code review, but rejected by community due to issues related to Apache policy. Another Apache project is following github pull request model: http://wiki.apache.org/cordova/GitWorkflow, we could adopt this model as well, if gerrit is impossible. So you see, above two proposals have different git work flow, but they both lead to the same goal(more control on the code quality). Without thinking about the big picture, it's really not that useful to change our current work flow. If the community can agree on the basic issue(no CI, no code review) we have today, then we can move on the fix it.
> modern software development life cycles, the trend is for smaller more > frequent changes. I would rather see us make continuous small > improvements than debating forever on the ideal solution that changes > everything. > > Thanks, > > -Nate > > > On Mon, Aug 18, 2014 at 12:45 AM, Rajani Karuturi <raj...@apache.org> > wrote: > > > +1 for merges(no-ff) from stable to unstable. > > There are pros and cons of ff and no-ff. I prefer no-ff. > > > > -1 on frequent merges in RC stage. > > IMO, we shouldn't cut a release a branch until we are reasonably sure > > that we have a stable branch. Which would mean everyone working on the > release. > > once we cut the branch, we start working towards the next release and > > the release focus is lost. > > I also prefer a single merge after the release is voted. (The changes > > should be minimal) > > > > ~Rajani > > > > > > On Fri, Aug 15, 2014 at 3:55 PM, Rohit Yadav > > <rohit.ya...@shapeblue.com> > > wrote: > > > > > Hello everyone, > > > > > > With reference to my proposal on changing our release-master commit > > > flow [1], I would like to start a voting thread to decide on the > > > adoption starting 4.5 release. Any opinion, ideas, modifications is > > > welcome to > > help > > > reach a consensus and improve our present situation. > > > > > > Today’s Friday so it will be only fair to extend the voting window > > > to > > more > > > than our usual 72 hours window. > > > Therefore, we’ll end this voting on Wednesday, 20 August 2014 at > > > 18:00H UTC giving about 5 days of time for people to share what > > > works and what does not. We’ll stop anytime we've three -1s (binding). > > > > > > Short summary: > > > > > > - Base line protocol: Continuous changes from release/stable > > > branches to master/unable branches > > > - Get contributors more engaged with release branches by working > > > (fixing bugs, docs etc.) on release branches first (and not on > > > master) > > > - Fixes on release branches are recommended (non strict enforcement) > > > go via a hotfix/bugfix branch that get automatically tested by > > > Jenkins, when they are green RMs get the changes to release branch > > > > > > Long Summary of what we’ll adopt: (I’m skipping writing them on > > > wiki, as this may change/modify in this thread) > > > > > > - Continuous flow of changes from stable branches to un-stables ones i.e. > > > from release branches to master and from master to features etc. Use > > > of merge —fast-forward is encourages over cherry-picking and —no-ff > > > (no ff will create merge commit). This happens couple of times a day > > > to ensure > > we > > > get solid/robust changes from release branches (such as bugfixes > > > etc.) on master, any conflicts will be resolved. If we do it > > > continuously we’ll > > also > > > save ourselves from a big conflict at the end of the release cycle > > > and we’ll also avoid missing/misplacing any commit when cherry-picking. > > > > > > - After code freeze is declared and release branch is cut out, > > > contributors work on fixing bugs and other changes (such as > > documentation, > > > build/packaging fixes etc.) first on the release branch (and not master). > > > This is not to restrict anyone working on master, features and other > > > changes can keep landing on master as well. This is to encourage > > > contributors to give more attention to release branches by at least > > fixing > > > bugs on release branches first and not our current way where we fix > > > it on master and ask RMs to cherry pick it to release branch. > > > > > > - Changes to release branches can be done by pushing a bugfix/change > > > branch and asking the RM to pick it up if they are tested. Our > > > automated systems can perform checks on such branches too (starting > > > with a suffix that can automatically trigger such builds/tests) and > > > if everything is fine, RMs to land the changes to release branches. > > > > > > - Nothing is written in stones, this should be change-able. And, > > > this can only work if we all agree to follow this with 4.5 > > > > > > To make the best of this thread, please keep your reply short, > > > constructive and to the point.. > > > Please share your opinion on this proposal with suitable reasons: > > > > > > [ ] +1 approve > > > [ ] +0 no opinion > > > [ ] -1 disapprove (and reason why) > > > > > > [1] http://markmail.org/message/ucixhhdbz3ajyv2a > > > > > > Regards, > > > Rohit Yadav > > > Software Architect, ShapeBlue > > > M. +41 779015219 | rohit.ya...@shapeblue.com > > > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > > > > > > > > > Find out more about ShapeBlue and our range of CloudStack related > > services > > > > > > IaaS Cloud Design & Build< > > > http://shapeblue.com/iaas-cloud-design-and-build//> > > > CSForge – rapid IaaS deployment > > > framework<http://shapeblue.com/csforge/> > > > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > > > CloudStack Infrastructure Support< > > > http://shapeblue.com/cloudstack-infrastructure-support/> > > > CloudStack Bootcamp Training Courses< > > > http://shapeblue.com/cloudstack-training/> > > > > > > This email and any attachments to it may be confidential and are > > > intended solely for the use of the individual to whom it is > > > addressed. Any views > > or > > > opinions expressed are solely those of the author and do not > > > necessarily represent those of Shape Blue Ltd or related companies. > > > If you are not > > the > > > intended recipient of this email, you must neither take any action > > > based upon its contents, nor copy or show it to anyone. Please > > > contact the > > sender > > > if you believe you have received this email in error. Shape Blue Ltd > > > is a company incorporated in England & Wales. ShapeBlue Services > > > India LLP is > > a > > > company incorporated in India and is operated under license from > > > Shape > > Blue > > > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in > > Brasil > > > and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty > > > Ltd > > is > > > a company registered by The Republic of South Africa and is traded > > > under license from Shape Blue Ltd. ShapeBlue is a registered trademark. > > > > > > > > > -- > > > *Nate Gordon*Director of Technology | Appcore - the business of cloud > computing® > > Office +1.800.735.7104 | Direct +1.515.612.7787 nate.gor...@appcore.com > | www.appcore.com > > ---------------------------------------------------------------------- > > The information in this message is intended for the named recipients only. > It may contain information that is privileged, confidential or otherwise > protected from disclosure. If you are not the intended recipient, you are > hereby notified that any disclosure, copying, distribution, or the taking of > any > action in reliance on the contents of this message is strictly prohibited. If > you > have received this e-mail in error, do not print it or disseminate it or its > contents. In such event, please notify the sender by return e-mail and delete > the e-mail file immediately thereafter. Thank you.
