Karthik, thanks for starting the thread. Here's my $0.02 based on the experience of working on a feature branch while adding reservations (YARN-1051).
Overall a +1 for the approach. The couple of pain points we faced were: 1) Merge cost with trunk 2) Lack of CI in the feature branch The migration to git & keeping the feature branch in continuous sync with trunk mitigated (1) and with Allen's new test-patch.sh addressing (2), branches for features especially if used for all major features seems like an excellent choice. -Subru On Tue, Apr 28, 2015 at 5:47 PM, Sangjin Lee <sjl...@gmail.com> wrote: > Ah, I missed that part (obviously). Fantastic! > > On Tue, Apr 28, 2015 at 5:31 PM, Sean Busbey <bus...@cloudera.com> wrote: > > > On Apr 28, 2015 5:59 PM, "Sangjin Lee" <sjl...@gmail.com> wrote: > > > > > > > > That said, in a way we're deferring the cost of cleaning things up > > towards > > > the end of the branch. For example, we don't get the same treatment of > > the > > > hadoop jenkins in a branch development. It's left up to the group or > the > > > individuals to make sure to run test-patch.sh to ensure tech debt does > > not > > > accumulate. > > > > As Allen previously mentioned, the QA bot will run test-patch against > > feature branches so long as you name the patch file correctly. > > >
