htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: [VOTE] htrace-3.1.0, the sixth release candidate
Date Fri, 09 Jan 2015 17:21:20 GMT
Javadocs will help a lot, and a little headsup as to what changes in
release notes will be good too.

On Fri, Jan 9, 2015 at 9:15 AM, Stack <stack@duboce.net> wrote:

> On Thu, Jan 8, 2015 at 6:29 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
>
> > I'm trying out this RC over in HBase code. We've broken API compatibility
> > in at least two commits:
> >
> > HTRACE-1 changes the SpanReceiver interface. HBase was instantiating
> > SpanReceivers itself and calling .configure(HTraceConfiguration) on each
> > one. Looks like now the expectation is that SpanReceiver implementations
> > provide a constructor that takes a single parameter of
> HTraceConfiguration.
> >
> > HTRACE-16 refactors the TraceTree interface a good bit. The handy
> > getRoots() method has been replaced with the less obvious
> > getSpansByParent().find(Span.ROOT_SPAN_ID) and .getSpansByParentIdMap()
> is
> > also an invocation of getSpansByParent().find().
> >
> > Neither of these changes are a big deal, but none of this code has
> > javadocs, so it's not obvious how the contract changed. I had to look at
> > diffs and tests to decipher the new usage. This means that a simple
> > search/replace is not sufficient for existing users to upgrade.
> >
> > For reference, my patch is over on HBASE-12810.
> >
> > I don't think this is enough to sink the RC, but my understanding of the
> > earlier discussion was that this release would be a simple search/replace
> > kind of upgrade. We need to document these idiom changes for folks.
> >
>
> Good stuff Nick. I made HTRACE-62 to add doc on how to migrate. Do we need
> to add facility to make the lib easier to use?
> Thanks,
> St.Ack
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message