hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Junping Du <...@hortonworks.com>
Subject Re: [DISCUSS] Increased use of feature branches
Date Fri, 10 Jun 2016 13:56:19 GMT
Comparing with advantages, I believe the disadvantages of shipping any releases directly from
trunk are more obvious and significant:
- A lot of commits (incompatible, risky, uncompleted feature, etc.) have to wait to commit
to trunk or put into a separated branch that could delay feature development progress as additional
vote process get involved even the feature is simple and harmless.

- These commits left in separated branches are isolated and get more chance to conflict each
other, and more bugs could be involved due to conflicts and/or less eyes watching/bless on
isolated branches.

- More unnecessary arguments/debates will happen on if some commits should land on trunk or
a separated branch, just like what we have recently.

- Because branches will get increased massively, more community efforts will be spent on review
& vote for branches merge that means less effort will be spent on other commits review
given our review bandwidth is quite short so far.

- For small feature with only 1 or 2 commits, that need three +1 from PMCs will increase the
bar largely for contributors who just start to contribute on Hadoop features but no such sufficient

Given these concerns, I am open to other options, like: proposed by Vinod or Chris, but rather
than to release anything directly from trunk.

- This point doesn't necessarily need to be resolved now though, since again we're still doing
No. I think we have to settle down this first. Without a common agreed and transparent release
process and branches in community, any release (alpha, beta) bits is only called a private
release but not a official apache hadoop release (even alpha).


From: Karthik Kambatla <kasha@cloudera.com>
Sent: Friday, June 10, 2016 7:49 AM
To: Andrew Wang
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
Subject: Re: [DISCUSS] Increased use of feature branches

Thanks for restarting this thread Andrew. I really hope we can get this
across to a VOTE so it is clear.

I see a few advantages shipping from trunk:

   - The lack of need for one additional backport each time.
   - Feature rot in trunk

Instead of creating branch-3, I recommend creating branch-3.x so we can
continue doing 3.x releases off branch-3 even after we move trunk to 4.x (I
said it :))

On Thu, Jun 9, 2016 at 11:12 PM, Andrew Wang <andrew.wang@cloudera.com>

> Hi all,
> On a separate thread, a question was raised about 3.x branching and use of
> feature branches going forward.
> We discussed this previously on the "Looking to a Hadoop 3 release" thread
> that has spanned the years, with Vinod making this proposal (building on
> ideas from others who also commented in the email thread):
> http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201604.mbox/browser
> Pasting here for ease:
> On an unrelated note, offline I was pitching to a bunch of
> contributors another idea to deal
> with rotting trunk post 3.x: *Make 3.x releases off of trunk directly*.
> What this gains us is that
>  - Trunk is always nearly stable or nearly ready for releases
>  - We no longer have some code lying around in some branch (today’s
> trunk) that is not releasable
> because it gets mixed with other undesirable and incompatible changes.
>  - This needs to be coupled with more discipline on individual
> features - medium to to large
> features are always worked upon in branches and get merged into trunk
> (and a nearing release!)
> when they are ready
>  - All incompatible changes go into some sort of a trunk-incompat
> branch and stay there till
> we accumulate enough of those to warrant another major release.
> Regarding "trunk-incompat", since we're still in the alpha stage for 3.0.0,
> there's no need for this branch yet. This aspect of Vinod's proposal was
> still under a bit of discussion; Chris Douglas though we should cut a
> branch-3 for the first 3.0.0 beta, which aligns with my original thinking.
> This point doesn't necessarily need to be resolved now though, since again
> we're still doing alphas.
> What we should get consensus on is the goal of keeping trunk stable, and
> achieving that by doing more development on feature branches and being
> judicious about merges. My sense from the Hadoop 3 email thread (and the
> more recent one on the async API) is that people are generally in favor of
> this.
> We're just about ready to do the first 3.0.0 alpha, so would greatly
> appreciate everyone's timely response in this matter.
> Thanks,
> Andrew

To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

View raw message