Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGHyZ6KmEdD9uw4dqPc+h1WLNDnNywsUi=gPHsJCRL3=XDgAQQ@mail.gmail.com>
References: 
 <CAMUu0w_V-jdEKg4rx+_aQ-_wLNLKyoDHigEakvSZdE+YL5Hr_g@mail.gmail.com>
 <CAAha9a2hb47P0J0AyCqJh-DC-EwmrKp00tc8nW+=srdz-Si6nA@mail.gmail.com>
 <CAMUu0w9nhdtTnDhGobLg3XqXronFpCcg+O5NWWv1_QND0PcuGg@mail.gmail.com>
 <CANZa=Gv-Ay2PvGHMom1ks-us5CAYHv2uqZVooL+T_azhn4vqjw@mail.gmail.com>
 <CAGHyZ6+zdA6=vkBMCH69_fTZqZebDNhRa3soPB_CK8Uym7ogrA@mail.gmail.com>
 <CA+RK=_BaPJw8=eMJPGHGYGGYZNfjBkc01MUD0RAQBQyK0ErPPQ@mail.gmail.com>
 <CAMUu0w_m46QjwXqeZ5YN9AKQ_fSgG-ujGdB7dNYJCNfBgNgLpQ@mail.gmail.com>
 <CAGHyZ6KmEdD9uw4dqPc+h1WLNDnNywsUi=gPHsJCRL3=XDgAQQ@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Fri, 13 Mar 2015 09:18:48 -0700
Message-ID: 
 <CA+RK=_Arp_A9rrnY=wPkUifS9AFqf0B9XkJQLCh2EYzvvYs-nw@mail.gmail.com>
Subject: Re: [DISCUSS] Dependency compatibility
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=089e013d17185eb71505112ddd8f

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

> I'm -1 (non-binding) on weakening our compatibility promises. The more we=
 can
isolate our users from the impact of changes upstream the better.

We can't though in general. Making compatibility promises we can't keep
because our upstreams don't (see the dependencies section of Hadoop's
compatibility guidelines) is ultimately an untenable position. *If* we had
some complete dependency isolation for MapReduce and coprocessors committed
then this could be a different conversation. Am I misstating this?

=E2=80=8BIn this specific instance we do have another option, so we could d=
efer
this to a later time when a really unavoidable dependency change happens...
like a Guava update affecting HDFS. (We had one of those before.) We can
document the Jackson classpath issue with Hadoop >=3D 2.6 and provide
remediation advice in the troubleshooting section of the manual.

I would be disappointed to see a VOTE thread. That means we failed to reach
consensus and needed to fall back to process to resolve differences.

Why don't we do the doc update and call it a day?


On Thu, Mar 12, 2015 at 7:32 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Thu, Mar 12, 2015 at 1:20 PM, Enis S=C3=B6ztutar <enis.soz@gmail.com> =
wrote:
>
> > This is good discussion, but I would like to reach a consensus and move
> on
> > with HBASE-13149.
> >
> > My conclusion from the thread is that we cannot be realistically expect=
ed
> > to keep dependency compat between minor versions because of lack of
> shading
> > in HBase and Hadoop, and our dependencies are themselves not semver, an=
d
> we
> > cannot promise more than our dependencies promise.
> >
> > So I would like to formally drop support for dependency compat between
> > minor versions as defined in
> > https://hbase.apache.org/book.html#hbase.versioning. We can reintroduce
> > later when we have better isolation/guarantees. In the mean time, we ca=
n
> > move on.
> >
> >
> I'm -1 (non-binding) on weakening our compatibility promises. The more we
> can isolate our users from the impact of changes upstream the better. If
> our dependencies aren't semver it's all the more reason for us to be
> disciplined about 1) accepting them as exposed in the first place and 2)
> changing them.
>
> This is the first problem that has presented itself in the face of the
> restrictions we adopted as a community. I don't care for the precedent of
> us solving it by weakening those promises. For one thing, it reinforces
> messaging from vendors that folks need them to protect against choices
> individual projects make.
>
> If I have a solution that works to separate us from Hadoop when running o=
n
> YARN in Hadoop 2.6+ before 1.1 is ready, can we keep our compat at the
> current strength? Some other deadline? AFAIK, we have no direct need for
> Jackson 1.9.
>
>
>
> > The PMC has approved the compat guide, but I am not sure whether we nee=
d
> a
> > VOTE thraed. What do you guys think?
> >
> >
> My main concern with not having a VOTE thread is that some PMC members
> might be more likely to pay attention to the matter if there's a VOTE, so=
 a
> DISCUSS thread might only show consensus among a subset.
>
> Changes to the promises we make downstream are a big deal, so I'd prefer =
to
> err on the side of more participation. I'd also really like that VOTE
> thread to include user@hbase, since this impacts downstream users more
> than
> us directly.
>
> --
> Sean
>


--=20
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--089e013d17185eb71505112ddd8f--