Rohit,
I think that Edison and I have clearly indicated our objection reason in
our previous email. Based on current cloudstack quality, RM needs to have
control over what commits to be in release branch to get a release at
least having some quality. With this proposed model, how can you guarantee
the quality of a release? We cannot just talk about changing a process
without resolving this important concern. What is your solution to this
concern?
Thanks
-min
On 8/18/14 10:59 AM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote:
>Hi,
>
>@Jessica ‹ Can you please suggest what¹s wrong with the ³things² that
>were proposed here as I could not figure out your or Min¹s or Edison's
>individual opinion and reason behind the vote.
>
>We have three -1s (1 binding) but none of them share valid reasons or
>concerns that would point out issues and challenges with adopting the
>proposed items so we¹ll continue with the voting.
>
>Min, Jessica, Edison ‹ I would love to know what¹s wrong in the "proposed
>things" so we don¹t make mistake.
>
>@Rajani ‹ Thanks, but when we should cut a release branch is a different
>topic and IMO is per the RM¹s discretion so if you¹ve any ideas or
>proposals please go ahead and start a thread on that.
>
>Cheers.
>
>On 18-Aug-2014, at 6:52 pm, Jessica Wang <jessica.w...@citrix.com> wrote:
>
>> I agree with Edison.
>> I am -1 on this as well.
>>
>>
>> -----Original Message-----
>> From: Edison Su [mailto:edison...@citrix.com]
>> Sent: Saturday, August 16, 2014 12:11 PM
>> To: dev
>> Subject: RE: [VOTE] Adapting git workflow for release branches
>>
>> I agree with what Min said on thread:
>>http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with
>>your answer:
>> Currently we don't have a CI running continuously, no code review, it's
>>too risky to let developer check in whatever commit they want into
>>release branch. RM needs to have to control over what commit should be
>>put into release branch and what should not, otherwise, we could get
>>into a stage where no control on the quality.
>> How RM will do the control, that's something we could discuss. I know,
>>current model is not scale, as RM needs to manually cherry pick commits
>>into release branch. The way I thinking about, is all the commits put
>>into release branch, must be put into review board, or gerrit, must be
>>passed by CI and reviewers, then the commits can be put into release
>>branch.
>> For above reason, I am -1(binding) on your proposal for now until we
>>solve the quality control problem.
>>
>>> -----Original Message-----
>>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>>> Sent: Friday, August 15, 2014 3:25 AM
>>> To: dev
>>> Subject: [VOTE] Adapting git workflow for release branches
>>>
>>> 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.
>
>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.
