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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > >> > > >> >> On Tue, Jul 10, 2012 at 1:46 AM, lars hofhansl <[email protected]> > >> >> 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 >
