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
