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 yuzhihong@gmail.com designates
 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADY20s7gtbc9iKCdZcUUvFbNoa4P77a=7V5OWwf84C7fO_yE-A@mail.gmail.com>
References: <1341534984.68303.YahooMailNeo@web121705.mail.ne1.yahoo.com>
	<CA+ULb+uC3zLkpisy-vKqe-6oOiv8iV4+LaNOfKF7FAeBbOx9ZA@mail.gmail.com>
	<1341875234.78322.YahooMailNeo@web121704.mail.ne1.yahoo.com>
	<CALte62ybNkAXwLEuuJ5EggQ4fEDiGm9jBCB25-sEoTx-OsW3Gw@mail.gmail.com>
	<1341877583.95448.YahooMailNeo@web121706.mail.ne1.yahoo.com>
	<CADcMMgFL0kFPkoYDwZ1RwLQfLWr4uF5tH_iU9W5DaBvEu5KmgA@mail.gmail.com>
	<CALte62xZemH2k7=kKDFzRK=7V4ynG8C2mtjxnAFfp0=e+1GrHA@mail.gmail.com>
	<CADY20s729H24xczVr3KtEgbkaBVp3LiXLa-qh-nDUQeHcN973A@mail.gmail.com>
	<CALte62zJY5HnRU8suKmiCgt2kRqqOMznw1=h0TQUe-vabFYOCQ@mail.gmail.com>
	<CADY20s7gtbc9iKCdZcUUvFbNoa4P77a=7V5OWwf84C7fO_yE-A@mail.gmail.com>
Date: Tue, 10 Jul 2012 10:50:28 -0700
Message-ID: 
 <CALte62zF_JF17LAc2Bpbo8mx+ddxnovfB4cyWmwBswHMMZRNmA@mail.gmail.com>
Subject: Re: HBase 0.94.1
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=001636e1ec86a97d6504c47d5d55

--001636e1ec86a97d6504c47d5d55
Content-Type: text/plain; charset=ISO-8859-1

Please take a look at my tentative patch on HBASE-6365 and provide your
feedback.

Cheers

On Tue, Jul 10, 2012 at 10:34 AM, Todd Lipcon <todd@cloudera.com> wrote:

> I don't think we should be concerned with people directly extending
> the various metrics classes. They're not meant to be a "user API" IMO.
> We should annotate them as private. But the external-facing interface
> (ie the JMX output) should be treated as an interface.
>
> If we have to break them at some point without a deprecation path, +1
> for doing so in 0.96.
>
> On Tue, Jul 10, 2012 at 10:32 AM, Ted Yu <yuzhihong@gmail.com> wrote:
> > Todd brought up a good point.
> >
> > MetricsBase class only exists in old metrics framework but not metrics2
> > framework.
> > So I am not sure whether the actual names of (all) the metrics exposed
> > would be kept consistent.
> >
> > Since MetricsHistogram, etc, are public, we do need to deprecate them in
> > 0.94 in case some users extend these classes.
> >
> > Would listen to metrics experts' comments.
> >
> > On Tue, Jul 10, 2012 at 10:14 AM, Todd Lipcon <todd@cloudera.com> wrote:
> >
> >> I think there's an important distinction between the Java API of
> >> metrics, and the implicit interface that the metrics themselves
> >> expose. IMO, we can completely change the implementation of metrics
> >> (e.g. class names and java APIs) so long as the actual names of the
> >> metrics exposed are kept consistent. If we make a change there, we
> >> should provide a deprecation path if at all possible - otherwise we
> >> need a big warning on upgrade so that operators know what they're
> >> getting themselves into.
> >>
> >> -Todd
> >>
> >> On Tue, Jul 10, 2012 at 9:57 AM, Ted Yu <yuzhihong@gmail.com> wrote:
> >> > There is no annotation declaring whether the current metrics are
> stable
> >> API:
> >> >
> >> > public class MetricsHistogram extends MetricsBase {
> >> >
> >> > LarsH has endorsed marking the current metrics classes deprecated in
> his
> >> > later reply to this thread.
> >> >
> >> > Correct me if my interpretation is wrong.
> >> >
> >> > On Tue, Jul 10, 2012 at 9:23 AM, Stack <stack@duboce.net> wrote:
> >> >
> >> >> On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <lhofhansl@yahoo.com>
> >> >> wrote:
> >> >> > 0.94 is already out and did not have these deprecated. So
> deprecating
> >> >> them now in a point release is a bit strange.
> >> >> > Not -1'ing it, just raising that thought here.
> >> >> >
> >> >> > As said below because of HBASE-6311 0.94.1 should get out soon. If
> >> push
> >> >> comes to shuff are folks ok with:
> >> >> > 1. deprecating in a point release
> >> >> > 2. maybe doing that in 0.94.2
> >> >> > ?
> >> >> >
> >> >>
> >> >> In the past, we'd remove public APIs after deprecating them across a
> >> >> full major release: i.e. we'd deprecate something we want to remove
> in
> >> >> 0.96.0 in 0.94.0 (not 0.94.1).  Are the metrics changes to public
> >> >> "stable" APIs?  If so, I'd ask why change our convention now?   If
> >> >> they are "evolving", we might bend the rules.
> >> >>
> >> >> Regards, what goes into 0.94.1, its up to the release manager.  They
> >> >> can entertain petitions regards what to include but ultimately its up
> >> >> to the RM when it happens and what is in it.
> >> >>
> >> >> St.Ack
> >> >>
> >>
> >>
> >>
> >> --
> >> Todd Lipcon
> >> Software Engineer, Cloudera
> >>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

--001636e1ec86a97d6504c47d5d55--