Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CALwhT97_8gcThYwtSodC0Dw-Qte56KMfZ94v3Tx1g0vUB9m4hw@mail.gmail.com>
References: <CAGB5D2Z_bb_1KrRRp-rDey-aXd19vpJ14xSD+A8k_zJfbQqcNA@mail.gmail.com>
 <CALwhT97fpD-L9VB3oQN08LNNKhf9wcDiFTytiRRr1Wk_k0aCHg@mail.gmail.com>
 <1465567183392.4149@hortonworks.com> <CAMXuLLq_-hWgYxreaAYkLj43xhAMh4LJuMs9LtaZdJbpi-BLSg@mail.gmail.com>
 <CADbBEntV_9KtrXjPhBz+FBoLa2EBsXZK3LhiqjWANtFXNizAjg@mail.gmail.com>
 <BD5F83F9-2EF7-4CD0-B4E8-65449A3D0BE9@hortonworks.com> <CADbBEnu0OP8agpC30UjvVSFkhcv-rBe4=Zj00WFRsu59Dgh1Rw@mail.gmail.com>
 <CAGB5D2bdcDaBE75TAFj2S27aMYQ2pR-hOA_NXmcaRb8wratUMg@mail.gmail.com>
 <CALwhT96HcCti=thWcVCBTOiSE1+GOMLuh0T2NM+PbkkSctsxHg@mail.gmail.com>
 <CAGB5D2bi6d_YYm701r=yUKMepXoYZw7x2G_ehAcCSQxOwDT7Hw@mail.gmail.com> <CALwhT97_8gcThYwtSodC0Dw-Qte56KMfZ94v3Tx1g0vUB9m4hw@mail.gmail.com>
From: Andrew Wang <andrew.wang@cloudera.com>
Date: Tue, 14 Jun 2016 16:48:55 -0700
Message-ID: <CAGB5D2YdfcNAjzHxvOBS1XzHXvZcLAR+PNf-uf7T+i4Wk=F_UA@mail.gmail.com>
Subject: Re: [DISCUSS] Increased use of feature branches
To: Karthik Kambatla <kasha@cloudera.com>
Cc: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=001a114e551c0f318f053545a72d
archived-at: Tue, 14 Jun 2016 23:49:20 -0000

--001a114e551c0f318f053545a72d
Content-Type: text/plain; charset=UTF-8

>
> 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?
>

So the idea is that we do trunk-incompat, then when the first large
incompat feature hits, we switch to branch-3? I guess this might work,
though it still requires someone to maintain trunk-incompat.

I think it'd also be hard to make this decision, since EC for instance at
one point was targeted for 2.x.

--001a114e551c0f318f053545a72d--