Daan, thank you for the summary. See my answers below.
On 8/6/14, 1:59 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >Alena, > >I think this is a matter of semantics. If you call the latest version >that got through the CI a pre-release and add them as releases in the >git-flow way of working on master you've got what you envision. Yes. > >In spite of my mail this morning I am not a warrior (though I like the >compliment, Rohit) of gitflow but I feel that it fits whatever we need >so far. My main point of objection was the way they maintain the master branch - to reflect the latest release, which doesn’t suit the CS maintenance releases model. Plus we can’t remove the release branches like the original model does. >I have read no contradiction to that so far. The only real >change to our present way of working , given that we will use support >branches, is that we don't build releases on the basis of cherry-picks >anymore, which is not a very big change. Other then that, naming is >all that is left. Yes, merges instead of cherry-picks and introducing a staging (*develop, or *pre-release) branch - that was all missing in the CS before, and we have to implement it. > >Maybe I lost view on the obstacles and objections and am being short >sighted here, please advice, >Daan > >On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: >> >> >> On 8/6/14, 12:52 PM, "Erik Weber" <terbol...@gmail.com> wrote: >> >>>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk < >>>alena.prokharc...@citrix.com> wrote: >>> >>>> Agree with you, Rohit. The changes to the git model we use, are needed >>>> indeed. But we should address only the problems that CS faces, and the >>>> main problem - quality control. The proposal should be limited just to >>>>the >>>> changes that are really needed for the CS, and that will work with the >>>> current CS model (minor maintenance releases support is a part of it) >>>> >>>> >>> >>>Theoretically you don't really have to change anything other than >>>merging >>>instead of cherry picking. >>>That is the main issue from a release perspective. >>> >>>But I still think there are good reasons to do so; >>> >>>1) using a well known way of handling code/releases instantly tells new >>>contributors / committers how we work. add to the fact that there exists >>>tools to help doing this correctly is a bonus. >>>2) having a known stable (atleast in theory) release as master is good >>>practice. although not many users will be running from git, i still >>>consider it to be good practice. >>>3) there is a huge belief in this thread/discussion that as long as >>>something passes CI / BVT it is considered stable. The fact is that it >>>is >>>not. Take the recent 4.4 release as a good example, where a new install >>>was >>>not working at all at the point of release. Now, this is more a CI / >>>test >>>coverage issue than git workflow issue, but i find it weird to use as an >>>argument for not improving the workflow. >>> >>>-- >>>Erik >> >> I¹m not arguing against keeping master release stable; I advocate for >>it. >> But we can¹t adopt git workflow way of keeping master branch to be a >> reflection of the latest release branch. It will not work with our way >>of >> handling maintenance releases for multiple versions of CS - see another >> thread. >> >> Instead, master branch should reflect the latest code that passed the CI >> test (the code merged from *develop after CI passes). The release >>branches >> should be cut from stable master branch - it will ensure that we won¹t >> face last minute blockers as for 4.4, because master IS a stable branch. >> And yes, we should do merges instead of cherry picking. >> >> >> >>> >> > > > >-- >Daan
