[DISCUSS] Omid and Tephra podlings

[Josh Elser <el...@apache.org>]

Hiya folks,

There's a discussion[1] on general@incubator about the Omid and Tephra 
podlings, their decrease in volume (commits, discussion, activity), and 
what to do about them. If you'd like to contribute to that discussion, 
please watch on general@incubator and the dev lists for those podlings.

One idea that seems to have resonated was that the Phoenix PMC could 
"adopt" the codebases for Omid and Tephra.

While this is by no means a "done decision", but I thought it would be 
good for us to think about this, decide if it's something we think we 
want to entertain, and how would would technically do this.

As far as a PMC goes, we are allowed to have multiple projects under one 
PMC. We could move the tephra and omid repositories under the control of 
our PMC, and manage them just like we do phoenix, phoenix-connectors, 
phoenix-queryserver, etc.

Thankfully, with the work of the transaction abstraction layer, we 
shouldn't be in any position where Phoenix development would get "stuck" 
by work that needed to be done in Omid or Tephra.

What do folks think? Is this a good idea? Do we have enough interest to 
keep the codebases healthy?

- Josh

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

Re: [DISCUSS] Omid and Tephra podlings

[Josh Elser <el...@apache.org>]

Just noticed that the links Alan sent out do explicitly require a formal 
VOTE.

Incoming...

