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. >
