[DISCUSS] Subproject proposal

[Billie Rinaldi <bi...@gmail.com>]

In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
Tubbs brought up the idea to make HTrace a subproject of an existing TLP.
This would mitigate the issues of the community being inactive and the core
instrumentation library not requiring ongoing development. It's a choice we
could make now (assuming we were able to find a TLP willing to adopt HTrace
as a subproject), or we could allow HTrace to retire and then revisit the
subproject idea at a future time if someone becomes interested in patching
and releasing a new version of HTrace.

So far, the people who have expressed interest in being involved with
HTrace as a possible subproject are Christopher, Masatake, and myself. Is
anyone else in the community interested in this idea?

Re: [DISCUSS] Subproject proposal

[Christopher <ct...@apache.org>]

On Wed, Mar 14, 2018 at 9:53 PM Billie Rinaldi <bi...@gmail.com>
wrote:

> On Wed, Mar 14, 2018 at 4:32 PM, Mike Drob <md...@mdrob.com> wrote:
>
> > On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <bi...@gmail.com>
> > wrote:
> >
> > > In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
> > > Tubbs brought up the idea to make HTrace a subproject of an existing
> TLP.
> >
> > This would mitigate the issues of the community being inactive and the
> core
> > > instrumentation library not requiring ongoing development.
> >
> >
> > Does moving to a subproject out another tlp necessitate changing Java
> > package names prior to release? That would put a damper on user adoption
> > again.
> >
>
> I'm not sure. I'm not aware of a restriction on the package names of
> subprojects, but that would be a good thing to verify. The subproject idea
> would be less appealing if it still required all the downstream projects to
> change their instrumentation.
>
>
A conversation about package naming came up on the incubator mailing lists
last year [1] (and apparently not for the first time), and the conclusion
seemed clear to me: package naming "best practice" is to have
"org.apache.*", but there's no hard requirement to name packages any
particular way. As long as the namespace isn't colliding with other
packages, I'm certain it would not be a problem to keep the naming of an
already existing "org.apache.*" naming scheme. Maven groupIds are a similar
thing to think about... but I'm sure that wouldn't take more than
coordination with INFRA to ensure repository.apache.org is configured
correctly or to simply adopt the parent project's groupId. Either way, I
can't imagine it being a problem.

[1]:
https://lists.apache.org/thread.html/efff94b00150fefed36f73d09bc90caae66279aba9ed414b329aec85@%3Cgeneral.incubator.apache.org%3E


>
> >
> > It's a choice we could make now (assuming we were able to find a TLP
> > > willing to adopt HTrace
> >
> > as a subproject),
> >
> > The Skywalking podling expressed some interest in the vote thread.
> >
> >
> >
> > or we could allow HTrace to retire and then revisit the
> > > subproject idea at a future time if someone becomes interested in
> > patching
> > > and releasing a new version of HTrace.
> > >
> > > So far, the people who have expressed interest in being involved with
> > > HTrace as a possible subproject are Christopher, Masatake, and myself.
> Is
> > > anyone else in the community interested in this idea?
> > >
> >
>

Re: [DISCUSS] Subproject proposal

[Billie Rinaldi <bi...@gmail.com>]

On Wed, Mar 14, 2018 at 4:32 PM, Mike Drob <md...@mdrob.com> wrote:

> On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <bi...@gmail.com>
> wrote:
>
> > In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
> > Tubbs brought up the idea to make HTrace a subproject of an existing TLP.
>
> This would mitigate the issues of the community being inactive and the core
> > instrumentation library not requiring ongoing development.
>
>
> Does moving to a subproject out another tlp necessitate changing Java
> package names prior to release? That would put a damper on user adoption
> again.
>

I'm not sure. I'm not aware of a restriction on the package names of
subprojects, but that would be a good thing to verify. The subproject idea
would be less appealing if it still required all the downstream projects to
change their instrumentation.


>
> It's a choice we could make now (assuming we were able to find a TLP
> > willing to adopt HTrace
>
> as a subproject),
>
> The Skywalking podling expressed some interest in the vote thread.
>
>
>
> or we could allow HTrace to retire and then revisit the
> > subproject idea at a future time if someone becomes interested in
> patching
> > and releasing a new version of HTrace.
> >
> > So far, the people who have expressed interest in being involved with
> > HTrace as a possible subproject are Christopher, Masatake, and myself. Is
> > anyone else in the community interested in this idea?
> >
>