On 10/30/19 10:06 AM, Josh Elser wrote:
> I am OK with Tephra and Omid committers becoming Phoenix committers. We 
> can send them a welcome package to remind them that Phoenix is a 
> "review-then-commit" community which assuages any fears I have. Agree on 
> not giving PMC membership immediately.
> 
> We can ask infra to just rename each of their repositories out of 
> "incubator" and into "phoenix (e.g. incubator-omid becomes phoenix-omid) 
> to match the infra conventions, and ask Infra to switch the LDAP 
> permissions to point at Phoenix group instead of the podlings/incubator 
> groups.
> 
> (with Phoenix VP hat on)
> 
> I think you're good to go, Alan. The only objection we've heard was a 
> weak one about not wasting Phoenix committers times (and the above plan 
> isn't a time sink on anyone). Our discussions meet my bar for lazy 
> consensus.
> 
> If anyone wants (or needs) to see an official VOTE, please holler and 
> I'll send a thread out.
> 
> - Josh
> 
> On 10/28/19 7:01 PM, Alan Gates wrote:
>> It sounds like the Phoenix community is on board, so the next step 
>> will be to have votes in Tephra and Omid.  Before I start votes there 
>> I need some indication of how Phoenix will integrate the people in 
>> Tephra and Omid.  My suggestion is that you allow any committer on 
>> Omid or Tephra to request to be a committer on Phoenix.  This way 
>> anyone who wants to continue to develop the technology can, while 
>> those who have already moved away from the project won't be added to 
>> Phoenix as inactive committers.  I wouldn't put Tephra or Omid PPMC 
>> members on the Phoenix PMC.  They will be committers if they choose, 
>> and from there they can become PMC members in time.  This is just a 
>> suggestion, feel free to modify or ignore it.
>>
>> Once you build consensus around a proposal I'll start votes in Tephra 
>> and Omid.  Once those communities have ratified it the Phoenix PMC and 
>> then the Incubator PMC will need to ratify it as well.
>>
>> Alan.
>>
>> On 2019/10/28 20:08:36, Geoffrey Jacoby <gj...@apache.org> wrote:
>>> +1. I agree with Vincent and James. So long as we support 
>>> transactions in
>>> Phoenix, we're bound to keep at least one transaction manager 
>>> working, and
>>> we'd need to contribute at least compatibility and bug fixes. That's
>>> probably more easily done under our umbrella if the Omid and Tephra
>>> communities have become inactive.
>>>
>>> If we were sure that most of our users would use one over the other, we
>>> could potentially just adopt one, but since they have different 
>>> strengths
>>> and drawbacks, that might never be the case. (If I remember right, Lars
>>> Hofhansl did some perf testing awhile back that showed Tephra better for
>>> fewer, longer transactions and Omid better for more frequent short 
>>> ones.)
>>>
>>> At least for now, probably better to take on both.
>>>
>>> Geoffrey
>>>
>>> On Fri, Oct 25, 2019 at 6:14 PM Vincent Poon <vi...@apache.org> 
>>> wrote:
>>>
>>>> +1
>>>> I don't think pulling these under Phoenix would change their volume of
>>>> activity in the near term.
>>>> However, when/if usage of transactions with Phoenix increases, we'd 
>>>> want a
>>>> path forward to be able to make modifications where necessary to these
>>>> projects.
>>>> This seems the best way to ensure there's an expedient way to do that.
>>>>
>>>> On Fri, Oct 25, 2019 at 10:36 AM James Taylor <ja...@apache.org>
>>>> wrote:
>>>>
>>>>> +1 to pulling these projects into Phoenix. We’ve already done some 
>>>>> work
>>>> in
>>>>> those projects and so have some familiarity with them. We also have 
>>>>> some
>>>>> overlap in the committers with Omid. At a minimum we’d need to 
>>>>> create new
>>>>> compat modules when necessary for future HBase releases. The 
>>>>> alternative
>>>>> would be to rip out the transaction support which would be a mistake
>>>> IMHO.
>>>>>
>>>>> On Fri, Oct 25, 2019 at 8:08 AM Josh Elser <el...@apache.org> wrote:
>>>>>
>>>>>> I share your same hesitation. I'm worried about us adopting code that
>>>> no
>>>>>> one intends to actually maintain.
>>>>>>
>>>>>> My immediate concern is whether adoption of these codebases would
>>>> impact
>>>>>> the PMC's ability to develop on Phoenix -- I think there's a path
>>>>>> forward to avoid that. Is that sufficient to say we "should" adopt
>>>> them?
>>>>>> I dunno.
>>>>>>
>>>>>> On 10/24/19 5:37 PM, Andrew Purtell wrote:
>>>>>>> Tephra and Omid are interesting in that they serve a similar 
>>>>>>> function
>>>>> - a
>>>>>>> transaction oracle - but scale differently per different choices in
>>>>>> design,
>>>>>>> so one is more appropriate for some kinds of transactional workloads
>>>> vs
>>>>>> the
>>>>>>> other. It's akin to secondary indexing, there is not an index type
>>>> that
>>>>>>> fits all use cases. If you are going to consider one, you should
>>>>> consider
>>>>>>> both. That said my guess is you will find eventually one is the
>>>>> 'winner'
>>>>>>> per second order measures like contributions or user issues. This
>>>>> should
>>>>>> be
>>>>>>> fine. As separate repositories they can move at their own speed and
>>>>> only
>>>>>>> consume bandwidth as usage and uptake actually demands.
>>>>>>>
>>>>>>> For what it's worth I'd vote as PMC +0 on accepting these code 
>>>>>>> bases.
>>>>> '+'
>>>>>>> because Phoenix transactional indexes are a promising feature, and
>>>>> could
>>>>>> be
>>>>>>> compelling, and they need one of these transaction oracles. '0'
>>>> because
>>>>>> it
>>>>>>> would be unfair to commit someone else's time. I'm not around here
>>>>>> much...
>>>>>>> but may be around more going forward.
>>>>>>>
>>>>>>> On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org>
>>>> wrote:
>>>>>>>
>>>>>>>> Hiya folks,
>>>>>>>>
>>>>>>>> There's a discussion[1] on general@incubator about the Omid and
>>>>> Tephra
>>>>>>>> podlings, their decrease in volume (commits, discussion, activity),
>>>>> and
>>>>>>>> what to do about them. If you'd like to contribute to that
>>>> discussion,
>>>>>>>> please watch on general@incubator and the dev lists for those
>>>>> podlings.
>>>>>>>>
>>>>>>>> One idea that seems to have resonated was that the Phoenix PMC 
>>>>>>>> could
>>>>>>>> "adopt" the codebases for Omid and Tephra.
>>>>>>>>
>>>>>>>> While this is by no means a "done decision", but I thought it would
>>>> be
>>>>>>>> good for us to think about this, decide if it's something we think
>>>> we
>>>>>>>> want to entertain, and how would would technically do this.
>>>>>>>>
>>>>>>>> As far as a PMC goes, we are allowed to have multiple projects 
>>>>>>>> under
>>>>> one
>>>>>>>> PMC. We could move the tephra and omid repositories under the
>>>> control
>>>>> of
>>>>>>>> our PMC, and manage them just like we do phoenix,
>>>> phoenix-connectors,
>>>>>>>> phoenix-queryserver, etc.
>>>>>>>>
>>>>>>>> Thankfully, with the work of the transaction abstraction layer, we
>>>>>>>> shouldn't be in any position where Phoenix development would get
>>>>> "stuck"
>>>>>>>> by work that needed to be done in Omid or Tephra.
>>>>>>>>
>>>>>>>> What do folks think? Is this a good idea? Do we have enough 
>>>>>>>> interest
>>>>> to
>>>>>>>> keep the codebases healthy?
>>>>>>>>
>>>>>>>> - Josh
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E 
>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>

Re: [DISCUSS] Omid and Tephra podlings

[Josh Elser <el...@apache.org>]

I am OK with Tephra and Omid committers becoming Phoenix committers. We 
can send them a welcome package to remind them that Phoenix is a 
"review-then-commit" community which assuages any fears I have. Agree on 
not giving PMC membership immediately.

We can ask infra to just rename each of their repositories out of 
"incubator" and into "phoenix (e.g. incubator-omid becomes phoenix-omid) 
to match the infra conventions, and ask Infra to switch the LDAP 
permissions to point at Phoenix group instead of the podlings/incubator 
groups.

(with Phoenix VP hat on)

I think you're good to go, Alan. The only objection we've heard was a 
weak one about not wasting Phoenix committers times (and the above plan 
isn't a time sink on anyone). Our discussions meet my bar for lazy 
consensus.

If anyone wants (or needs) to see an official VOTE, please holler and 
I'll send a thread out.

- Josh

On 10/28/19 7:01 PM, Alan Gates wrote:
> It sounds like the Phoenix community is on board, so the next step will be to have votes in Tephra and Omid.  Before I start votes there I need some indication of how Phoenix will integrate the people in Tephra and Omid.  My suggestion is that you allow any committer on Omid or Tephra to request to be a committer on Phoenix.  This way anyone who wants to continue to develop the technology can, while those who have already moved away from the project won't be added to Phoenix as inactive committers.  I wouldn't put Tephra or Omid PPMC members on the Phoenix PMC.  They will be committers if they choose, and from there they can become PMC members in time.  This is just a suggestion, feel free to modify or ignore it.
> 
> Once you build consensus around a proposal I'll start votes in Tephra and Omid.  Once those communities have ratified it the Phoenix PMC and then the Incubator PMC will need to ratify it as well.
> 
> Alan.
> 
> On 2019/10/28 20:08:36, Geoffrey Jacoby <gj...@apache.org> wrote:
>> +1. I agree with Vincent and James. So long as we support transactions in
>> Phoenix, we're bound to keep at least one transaction manager working, and
>> we'd need to contribute at least compatibility and bug fixes. That's
>> probably more easily done under our umbrella if the Omid and Tephra
>> communities have become inactive.
>>
>> If we were sure that most of our users would use one over the other, we
>> could potentially just adopt one, but since they have different strengths
>> and drawbacks, that might never be the case. (If I remember right, Lars
>> Hofhansl did some perf testing awhile back that showed Tephra better for
>> fewer, longer transactions and Omid better for more frequent short ones.)
>>
>> At least for now, probably better to take on both.
>>
>> Geoffrey
>>
>> On Fri, Oct 25, 2019 at 6:14 PM Vincent Poon <vi...@apache.org> wrote:
>>
>>> +1
>>> I don't think pulling these under Phoenix would change their volume of
>>> activity in the near term.
>>> However, when/if usage of transactions with Phoenix increases, we'd want a
>>> path forward to be able to make modifications where necessary to these
>>> projects.
>>> This seems the best way to ensure there's an expedient way to do that.
>>>
>>> On Fri, Oct 25, 2019 at 10:36 AM James Taylor <ja...@apache.org>
>>> wrote:
>>>
>>>> +1 to pulling these projects into Phoenix. We’ve already done some work
>>> in
>>>> those projects and so have some familiarity with them. We also have some
>>>> overlap in the committers with Omid. At a minimum we’d need to create new
>>>> compat modules when necessary for future HBase releases. The alternative
>>>> would be to rip out the transaction support which would be a mistake
>>> IMHO.
>>>>
>>>> On Fri, Oct 25, 2019 at 8:08 AM Josh Elser <el...@apache.org> wrote:
>>>>
>>>>> I share your same hesitation. I'm worried about us adopting code that
>>> no
>>>>> one intends to actually maintain.
>>>>>
>>>>> My immediate concern is whether adoption of these codebases would
>>> impact
>>>>> the PMC's ability to develop on Phoenix -- I think there's a path
>>>>> forward to avoid that. Is that sufficient to say we "should" adopt
>>> them?
>>>>> I dunno.
>>>>>
>>>>> On 10/24/19 5:37 PM, Andrew Purtell wrote:
>>>>>> Tephra and Omid are interesting in that they serve a similar function
>>>> - a
>>>>>> transaction oracle - but scale differently per different choices in
>>>>> design,
>>>>>> so one is more appropriate for some kinds of transactional workloads
>>> vs
>>>>> the
>>>>>> other. It's akin to secondary indexing, there is not an index type
>>> that
>>>>>> fits all use cases. If you are going to consider one, you should
>>>> consider
>>>>>> both. That said my guess is you will find eventually one is the
>>>> 'winner'
>>>>>> per second order measures like contributions or user issues. This
>>>> should
>>>>> be
>>>>>> fine. As separate repositories they can move at their own speed and
>>>> only
>>>>>> consume bandwidth as usage and uptake actually demands.
>>>>>>
>>>>>> For what it's worth I'd vote as PMC +0 on accepting these code bases.
>>>> '+'
>>>>>> because Phoenix transactional indexes are a promising feature, and
>>>> could
>>>>> be
>>>>>> compelling, and they need one of these transaction oracles. '0'
>>> because
>>>>> it
>>>>>> would be unfair to commit someone else's time. I'm not around here
>>>>> much...
>>>>>> but may be around more going forward.
>>>>>>
>>>>>> On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org>
>>> wrote:
>>>>>>
>>>>>>> Hiya folks,
>>>>>>>
>>>>>>> There's a discussion[1] on general@incubator about the Omid and
>>>> Tephra
>>>>>>> podlings, their decrease in volume (commits, discussion, activity),
>>>> and
>>>>>>> what to do about them. If you'd like to contribute to that
>>> discussion,
>>>>>>> please watch on general@incubator and the dev lists for those
>>>> podlings.
>>>>>>>
>>>>>>> One idea that seems to have resonated was that the Phoenix PMC could
>>>>>>> "adopt" the codebases for Omid and Tephra.
>>>>>>>
>>>>>>> While this is by no means a "done decision", but I thought it would
>>> be
>>>>>>> good for us to think about this, decide if it's something we think
>>> we
>>>>>>> want to entertain, and how would would technically do this.
>>>>>>>
>>>>>>> As far as a PMC goes, we are allowed to have multiple projects under
>>>> one
>>>>>>> PMC. We could move the tephra and omid repositories under the
>>> control
>>>> of
>>>>>>> our PMC, and manage them just like we do phoenix,
>>> phoenix-connectors,
>>>>>>> phoenix-queryserver, etc.
>>>>>>>
>>>>>>> Thankfully, with the work of the transaction abstraction layer, we
>>>>>>> shouldn't be in any position where Phoenix development would get
>>>> "stuck"
>>>>>>> by work that needed to be done in Omid or Tephra.
>>>>>>>
>>>>>>> What do folks think? Is this a good idea? Do we have enough interest
>>>> to
>>>>>>> keep the codebases healthy?
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Re: [DISCUSS] Omid and Tephra podlings

[Alan Gates <ga...@apache.org>]

It sounds like the Phoenix community is on board, so the next step will be to have votes in Tephra and Omid.  Before I start votes there I need some indication of how Phoenix will integrate the people in Tephra and Omid.  My suggestion is that you allow any committer on Omid or Tephra to request to be a committer on Phoenix.  This way anyone who wants to continue to develop the technology can, while those who have already moved away from the project won't be added to Phoenix as inactive committers.  I wouldn't put Tephra or Omid PPMC members on the Phoenix PMC.  They will be committers if they choose, and from there they can become PMC members in time.  This is just a suggestion, feel free to modify or ignore it.  

Once you build consensus around a proposal I'll start votes in Tephra and Omid.  Once those communities have ratified it the Phoenix PMC and then the Incubator PMC will need to ratify it as well.

Alan.

On 2019/10/28 20:08:36, Geoffrey Jacoby <gj...@apache.org> wrote: 
> +1. I agree with Vincent and James. So long as we support transactions in
> Phoenix, we're bound to keep at least one transaction manager working, and
> we'd need to contribute at least compatibility and bug fixes. That's
> probably more easily done under our umbrella if the Omid and Tephra
> communities have become inactive.
> 
> If we were sure that most of our users would use one over the other, we
> could potentially just adopt one, but since they have different strengths
> and drawbacks, that might never be the case. (If I remember right, Lars
> Hofhansl did some perf testing awhile back that showed Tephra better for
> fewer, longer transactions and Omid better for more frequent short ones.)
> 
> At least for now, probably better to take on both.
> 
> Geoffrey
> 
> On Fri, Oct 25, 2019 at 6:14 PM Vincent Poon <vi...@apache.org> wrote:
> 
> > +1
> > I don't think pulling these under Phoenix would change their volume of
> > activity in the near term.
> > However, when/if usage of transactions with Phoenix increases, we'd want a
> > path forward to be able to make modifications where necessary to these
> > projects.
> > This seems the best way to ensure there's an expedient way to do that.
> >
> > On Fri, Oct 25, 2019 at 10:36 AM James Taylor <ja...@apache.org>
> > wrote:
> >
> > > +1 to pulling these projects into Phoenix. We’ve already done some work
> > in
> > > those projects and so have some familiarity with them. We also have some
> > > overlap in the committers with Omid. At a minimum we’d need to create new
> > > compat modules when necessary for future HBase releases. The alternative
> > > would be to rip out the transaction support which would be a mistake
> > IMHO.
> > >
> > > On Fri, Oct 25, 2019 at 8:08 AM Josh Elser <el...@apache.org> wrote:
> > >
> > > > I share your same hesitation. I'm worried about us adopting code that
> > no
> > > > one intends to actually maintain.
> > > >
> > > > My immediate concern is whether adoption of these codebases would
> > impact
> > > > the PMC's ability to develop on Phoenix -- I think there's a path
> > > > forward to avoid that. Is that sufficient to say we "should" adopt
> > them?
> > > > I dunno.
> > > >
> > > > On 10/24/19 5:37 PM, Andrew Purtell wrote:
> > > > > Tephra and Omid are interesting in that they serve a similar function
> > > - a
> > > > > transaction oracle - but scale differently per different choices in
> > > > design,
> > > > > so one is more appropriate for some kinds of transactional workloads
> > vs
> > > > the
> > > > > other. It's akin to secondary indexing, there is not an index type
> > that
> > > > > fits all use cases. If you are going to consider one, you should
> > > consider
> > > > > both. That said my guess is you will find eventually one is the
> > > 'winner'
> > > > > per second order measures like contributions or user issues. This
> > > should
> > > > be
> > > > > fine. As separate repositories they can move at their own speed and
> > > only
> > > > > consume bandwidth as usage and uptake actually demands.
> > > > >
> > > > > For what it's worth I'd vote as PMC +0 on accepting these code bases.
> > > '+'
> > > > > because Phoenix transactional indexes are a promising feature, and
> > > could
> > > > be
> > > > > compelling, and they need one of these transaction oracles. '0'
> > because
> > > > it
> > > > > would be unfair to commit someone else's time. I'm not around here
> > > > much...
> > > > > but may be around more going forward.
> > > > >
> > > > > On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org>
> > wrote:
> > > > >
> > > > >> Hiya folks,
> > > > >>
> > > > >> There's a discussion[1] on general@incubator about the Omid and
> > > Tephra
> > > > >> podlings, their decrease in volume (commits, discussion, activity),
> > > and
> > > > >> what to do about them. If you'd like to contribute to that
> > discussion,
> > > > >> please watch on general@incubator and the dev lists for those
> > > podlings.
> > > > >>
> > > > >> One idea that seems to have resonated was that the Phoenix PMC could
> > > > >> "adopt" the codebases for Omid and Tephra.
> > > > >>
> > > > >> While this is by no means a "done decision", but I thought it would
> > be
> > > > >> good for us to think about this, decide if it's something we think
> > we
> > > > >> want to entertain, and how would would technically do this.
> > > > >>
> > > > >> As far as a PMC goes, we are allowed to have multiple projects under
> > > one
> > > > >> PMC. We could move the tephra and omid repositories under the
> > control
> > > of
> > > > >> our PMC, and manage them just like we do phoenix,
> > phoenix-connectors,
> > > > >> phoenix-queryserver, etc.
> > > > >>
> > > > >> Thankfully, with the work of the transaction abstraction layer, we
> > > > >> shouldn't be in any position where Phoenix development would get
> > > "stuck"
> > > > >> by work that needed to be done in Omid or Tephra.
> > > > >>
> > > > >> What do folks think? Is this a good idea? Do we have enough interest
> > > to
> > > > >> keep the codebases healthy?
> > > > >>
> > > > >> - Josh
> > > > >>
> > > > >> [1]
> > > > >>
> > > > >>
> > > >
> > >
> > https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [DISCUSS] Omid and Tephra podlings

[Geoffrey Jacoby <gj...@apache.org>]

+1. I agree with Vincent and James. So long as we support transactions in
Phoenix, we're bound to keep at least one transaction manager working, and
we'd need to contribute at least compatibility and bug fixes. That's
probably more easily done under our umbrella if the Omid and Tephra
communities have become inactive.

If we were sure that most of our users would use one over the other, we
could potentially just adopt one, but since they have different strengths
and drawbacks, that might never be the case. (If I remember right, Lars
Hofhansl did some perf testing awhile back that showed Tephra better for
fewer, longer transactions and Omid better for more frequent short ones.)

At least for now, probably better to take on both.

Geoffrey

On Fri, Oct 25, 2019 at 6:14 PM Vincent Poon <vi...@apache.org> wrote:

> +1
> I don't think pulling these under Phoenix would change their volume of
> activity in the near term.
> However, when/if usage of transactions with Phoenix increases, we'd want a
> path forward to be able to make modifications where necessary to these
> projects.
> This seems the best way to ensure there's an expedient way to do that.
>
> On Fri, Oct 25, 2019 at 10:36 AM James Taylor <ja...@apache.org>
> wrote:
>
> > +1 to pulling these projects into Phoenix. We’ve already done some work
> in
> > those projects and so have some familiarity with them. We also have some
> > overlap in the committers with Omid. At a minimum we’d need to create new
> > compat modules when necessary for future HBase releases. The alternative
> > would be to rip out the transaction support which would be a mistake
> IMHO.
> >
> > On Fri, Oct 25, 2019 at 8:08 AM Josh Elser <el...@apache.org> wrote:
> >
> > > I share your same hesitation. I'm worried about us adopting code that
> no
> > > one intends to actually maintain.
> > >
> > > My immediate concern is whether adoption of these codebases would
> impact
> > > the PMC's ability to develop on Phoenix -- I think there's a path
> > > forward to avoid that. Is that sufficient to say we "should" adopt
> them?
> > > I dunno.
> > >
> > > On 10/24/19 5:37 PM, Andrew Purtell wrote:
> > > > Tephra and Omid are interesting in that they serve a similar function
> > - a
> > > > transaction oracle - but scale differently per different choices in
> > > design,
> > > > so one is more appropriate for some kinds of transactional workloads
> vs
> > > the
> > > > other. It's akin to secondary indexing, there is not an index type
> that
> > > > fits all use cases. If you are going to consider one, you should
> > consider
> > > > both. That said my guess is you will find eventually one is the
> > 'winner'
> > > > per second order measures like contributions or user issues. This
> > should
> > > be
> > > > fine. As separate repositories they can move at their own speed and
> > only
> > > > consume bandwidth as usage and uptake actually demands.
> > > >
> > > > For what it's worth I'd vote as PMC +0 on accepting these code bases.
> > '+'
> > > > because Phoenix transactional indexes are a promising feature, and
> > could
> > > be
> > > > compelling, and they need one of these transaction oracles. '0'
> because
> > > it
> > > > would be unfair to commit someone else's time. I'm not around here
> > > much...
> > > > but may be around more going forward.
> > > >
> > > > On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org>
> wrote:
> > > >
> > > >> Hiya folks,
> > > >>
> > > >> There's a discussion[1] on general@incubator about the Omid and
> > Tephra
> > > >> podlings, their decrease in volume (commits, discussion, activity),
> > and
> > > >> what to do about them. If you'd like to contribute to that
> discussion,
> > > >> please watch on general@incubator and the dev lists for those
> > podlings.
> > > >>
> > > >> One idea that seems to have resonated was that the Phoenix PMC could
> > > >> "adopt" the codebases for Omid and Tephra.
> > > >>
> > > >> While this is by no means a "done decision", but I thought it would
> be
> > > >> good for us to think about this, decide if it's something we think
> we
> > > >> want to entertain, and how would would technically do this.
> > > >>
> > > >> As far as a PMC goes, we are allowed to have multiple projects under
> > one
> > > >> PMC. We could move the tephra and omid repositories under the
> control
> > of
> > > >> our PMC, and manage them just like we do phoenix,
> phoenix-connectors,
> > > >> phoenix-queryserver, etc.
> > > >>
> > > >> Thankfully, with the work of the transaction abstraction layer, we
> > > >> shouldn't be in any position where Phoenix development would get
> > "stuck"
> > > >> by work that needed to be done in Omid or Tephra.
> > > >>
> > > >> What do folks think? Is this a good idea? Do we have enough interest
> > to
> > > >> keep the codebases healthy?
> > > >>
> > > >> - Josh
> > > >>
> > > >> [1]
> > > >>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
> > > >>
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Omid and Tephra podlings

[Vincent Poon <vi...@apache.org>]

+1
I don't think pulling these under Phoenix would change their volume of
activity in the near term.
However, when/if usage of transactions with Phoenix increases, we'd want a
path forward to be able to make modifications where necessary to these
projects.
This seems the best way to ensure there's an expedient way to do that.

On Fri, Oct 25, 2019 at 10:36 AM James Taylor <ja...@apache.org>
wrote:

> +1 to pulling these projects into Phoenix. We’ve already done some work in
> those projects and so have some familiarity with them. We also have some
> overlap in the committers with Omid. At a minimum we’d need to create new
> compat modules when necessary for future HBase releases. The alternative
> would be to rip out the transaction support which would be a mistake IMHO.
>
> On Fri, Oct 25, 2019 at 8:08 AM Josh Elser <el...@apache.org> wrote:
>
> > I share your same hesitation. I'm worried about us adopting code that no
> > one intends to actually maintain.
> >
> > My immediate concern is whether adoption of these codebases would impact
> > the PMC's ability to develop on Phoenix -- I think there's a path
> > forward to avoid that. Is that sufficient to say we "should" adopt them?
> > I dunno.
> >
> > On 10/24/19 5:37 PM, Andrew Purtell wrote:
> > > Tephra and Omid are interesting in that they serve a similar function
> - a
> > > transaction oracle - but scale differently per different choices in
> > design,
> > > so one is more appropriate for some kinds of transactional workloads vs
> > the
> > > other. It's akin to secondary indexing, there is not an index type that
> > > fits all use cases. If you are going to consider one, you should
> consider
> > > both. That said my guess is you will find eventually one is the
> 'winner'
> > > per second order measures like contributions or user issues. This
> should
> > be
> > > fine. As separate repositories they can move at their own speed and
> only
> > > consume bandwidth as usage and uptake actually demands.
> > >
> > > For what it's worth I'd vote as PMC +0 on accepting these code bases.
> '+'
> > > because Phoenix transactional indexes are a promising feature, and
> could
> > be
> > > compelling, and they need one of these transaction oracles. '0' because
> > it
> > > would be unfair to commit someone else's time. I'm not around here
> > much...
> > > but may be around more going forward.
> > >
> > > On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org> wrote:
> > >
> > >> Hiya folks,
> > >>
> > >> There's a discussion[1] on general@incubator about the Omid and
> Tephra
> > >> podlings, their decrease in volume (commits, discussion, activity),
> and
> > >> what to do about them. If you'd like to contribute to that discussion,
> > >> please watch on general@incubator and the dev lists for those
> podlings.
> > >>
> > >> One idea that seems to have resonated was that the Phoenix PMC could
> > >> "adopt" the codebases for Omid and Tephra.
> > >>
> > >> While this is by no means a "done decision", but I thought it would be
> > >> good for us to think about this, decide if it's something we think we
> > >> want to entertain, and how would would technically do this.
> > >>
> > >> As far as a PMC goes, we are allowed to have multiple projects under
> one
> > >> PMC. We could move the tephra and omid repositories under the control
> of
> > >> our PMC, and manage them just like we do phoenix, phoenix-connectors,
> > >> phoenix-queryserver, etc.
> > >>
> > >> Thankfully, with the work of the transaction abstraction layer, we
> > >> shouldn't be in any position where Phoenix development would get
> "stuck"
> > >> by work that needed to be done in Omid or Tephra.
> > >>
> > >> What do folks think? Is this a good idea? Do we have enough interest
> to
> > >> keep the codebases healthy?
> > >>
> > >> - Josh
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
> > >>
> > >
> > >
> >
>

Re: [DISCUSS] Omid and Tephra podlings

[James Taylor <ja...@apache.org>]

+1 to pulling these projects into Phoenix. We’ve already done some work in
those projects and so have some familiarity with them. We also have some
overlap in the committers with Omid. At a minimum we’d need to create new
compat modules when necessary for future HBase releases. The alternative
would be to rip out the transaction support which would be a mistake IMHO.

On Fri, Oct 25, 2019 at 8:08 AM Josh Elser <el...@apache.org> wrote:

> I share your same hesitation. I'm worried about us adopting code that no
> one intends to actually maintain.
>
> My immediate concern is whether adoption of these codebases would impact
> the PMC's ability to develop on Phoenix -- I think there's a path
> forward to avoid that. Is that sufficient to say we "should" adopt them?
> I dunno.
>
> On 10/24/19 5:37 PM, Andrew Purtell wrote:
> > Tephra and Omid are interesting in that they serve a similar function - a
> > transaction oracle - but scale differently per different choices in
> design,
> > so one is more appropriate for some kinds of transactional workloads vs
> the
> > other. It's akin to secondary indexing, there is not an index type that
> > fits all use cases. If you are going to consider one, you should consider
> > both. That said my guess is you will find eventually one is the 'winner'
> > per second order measures like contributions or user issues. This should
> be
> > fine. As separate repositories they can move at their own speed and only
> > consume bandwidth as usage and uptake actually demands.
> >
> > For what it's worth I'd vote as PMC +0 on accepting these code bases. '+'
> > because Phoenix transactional indexes are a promising feature, and could
> be
> > compelling, and they need one of these transaction oracles. '0' because
> it
> > would be unfair to commit someone else's time. I'm not around here
> much...
> > but may be around more going forward.
> >
> > On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org> wrote:
> >
> >> Hiya folks,
> >>
> >> There's a discussion[1] on general@incubator about the Omid and Tephra
> >> podlings, their decrease in volume (commits, discussion, activity), and
> >> what to do about them. If you'd like to contribute to that discussion,
> >> please watch on general@incubator and the dev lists for those podlings.
> >>
> >> One idea that seems to have resonated was that the Phoenix PMC could
> >> "adopt" the codebases for Omid and Tephra.
> >>
> >> While this is by no means a "done decision", but I thought it would be
> >> good for us to think about this, decide if it's something we think we
> >> want to entertain, and how would would technically do this.
> >>
> >> As far as a PMC goes, we are allowed to have multiple projects under one
> >> PMC. We could move the tephra and omid repositories under the control of
> >> our PMC, and manage them just like we do phoenix, phoenix-connectors,
> >> phoenix-queryserver, etc.
> >>
> >> Thankfully, with the work of the transaction abstraction layer, we
> >> shouldn't be in any position where Phoenix development would get "stuck"
> >> by work that needed to be done in Omid or Tephra.
> >>
> >> What do folks think? Is this a good idea? Do we have enough interest to
> >> keep the codebases healthy?
> >>
> >> - Josh
> >>
> >> [1]
> >>
> >>
> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
> >>
> >
> >
>

Re: [DISCUSS] Omid and Tephra podlings

[Josh Elser <el...@apache.org>]

I share your same hesitation. I'm worried about us adopting code that no 
one intends to actually maintain.

My immediate concern is whether adoption of these codebases would impact 
the PMC's ability to develop on Phoenix -- I think there's a path 
forward to avoid that. Is that sufficient to say we "should" adopt them? 
I dunno.

On 10/24/19 5:37 PM, Andrew Purtell wrote:
> Tephra and Omid are interesting in that they serve a similar function - a
> transaction oracle - but scale differently per different choices in design,
> so one is more appropriate for some kinds of transactional workloads vs the
> other. It's akin to secondary indexing, there is not an index type that
> fits all use cases. If you are going to consider one, you should consider
> both. That said my guess is you will find eventually one is the 'winner'
> per second order measures like contributions or user issues. This should be
> fine. As separate repositories they can move at their own speed and only
> consume bandwidth as usage and uptake actually demands.
> 
> For what it's worth I'd vote as PMC +0 on accepting these code bases. '+'
> because Phoenix transactional indexes are a promising feature, and could be
> compelling, and they need one of these transaction oracles. '0' because it
> would be unfair to commit someone else's time. I'm not around here much...
> but may be around more going forward.
> 
> On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org> wrote:
> 
>> Hiya folks,
>>
>> There's a discussion[1] on general@incubator about the Omid and Tephra
>> podlings, their decrease in volume (commits, discussion, activity), and
>> what to do about them. If you'd like to contribute to that discussion,
>> please watch on general@incubator and the dev lists for those podlings.
>>
>> One idea that seems to have resonated was that the Phoenix PMC could
>> "adopt" the codebases for Omid and Tephra.
>>
>> While this is by no means a "done decision", but I thought it would be
>> good for us to think about this, decide if it's something we think we
>> want to entertain, and how would would technically do this.
>>
>> As far as a PMC goes, we are allowed to have multiple projects under one
>> PMC. We could move the tephra and omid repositories under the control of
>> our PMC, and manage them just like we do phoenix, phoenix-connectors,
>> phoenix-queryserver, etc.
>>
>> Thankfully, with the work of the transaction abstraction layer, we
>> shouldn't be in any position where Phoenix development would get "stuck"
>> by work that needed to be done in Omid or Tephra.
>>
>> What do folks think? Is this a good idea? Do we have enough interest to
>> keep the codebases healthy?
>>
>> - Josh
>>
>> [1]
>>
>> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
>>
> 
> 

Re: [DISCUSS] Omid and Tephra podlings

[Andrew Purtell <ap...@apache.org>]

Tephra and Omid are interesting in that they serve a similar function - a
transaction oracle - but scale differently per different choices in design,
so one is more appropriate for some kinds of transactional workloads vs the
other. It's akin to secondary indexing, there is not an index type that
fits all use cases. If you are going to consider one, you should consider
both. That said my guess is you will find eventually one is the 'winner'
per second order measures like contributions or user issues. This should be
fine. As separate repositories they can move at their own speed and only
consume bandwidth as usage and uptake actually demands.

For what it's worth I'd vote as PMC +0 on accepting these code bases. '+'
because Phoenix transactional indexes are a promising feature, and could be
compelling, and they need one of these transaction oracles. '0' because it
would be unfair to commit someone else's time. I'm not around here much...
but may be around more going forward.

On Thu, Oct 24, 2019 at 10:14 AM Josh Elser <el...@apache.org> wrote:

> Hiya folks,
>
> There's a discussion[1] on general@incubator about the Omid and Tephra
> podlings, their decrease in volume (commits, discussion, activity), and
> what to do about them. If you'd like to contribute to that discussion,
> please watch on general@incubator and the dev lists for those podlings.
>
> One idea that seems to have resonated was that the Phoenix PMC could
> "adopt" the codebases for Omid and Tephra.
>
> While this is by no means a "done decision", but I thought it would be
> good for us to think about this, decide if it's something we think we
> want to entertain, and how would would technically do this.
>
> As far as a PMC goes, we are allowed to have multiple projects under one
> PMC. We could move the tephra and omid repositories under the control of
> our PMC, and manage them just like we do phoenix, phoenix-connectors,
> phoenix-queryserver, etc.
>
> Thankfully, with the work of the transaction abstraction layer, we
> shouldn't be in any position where Phoenix development would get "stuck"
> by work that needed to be done in Omid or Tephra.
>
> What do folks think? Is this a good idea? Do we have enough interest to
> keep the codebases healthy?
>
> - Josh
>
> [1]
>
> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk