Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of enis.soz@gmail.com designates
 209.85.216.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+RK=_AJHNpOYw_cUGrN5c6SnU1oHixCW7dpy-X5OoAeJFfReg@mail.gmail.com>
References: 
 <CAMUu0w8uvb29+QYpZ8VwSO4qEpKRyKGNPzyj1kw7tLRhLPoZkA@mail.gmail.com>
 <CA+RK=_CWMv-kfw2jxM3BB-X2dsa_P8DqA6kB9ei_V0m4TQFOaA@mail.gmail.com>
 <CAAha9a2-79m1_r0XW7UOzxs6kUR+wftjA547u10u0Cz2EyMMCg@mail.gmail.com>
 <CA+RK=_AJHNpOYw_cUGrN5c6SnU1oHixCW7dpy-X5OoAeJFfReg@mail.gmail.com>
From: =?UTF-8?Q?Enis_S=C3=B6ztutar?= <enis.soz@gmail.com>
Date: Fri, 6 Jun 2014 17:07:15 -0700
Message-ID: 
 <CAMUu0w8V9h4sqK4a1G_ESjPDLd=9EXznZXf7S2kU5-sgC9H7Dw@mail.gmail.com>
Subject: Re: [VOTE] Merge branch HBASE-10070 to trunk
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2c5a6e3822204fb33c3fe

--001a11c2c5a6e3822204fb33c3fe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 6, 2014 at 4:44 PM, Andrew Purtell <apurtell@apache.org> wrote:

> On Fri, Jun 6, 2014 at 4:36 PM, Jonathan Hsieh <jon@cloudera.com> wrote:
>
> > Personally I prefer the merge for these large feature branches -- it
> > guarantees that each commit is compilable, and reflects what you guys
> have
> > been testing for a while.  If you go with the last approach you might
> have
> > stuff broken, and in the mainline commit path.
> >
>
> =E2=80=8BThis is why I asked for the final patches to be broken out with =
git
> format-patch and attached to the JIRA, so we know what was finally
> committed.
>

Fair enough. I thought that the canonical version of the patch is always in
repo anyway, but I'll upload the patches.


>
> To allay these concerns it would be great, if rebasing the 10070 patches
> consecutively on top of trunk, =E2=80=8Bto check that the result passes t=
he typical
> release candidate checks and only push after it checks out.
>

Agreed. I'll be running the UT + some tests before the push.


>
> My opinion is this need not be a requirement, even with a history
> preserving merge into trunk we can end up in a broken state if fixups are
> committed in the merge commit. We would have the additional complication =
of
> a delta committed in the merge commit not directly associated with a JIRA=
.
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

--001a11c2c5a6e3822204fb33c3fe--