For major features, yes, +1. Labels, for example, should have really
been done in a branch and I was shocked that it wasn’t.
Anything that helps get quality back up. The fact that our “stable”
branch isn’t is a very very bad thing. There is way too much Pokemon happening
in Hadoop:
“This feature doesn’t actually work for anything but this one use case.”
“Oh, we’re not finished with it yet. You haven’t seen it’s final form.”
2 releases later….
“Oh, we stopped working on it/not a priority.”
*grumble*
It’s worth mentioning that we have a successful confirmation that the
new test-patch.sh is properly testing on feature branches if patch files are
named appropriately and branches are named in a sane manner (hint: avoid
periods and use only one -). See HDFS-7859 for the details of a run last night
on the HDFS-7285 feature branch.
On Apr 28, 2015, at 9:26 AM, Karthik Kambatla <[email protected]> wrote:
> 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.
> --------------------------------------------