Re: [DISCUSS] Subproject proposal

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Thu, Mar 15, 2018 at 1:29 PM, Andrew Purtell
<an...@gmail.com> wrote:
> I think it would make a lot of sense if merged into Hadoop Common. HBase and Phoenix at least would have a trivial migration, and already depend on Hadoop Common for many other things. This would prolong the life of HTrace API usage in those projects, perhaps indefinitely.

Big +1 to the above - great idea!

Thanks,
Roman.

Re: [DISCUSS] Subproject proposal

[Christopher <ct...@apache.org>]

To be clear, I agree that Hadoop TLP (if interested) is a better
destination, just as a separate sub-project, and not munged into existing
code.

On Fri, Mar 16, 2018 at 12:33 AM Andrew Purtell <an...@gmail.com>
wrote:

> I agree taking a dependency on Hadoop Common wouldn't be ideal for some
> HTrace users who haven't already done so. I don't even know if Hadoop would
> be interested. However if they are I would hope we don't forclose on the
> idea only to see HTrace go to the attic instead.
>
>
> > On Mar 15, 2018, at 7:45 PM, Christopher <ct...@apache.org> wrote:
> >
> > I share Colin's reservations about it being a subproject of Accumulo. I
> > think that is only worth considering because of HTrace's past, but not
> > necessarily for its future.
> >
> > I'm hesitant to agree it should be merged into Hadoop Common. Hadoop is
> > already so big... and personally, I would like to see it split up into a
> > few projects (not necessarily under different PMC, but certainly with
> > independent builds, releases, and separate focus areas: YARN and HDFS for
> > example really should be separate, IMO). If HTrace got merged into Hadoop
> > Common in Hadoop's current state, I think it would only make it harder
> for
> > people to identify where the separation between components is and how to
> > contribute. As a downstream packager helping maintain Hadoop and HTrace
> for
> > Fedora, I already find this amalgamation of all the different components
> of
> > Hadoop into a single project a nightmare task; throwing in HTrace to the
> > mix could make the situation even worse for packagers and other
> downstream
> > users of Hadoop and/or HTrace.
> >
> > There's also a risk that Hadoop's size and level of activity could be
> > overwhelming, and a deterrent to contributors who just want to help out
> > with HTrace occasionally.
> >
> > I also wouldn't want to force a dependency on the larger Hadoop
> libraries,
> > to get tracing instrumention from HTrace into one's own non-Hadoop
> project.
> > (This could be a problem if HTrace code were shipped in existing Hadoop
> > Common jars or was tightly coupled with them.)
> >
> > If, on the other hand, HTrace became the responsibility of the Hadoop PMC
> > as a subproject, but with its own repo/lists/releases, I think that could
> > be a very good thing. Hadoop could host a small sub-community of HTrace
> > without that sub-community being necessarily overwhelmed by the rest of
> > Hadoop's heavy activity.
> >
> > I don't know anything about Skywalking, so I don't have anything to add
> to
> > that idea.
> >
> >
> > On Thu, Mar 15, 2018 at 4:29 PM Andrew Purtell <andrew.purtell@gmail.com
> >
> > wrote:
> >
> >> I think it would make a lot of sense if merged into Hadoop Common. HBase
> >> and Phoenix at least would have a trivial migration, and already depend
> on
> >> Hadoop Common for many other things. This would prolong the life of
> HTrace
> >> API usage in those projects, perhaps indefinitely.
> >>
> >>
> >>> On Mar 15, 2018, at 12:52 PM, Colin McCabe <cm...@apache.org> wrote:
> >>>
> >>> I would potentially be interested in continue to be involved with
> HTrace
> >> as a subproject.
> >>>
> >>> The vision behind HTrace was always to have a single trace system that
> >> unified all of Hadoop.  So you could see what Accumulo was doing and how
> >> that affected HDFS, or what Phoenix was doing that affected HBase and
> HDFS,
> >> etc. etc.  This has sort of been built several times internally by
> >> companies running services based on Hadoopy projects, but never really
> made
> >> its way into open source in a meaningful way.  I thought we had a good
> shot
> >> at that, but maybe we needed to start earlier and have more resources.
> We
> >> especially lacked full-time developers and people to evangelize the
> client.
> >>>
> >>> I think it makes the most sense for HTrace to be a subproject of either
> >> Apache Hadoop or Apache Skywalking.  Skywalking in particular seems
> >> interesting since its goals are very similar to HTrace's -- to be a
> >> one-stop shop including tracing clients, visualization, and storage.
> >> Perhaps HTraced could be useful to them for improving that "first 15
> minute
> >> experience".  It's easy to start up and doesn't require managing a
> separate
> >> storage or query system.
> >>>
> >>> I'm not so sure about HTrace being a subproject of Accumulo.  It seems
> >> like Accumulo is really focused on being a storage system, not so much
> on
> >> being a platform.  It would be weird for HBase or HDFS to depend on
> >> something that was a subproject of Accumulo, for example.
> >>>
> >>> best,
> >>> Colin
> >>>
> >>>
> >>>> On Wed, Mar 14, 2018, at 17:35, Michael Wall wrote:
> >>>> I am interested.  I am not thinking about it as subproject under
> >> Accumulo
> >>>> though, just to be clear.  Just looked at Skywalking for the first
> time,
> >>>> seems intriguing.
> >>>>
> >>>>> On Wed, Mar 14, 2018 at 7:32 PM Mike Drob <md...@mdrob.com> wrote:
> >>>>>
> >>>>> On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <
> billie.rinaldi@gmail.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>> In the active thread "[VOTE] Retire HTrace from Incubation"
> >> Christopher
> >>>>>> Tubbs brought up the idea to make HTrace a subproject of an existing
> >> TLP.
> >>>>>
> >>>>> This would mitigate the issues of the community being inactive and
> the
> >> core
> >>>>>> instrumentation library not requiring ongoing development.
> >>>>>
> >>>>>
> >>>>> Does moving to a subproject out another tlp necessitate changing Java
> >>>>> package names prior to release? That would put a damper on user
> >> adoption
> >>>>> again.
> >>>>>
> >>>>> It's a choice we could make now (assuming we were able to find a TLP
> >>>>>> willing to adopt HTrace
> >>>>>
> >>>>> as a subproject),
> >>>>>
> >>>>> The Skywalking podling expressed some interest in the vote thread.
> >>>>>
> >>>>>
> >>>>>
> >>>>> or we could allow HTrace to retire and then revisit the
> >>>>>> subproject idea at a future time if someone becomes interested in
> >>>>> patching
> >>>>>> and releasing a new version of HTrace.
> >>>>>>
> >>>>>> So far, the people who have expressed interest in being involved
> with
> >>>>>> HTrace as a possible subproject are Christopher, Masatake, and
> >> myself. Is
> >>>>>> anyone else in the community interested in this idea?
> >>>>>>
> >>>>>
> >>
>

Re: [DISCUSS] Subproject proposal

[Andrew Purtell <an...@gmail.com>]

I agree taking a dependency on Hadoop Common wouldn't be ideal for some HTrace users who haven't already done so. I don't even know if Hadoop would be interested. However if they are I would hope we don't forclose on the idea only to see HTrace go to the attic instead. 


> On Mar 15, 2018, at 7:45 PM, Christopher <ct...@apache.org> wrote:
> 
> I share Colin's reservations about it being a subproject of Accumulo. I
> think that is only worth considering because of HTrace's past, but not
> necessarily for its future.
> 
> I'm hesitant to agree it should be merged into Hadoop Common. Hadoop is
> already so big... and personally, I would like to see it split up into a
> few projects (not necessarily under different PMC, but certainly with
> independent builds, releases, and separate focus areas: YARN and HDFS for
> example really should be separate, IMO). If HTrace got merged into Hadoop
> Common in Hadoop's current state, I think it would only make it harder for
> people to identify where the separation between components is and how to
> contribute. As a downstream packager helping maintain Hadoop and HTrace for
> Fedora, I already find this amalgamation of all the different components of
> Hadoop into a single project a nightmare task; throwing in HTrace to the
> mix could make the situation even worse for packagers and other downstream
> users of Hadoop and/or HTrace.
> 
> There's also a risk that Hadoop's size and level of activity could be
> overwhelming, and a deterrent to contributors who just want to help out
> with HTrace occasionally.
> 
> I also wouldn't want to force a dependency on the larger Hadoop libraries,
> to get tracing instrumention from HTrace into one's own non-Hadoop project.
> (This could be a problem if HTrace code were shipped in existing Hadoop
> Common jars or was tightly coupled with them.)
> 
> If, on the other hand, HTrace became the responsibility of the Hadoop PMC
> as a subproject, but with its own repo/lists/releases, I think that could
> be a very good thing. Hadoop could host a small sub-community of HTrace
> without that sub-community being necessarily overwhelmed by the rest of
> Hadoop's heavy activity.
> 
> I don't know anything about Skywalking, so I don't have anything to add to
> that idea.
> 
> 
> On Thu, Mar 15, 2018 at 4:29 PM Andrew Purtell <an...@gmail.com>
> wrote:
> 
>> I think it would make a lot of sense if merged into Hadoop Common. HBase
>> and Phoenix at least would have a trivial migration, and already depend on
>> Hadoop Common for many other things. This would prolong the life of HTrace
>> API usage in those projects, perhaps indefinitely.
>> 
>> 
>>> On Mar 15, 2018, at 12:52 PM, Colin McCabe <cm...@apache.org> wrote:
>>> 
>>> I would potentially be interested in continue to be involved with HTrace
>> as a subproject.
>>> 
>>> The vision behind HTrace was always to have a single trace system that
>> unified all of Hadoop.  So you could see what Accumulo was doing and how
>> that affected HDFS, or what Phoenix was doing that affected HBase and HDFS,
>> etc. etc.  This has sort of been built several times internally by
>> companies running services based on Hadoopy projects, but never really made
>> its way into open source in a meaningful way.  I thought we had a good shot
>> at that, but maybe we needed to start earlier and have more resources.  We
>> especially lacked full-time developers and people to evangelize the client.
>>> 
>>> I think it makes the most sense for HTrace to be a subproject of either
>> Apache Hadoop or Apache Skywalking.  Skywalking in particular seems
>> interesting since its goals are very similar to HTrace's -- to be a
>> one-stop shop including tracing clients, visualization, and storage.
>> Perhaps HTraced could be useful to them for improving that "first 15 minute
>> experience".  It's easy to start up and doesn't require managing a separate
>> storage or query system.
>>> 
>>> I'm not so sure about HTrace being a subproject of Accumulo.  It seems
>> like Accumulo is really focused on being a storage system, not so much on
>> being a platform.  It would be weird for HBase or HDFS to depend on
>> something that was a subproject of Accumulo, for example.
>>> 
>>> best,
>>> Colin
>>> 
>>> 
>>>> On Wed, Mar 14, 2018, at 17:35, Michael Wall wrote:
>>>> I am interested.  I am not thinking about it as subproject under
>> Accumulo
>>>> though, just to be clear.  Just looked at Skywalking for the first time,
>>>> seems intriguing.
>>>> 
>>>>> On Wed, Mar 14, 2018 at 7:32 PM Mike Drob <md...@mdrob.com> wrote:
>>>>> 
>>>>> On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <billie.rinaldi@gmail.com
>>> 
>>>>> wrote:
>>>>> 
>>>>>> In the active thread "[VOTE] Retire HTrace from Incubation"
>> Christopher
>>>>>> Tubbs brought up the idea to make HTrace a subproject of an existing
>> TLP.
>>>>> 
>>>>> This would mitigate the issues of the community being inactive and the
>> core
>>>>>> instrumentation library not requiring ongoing development.
>>>>> 
>>>>> 
>>>>> Does moving to a subproject out another tlp necessitate changing Java
>>>>> package names prior to release? That would put a damper on user
>> adoption
>>>>> again.
>>>>> 
>>>>> It's a choice we could make now (assuming we were able to find a TLP
>>>>>> willing to adopt HTrace
>>>>> 
>>>>> as a subproject),
>>>>> 
>>>>> The Skywalking podling expressed some interest in the vote thread.
>>>>> 
>>>>> 
>>>>> 
>>>>> or we could allow HTrace to retire and then revisit the
>>>>>> subproject idea at a future time if someone becomes interested in
>>>>> patching
>>>>>> and releasing a new version of HTrace.
>>>>>> 
>>>>>> So far, the people who have expressed interest in being involved with
>>>>>> HTrace as a possible subproject are Christopher, Masatake, and
>> myself. Is
>>>>>> anyone else in the community interested in this idea?
>>>>>> 
>>>>> 
>> 

Re: [DISCUSS] Subproject proposal

[Christopher <ct...@apache.org>]

I share Colin's reservations about it being a subproject of Accumulo. I
think that is only worth considering because of HTrace's past, but not
necessarily for its future.

I'm hesitant to agree it should be merged into Hadoop Common. Hadoop is
already so big... and personally, I would like to see it split up into a
few projects (not necessarily under different PMC, but certainly with
independent builds, releases, and separate focus areas: YARN and HDFS for
example really should be separate, IMO). If HTrace got merged into Hadoop
Common in Hadoop's current state, I think it would only make it harder for
people to identify where the separation between components is and how to
contribute. As a downstream packager helping maintain Hadoop and HTrace for
Fedora, I already find this amalgamation of all the different components of
Hadoop into a single project a nightmare task; throwing in HTrace to the
mix could make the situation even worse for packagers and other downstream
users of Hadoop and/or HTrace.

There's also a risk that Hadoop's size and level of activity could be
overwhelming, and a deterrent to contributors who just want to help out
with HTrace occasionally.

I also wouldn't want to force a dependency on the larger Hadoop libraries,
to get tracing instrumention from HTrace into one's own non-Hadoop project.
(This could be a problem if HTrace code were shipped in existing Hadoop
Common jars or was tightly coupled with them.)

If, on the other hand, HTrace became the responsibility of the Hadoop PMC
as a subproject, but with its own repo/lists/releases, I think that could
be a very good thing. Hadoop could host a small sub-community of HTrace
without that sub-community being necessarily overwhelmed by the rest of
Hadoop's heavy activity.

I don't know anything about Skywalking, so I don't have anything to add to
that idea.


On Thu, Mar 15, 2018 at 4:29 PM Andrew Purtell <an...@gmail.com>
wrote:

> I think it would make a lot of sense if merged into Hadoop Common. HBase
> and Phoenix at least would have a trivial migration, and already depend on
> Hadoop Common for many other things. This would prolong the life of HTrace
> API usage in those projects, perhaps indefinitely.
>
>
> > On Mar 15, 2018, at 12:52 PM, Colin McCabe <cm...@apache.org> wrote:
> >
> > I would potentially be interested in continue to be involved with HTrace
> as a subproject.
> >
> > The vision behind HTrace was always to have a single trace system that
> unified all of Hadoop.  So you could see what Accumulo was doing and how
> that affected HDFS, or what Phoenix was doing that affected HBase and HDFS,
> etc. etc.  This has sort of been built several times internally by
> companies running services based on Hadoopy projects, but never really made
> its way into open source in a meaningful way.  I thought we had a good shot
> at that, but maybe we needed to start earlier and have more resources.  We
> especially lacked full-time developers and people to evangelize the client.
> >
> > I think it makes the most sense for HTrace to be a subproject of either
> Apache Hadoop or Apache Skywalking.  Skywalking in particular seems
> interesting since its goals are very similar to HTrace's -- to be a
> one-stop shop including tracing clients, visualization, and storage.
> Perhaps HTraced could be useful to them for improving that "first 15 minute
> experience".  It's easy to start up and doesn't require managing a separate
> storage or query system.
> >
> > I'm not so sure about HTrace being a subproject of Accumulo.  It seems
> like Accumulo is really focused on being a storage system, not so much on
> being a platform.  It would be weird for HBase or HDFS to depend on
> something that was a subproject of Accumulo, for example.
> >
> > best,
> > Colin
> >
> >
> >> On Wed, Mar 14, 2018, at 17:35, Michael Wall wrote:
> >> I am interested.  I am not thinking about it as subproject under
> Accumulo
> >> though, just to be clear.  Just looked at Skywalking for the first time,
> >> seems intriguing.
> >>
> >>> On Wed, Mar 14, 2018 at 7:32 PM Mike Drob <md...@mdrob.com> wrote:
> >>>
> >>> On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <billie.rinaldi@gmail.com
> >
> >>> wrote:
> >>>
> >>>> In the active thread "[VOTE] Retire HTrace from Incubation"
> Christopher
> >>>> Tubbs brought up the idea to make HTrace a subproject of an existing
> TLP.
> >>>
> >>> This would mitigate the issues of the community being inactive and the
> core
> >>>> instrumentation library not requiring ongoing development.
> >>>
> >>>
> >>> Does moving to a subproject out another tlp necessitate changing Java
> >>> package names prior to release? That would put a damper on user
> adoption
> >>> again.
> >>>
> >>> It's a choice we could make now (assuming we were able to find a TLP
> >>>> willing to adopt HTrace
> >>>
> >>> as a subproject),
> >>>
> >>> The Skywalking podling expressed some interest in the vote thread.
> >>>
> >>>
> >>>
> >>> or we could allow HTrace to retire and then revisit the
> >>>> subproject idea at a future time if someone becomes interested in
> >>> patching
> >>>> and releasing a new version of HTrace.
> >>>>
> >>>> So far, the people who have expressed interest in being involved with
> >>>> HTrace as a possible subproject are Christopher, Masatake, and
> myself. Is
> >>>> anyone else in the community interested in this idea?
> >>>>
> >>>
>

