tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Neumann <a...@apache.org>
Subject Re: [ACTION REQUIRED] Omid & Tephra Migration to Phoenix LDAP
Date Wed, 04 Dec 2019 19:15:00 GMT
I think there are various options here:
1) Leave as is, with separate release cycles etc.
2) Migrate into Phoenix code base, release together with phoenix, but as
separate, independent artifacts
3) Tightly integrate into Phoenix, essentially removing support for using
them independently

I personally would favor 2) but let's have a discussion on that in the
community.
Cheers -Andreas


On Wed, Dec 4, 2019 at 9:32 AM Josh Elser <elserj@apache.org> wrote:

> Hey Lars,
>
> I haven't asked INFRA to do anything with the OMID or TEPHRA Jira
> projects. I can only assume that they will interpret this as "don't
> touch that", but I'll drop them a line to clarify[1]
>
> In general, I'm considering my volunteer'ed responsibilities (thanks
> AlanG ;)) to be done when Omid and Tephra have the ability to continue
> to function at the ASF. I have no expectation to define how they will
> make releases of either product -- that's on motivated individuals to
> take up. I do not presently intend to lead any integration of either
> into the "core" of Phoenix.
>
> I'd be super-happy to know who the local "experts" will be for both Omid
> and Tephra when the eventual questions/issues arise :). That can be
> something we help build into the website (or mailing list chatter will
> be enough to show us that).
>
> - Josh
>
> [1] https://issues.apache.org/jira/browse/INFRA-19460
>
> On 12/3/19 1:17 PM, larsh@apache.org wrote:
> >   That leads me to a general question:
> >
> > (1) Will OMID and TEPHRA continue to be usable standalone without
> Phoenix? In that case we should keep the OMID and TEPHRA projects in Jira.
> >
> > Or (2) do we envision to tightly integrate those into the Phoenix and
> have them only work in the Phoenix contexts?
> >
> > I strongly feel that option #1 is the one to go for, and we should
> discuss and have an opinion.
> > In fact as I outlined in earlier messages, I think there are more parts
> of Phoenix that are useful by themselves and should be separated out, such
> as the type encoders and the key-building, as well as the high performance
> interface into HBase via coprocessors... among others.
> > -- Lars
> >     On Tuesday, December 3, 2019, 9:56:24 AM PST, Josh Elser <
> elserj@apache.org> wrote:
> >
> >   Andreas, Gokul, Terence, and Yoni: You four should be all set as
> Phoenix
> > committers now. Please be sure that you're subscribed to the Phoenix dev
> > list for now (we'll split out new mailing lists as the need arises).
> >
> > I'll give INFRA the go-ahead to start tearing down the Omid and Tephra
> > resources to move them under Phoenix.
> >
> > For those who notice this at a later date, please include me in the
> > "To:" line so that I don't miss your request to retain your privileges.
> >
> > - Josh
> >
> > On 11/26/19 1:25 PM, Josh Elser wrote:
> >> Hi,
> >>
> >> As a part of the exit of the Incubator, we need to consolidate the Omid
> >> and Tephra LDAP groups (the system that controls podling membership,
> >> committer privileges, etc) with the Phoenix LDAP group.
> >>
> >> For all of those Omid and Tephra podling members who intend to continue
> >> to contribute to Omid or Tephra *and* are not already Phoenix committer
> >> or PMC, please reply to this email (on dev@phoenix) with your ASF ID
> and
> >> your intent to continue to contribute.
> >>
> >> I know a holiday in the US is coming up, but please try to respond by
> >> Monday (2019/12/02) COB. As close as we can get to the full set of
> >> committers from Omid & Tephra, the easier you will all be making my
> >> life. If someone does "miss" this message, please contact the Phoenix
> >> PMC and we'll add you to the appropriate LDAP group at a later point
> >> (your status does not expire, as per the ASF norms).
> >>
> >> Thanks in advance.
> >>
> >> - Josh (VP Phoenix)
> >
> >
>

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