hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] Increased use of feature branches
Date Tue, 14 Jun 2016 00:22:12 GMT
Thanks for clarifying Andrew. Inline.

On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang <andrew.wang@cloudera.com>
wrote:

>
> On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla <kasha@cloudera.com>
> wrote:
>
>> I would like to understand the trunk-incompat part of the proposal a
>> little better.
>>
>> Is trunk-incompat always going to be a superset of trunk? If yes, is it
>> just a change in naming convention with a hope that our approach to trunk
>> stability changes as Sangjin mentioned?
>>
>> Or, is it okay for trunk-incompat to be based off of an older commit in
>> trunk with (in)frequent rebases? This has the risk of incompatible changes
>> truly rotting. Periodic rebases will ensure these changes don't rot while
>> also easing the burden of hosting two branches; if we choose this route,
>> some guidance of the period and who rebases will be nice.
>>
>
> Based on my understanding from Vinod on the previous "Looking to..."
> thread, it would be the latter. The goal of trunk-incompat was to avoid
> adding yet-another-branch we need to commit to every time, compared to the
> branch-3 proposal.
>
> I agree with the concerns you raise around feature rot. For a feature like
> EC, it'd be untenable to leave it in trunk-incompat since the rebases would
> be impossible. I imagine we'd also need a very motivated maintainer (or
> maintainers) to handle the periodic integration of new trunk commits, since
> you'd potentially be doing it for multiple large features. If some brave
> and experienced committer is willing to own maintenance of the
> trunk-incompat branch, I think it could work. However, this is a big shift
> from how we've historically done development.
>

If an incompatible feature is ready (like EC here), should we consider
working towards the next major release? In other words, is it okay to defer
cutting branch-3 until we have a large incompatible feature that would be a
pain to keep up with?


>
> This is why I leaned toward Chris D's proposal, which is that we cut
> branch-3 for 3.0.0-beta1, at which point trunk moves on to 4.0. In my mind,
> this is the "default" proposal, since it's how we've previously done
> things, with the slight adjustment that we defer cutting branch-3 until we
> start enforcing compatibility. This is my current plan for the Hadoop 3
> series, and we already had a lot of +1's about releasing from trunk on the
> previous thread.
>

I guess this makes sense.


>
> If there's a strong advocate for trunk-incompat over branch-3, let's have
> that discussion. However, given that beta is still months (and multiple
> releases) away, I don't think this decision affects my near-term goal of
> getting 3.0.0-alpha1 released.
>
> Thanks,
> Andrew
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message