Re: [DISCUSS] Subproject proposal

[Andrew Purtell <an...@gmail.com>]

I think it would make a lot of sense if merged into Hadoop Common. HBase and Phoenix at least would have a trivial migration, and already depend on Hadoop Common for many other things. This would prolong the life of HTrace API usage in those projects, perhaps indefinitely. 


> On Mar 15, 2018, at 12:52 PM, Colin McCabe <cm...@apache.org> wrote:
> 
> I would potentially be interested in continue to be involved with HTrace as a subproject.
> 
> The vision behind HTrace was always to have a single trace system that unified all of Hadoop.  So you could see what Accumulo was doing and how that affected HDFS, or what Phoenix was doing that affected HBase and HDFS, etc. etc.  This has sort of been built several times internally by companies running services based on Hadoopy projects, but never really made its way into open source in a meaningful way.  I thought we had a good shot at that, but maybe we needed to start earlier and have more resources.  We especially lacked full-time developers and people to evangelize the client.
> 
> I think it makes the most sense for HTrace to be a subproject of either Apache Hadoop or Apache Skywalking.  Skywalking in particular seems interesting since its goals are very similar to HTrace's -- to be a one-stop shop including tracing clients, visualization, and storage.  Perhaps HTraced could be useful to them for improving that "first 15 minute experience".  It's easy to start up and doesn't require managing a separate storage or query system.
> 
> I'm not so sure about HTrace being a subproject of Accumulo.  It seems like Accumulo is really focused on being a storage system, not so much on being a platform.  It would be weird for HBase or HDFS to depend on something that was a subproject of Accumulo, for example.
> 
> best,
> Colin
> 
> 
>> On Wed, Mar 14, 2018, at 17:35, Michael Wall wrote:
>> I am interested.  I am not thinking about it as subproject under Accumulo
>> though, just to be clear.  Just looked at Skywalking for the first time,
>> seems intriguing.
>> 
>>> On Wed, Mar 14, 2018 at 7:32 PM Mike Drob <md...@mdrob.com> wrote:
>>> 
>>> On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <bi...@gmail.com>
>>> wrote:
>>> 
>>>> In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
>>>> Tubbs brought up the idea to make HTrace a subproject of an existing TLP.
>>> 
>>> This would mitigate the issues of the community being inactive and the core
>>>> instrumentation library not requiring ongoing development.
>>> 
>>> 
>>> Does moving to a subproject out another tlp necessitate changing Java
>>> package names prior to release? That would put a damper on user adoption
>>> again.
>>> 
>>> It's a choice we could make now (assuming we were able to find a TLP
>>>> willing to adopt HTrace
>>> 
>>> as a subproject),
>>> 
>>> The Skywalking podling expressed some interest in the vote thread.
>>> 
>>> 
>>> 
>>> or we could allow HTrace to retire and then revisit the
>>>> subproject idea at a future time if someone becomes interested in
>>> patching
>>>> and releasing a new version of HTrace.
>>>> 
>>>> So far, the people who have expressed interest in being involved with
>>>> HTrace as a possible subproject are Christopher, Masatake, and myself. Is
>>>> anyone else in the community interested in this idea?
>>>> 
>>> 

Re: [DISCUSS] Subproject proposal

[Colin McCabe <cm...@apache.org>]

I would potentially be interested in continue to be involved with HTrace as a subproject.

The vision behind HTrace was always to have a single trace system that unified all of Hadoop.  So you could see what Accumulo was doing and how that affected HDFS, or what Phoenix was doing that affected HBase and HDFS, etc. etc.  This has sort of been built several times internally by companies running services based on Hadoopy projects, but never really made its way into open source in a meaningful way.  I thought we had a good shot at that, but maybe we needed to start earlier and have more resources.  We especially lacked full-time developers and people to evangelize the client.

