Hi Yarn devs, I wanted to hear your thoughts on moving to a model where we develop ALL features in branches. I see the following pros/cons of this approach:
Pros: 1. A feature gets included in a release only after it is in a usable state - security etc. included. e.g. SharedCache has been included in 2.7 partially. We are yet to have MR use it or enable security. 2. Since it is not in a branch a release might be cut from, feature development could move faster without having to make sure the branch is in releasable-state between commits. e.g. Working on YARN-149 was hard mostly because we wanted the state between commits to be pristine. 3. Provide contributors the opportunity to review and commit code as branch-committers. Con: The cost of merging the branch back to trunk and branch-2. It might be painful to resolve conflicts during every rebase. However, if trunk/branch-2 have primarily bug fixes, there won't be as many conflicts. >From what I hear, the HDFS team has followed this model somewhat successfully. In YARN land, recent work on reservations was done in a branch and I think it went well. This is one of those cases where switching completely to a features-in-branches model is lot more convenient than trying it out for one-off features. Thanks Karthik -- Karthik Kambatla Software Engineer, Cloudera Inc. --------------------------------------------
