Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: LimitedPrivate and HBase
From: Allen Wittenauer <aw@apache.org>
In-Reply-To: <BANLkTikYuO0nRHz3UWZFZU245dMw82Y08Q@mail.gmail.com>
Date: Mon, 13 Jun 2011 09:51:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA158FFB-1067-48FF-BDD4-D3FC0B5721C6@apache.org>
References: <457011.690.qm@web65508.mail.ac4.yahoo.com>
 <F0CA2186-6E63-459D-ABFF-21863EE018E5@yahoo-inc.com>
 <BANLkTikYuO0nRHz3UWZFZU245dMw82Y08Q@mail.gmail.com>
To: <general@hadoop.apache.org>


On Jun 9, 2011, at 10:27 AM, Tom White wrote:
>=20
> We could also change the remaining 6 cases of LimitedPrivate to Public
> (note that they are already annotated Evolving or Unstable), and
> deprecate LimitedPrivate. Would this allay people's concerns?


Thanks for doing the search Tom.

Rather than just flip them all to public, I'd like to propose the =
following:

a) LimitedPrivate APIs to non-Hadoop projects are allowed to exist for 1 =
minor release.
b) When a LimitedPrivate to non-Hadoop project is created, a blocker =
JIRA for the next release is created.
c) That JIRA should be used to determine whether the API should go =
private or public, and if the latter, what interface changes are =
required.

This gives us a roadmap to make determinations on whether the =
LimitedPrivate API was a success or not and gives us a timeline as to =
when they go away, rather than just hanging around forever in a limbo =
state.

I suspect that most of these will go public anyway, but it would be good =
to have some documentation on the how's, why's, etc.  This could also be =
used to allay the fears of a "bad" public interface.=