I think it makes the most sense for HTrace to be a subproject of either Apache Hadoop or Apache Skywalking.  Skywalking in particular seems interesting since its goals are very similar to HTrace's -- to be a one-stop shop including tracing clients, visualization, and storage.  Perhaps HTraced could be useful to them for improving that "first 15 minute experience".  It's easy to start up and doesn't require managing a separate storage or query system.

I'm not so sure about HTrace being a subproject of Accumulo.  It seems like Accumulo is really focused on being a storage system, not so much on being a platform.  It would be weird for HBase or HDFS to depend on something that was a subproject of Accumulo, for example.

best,
Colin


On Wed, Mar 14, 2018, at 17:35, Michael Wall wrote:
> I am interested.  I am not thinking about it as subproject under Accumulo
> though, just to be clear.  Just looked at Skywalking for the first time,
> seems intriguing.
> 
> On Wed, Mar 14, 2018 at 7:32 PM Mike Drob <md...@mdrob.com> wrote:
> 
> > On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <bi...@gmail.com>
> > wrote:
> >
> > > In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
> > > Tubbs brought up the idea to make HTrace a subproject of an existing TLP.
> >
> > This would mitigate the issues of the community being inactive and the core
> > > instrumentation library not requiring ongoing development.
> >
> >
> > Does moving to a subproject out another tlp necessitate changing Java
> > package names prior to release? That would put a damper on user adoption
> > again.
> >
> > It's a choice we could make now (assuming we were able to find a TLP
> > > willing to adopt HTrace
> >
> > as a subproject),
> >
> > The Skywalking podling expressed some interest in the vote thread.
> >
> >
> >
> > or we could allow HTrace to retire and then revisit the
> > > subproject idea at a future time if someone becomes interested in
> > patching
> > > and releasing a new version of HTrace.
> > >
> > > So far, the people who have expressed interest in being involved with
> > > HTrace as a possible subproject are Christopher, Masatake, and myself. Is
> > > anyone else in the community interested in this idea?
> > >
> >

Re: [DISCUSS] Subproject proposal

[Michael Wall <mj...@apache.org>]

I am interested.  I am not thinking about it as subproject under Accumulo
though, just to be clear.  Just looked at Skywalking for the first time,
seems intriguing.

On Wed, Mar 14, 2018 at 7:32 PM Mike Drob <md...@mdrob.com> wrote:

> On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <bi...@gmail.com>
> wrote:
>
> > In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
> > Tubbs brought up the idea to make HTrace a subproject of an existing TLP.
>
> This would mitigate the issues of the community being inactive and the core
> > instrumentation library not requiring ongoing development.
>
>
> Does moving to a subproject out another tlp necessitate changing Java
> package names prior to release? That would put a damper on user adoption
> again.
>
> It's a choice we could make now (assuming we were able to find a TLP
> > willing to adopt HTrace
>
> as a subproject),
>
> The Skywalking podling expressed some interest in the vote thread.
>
>
>
> or we could allow HTrace to retire and then revisit the
> > subproject idea at a future time if someone becomes interested in
> patching
> > and releasing a new version of HTrace.
> >
> > So far, the people who have expressed interest in being involved with
> > HTrace as a possible subproject are Christopher, Masatake, and myself. Is
> > anyone else in the community interested in this idea?
> >
>

Re: [DISCUSS] Subproject proposal

[Mike Drob <md...@mdrob.com>]

On Wed, Mar 14, 2018, 2:26 PM Billie Rinaldi <bi...@gmail.com>
wrote:

> In the active thread "[VOTE] Retire HTrace from Incubation" Christopher
> Tubbs brought up the idea to make HTrace a subproject of an existing TLP.

This would mitigate the issues of the community being inactive and the core
> instrumentation library not requiring ongoing development.


Does moving to a subproject out another tlp necessitate changing Java
package names prior to release? That would put a damper on user adoption
again.

It's a choice we could make now (assuming we were able to find a TLP
> willing to adopt HTrace

as a subproject),

The Skywalking podling expressed some interest in the vote thread.



or we could allow HTrace to retire and then revisit the
> subproject idea at a future time if someone becomes interested in patching
> and releasing a new version of HTrace.
>
> So far, the people who have expressed interest in being involved with
> HTrace as a possible subproject are Christopher, Masatake, and myself. Is
> anyone else in the community interested in this idea?
>