Re: [VOTE] releasing Apache Metron 0.1BETA-RC7

[larry mccay]

Have to admit that I as confused by that as well.
I voted previously and didn't see a CANCEL - so I intended to dig through
the emails to see what I missed bit haven't gotten around to it.

On Tue, Apr 5, 2016 at 5:08 PM, Casey Stella  wrote:

> Regarding what changed between RC6 and RC7, it was just a PR to correct the
> snort URL issue, from teh changelog:
>
> METRON-92: Snort has moved their release artifacts, breaking
> deployment (dlyle65535 via cestella) closes apache/incubator-metron#65
>
>
> On Tue, Apr 5, 2016 at 4:54 PM, P. Taylor Goetz  wrote:
>
> > James,
> >
> > I’m a bit confused. There’ve been a number of votes on the dev@ list,
> but
> > only one that was closed with a RESULT (rc5). I voted on rc6, but it
> seems
> > that rc was abandoned without ever being CANCELED. The labels/links in
> the
> > message below don’t match (RC6 != RC7) — which I imagine is just a
> > copy/paste error, but it makes it confusing trying to figure out what
> > exactly we’re reviewing. The vote on RC7 also hasn’t run for 72 hours
> yet.
> >
> > Also, when starting an IPMC release vote, please provide a link to the
> > RESULT email.
> >
> > Please CANCEL this vote on general@, and we can sort things out on
> > dev@metron.
> >
> > -Taylor
> >
> > > On Apr 5, 2016, at 4:15 AM, James Sirota 
> > wrote:
> > >
> > > This is a call to vote on releasing Apache Metron 0.1BETA-RC7
> > >
> > > Full list of changes in this release:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.1BETA-RC7-incubating/CHANGES
> > <
> >
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.1BETA-RC6-incubating/CHANGES
> > >
> > >
> > > The tag/commit to be voted upon is Metron_0.1BETA_rc7:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=commit;h=ad3866bdf4b6233950e7803c3c3141f0f859e994
> > >
> > > The source archive being voted upon can be found here:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.1BETA-RC7-incubating/apache-metron-0.1BETA-RC7-incubating.tar.gz
> > <
> >
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.1BETA-RC6-incubating/apache-metron-0.1BETA-RC6-incubating.tar.gz
> > >
> > >
> > > Other release files, signatures and digests can be found here:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.1BETA-RC7-incubating/
> > <
> >
> https://dist.apache.org/repos/dist/dev/incubator/metron/0.1BETA-RC6-incubating/
> > >
> > >
> > > The release artifacts are signed with the following key:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=blob_plain;f=KEYS;hb=dc59e37e402bd868aeac7ab42a0cc9c51ccae3c2
> > >
> > > The Nexus staging repository for this release will be created after
> this
> > vote has been passed.
> > >
> > >
> > > Please vote on releasing this package as Apache Metron 0.1BETA-RC7.
> > >
> > > When voting, please list the actions taken to verify the release.
> > > Recommended build validation and verification instructions are posted
> > here:
> > > https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache Metron 0.1BETA-RC7
> > > [ ]  0 No opinion
> > > [ ] -1 Do not release this package because...
> >
> >
>

Re: Worked LICENSE and NOTICE example

[larry mccay]

Such a pain point while finding your way and even having to add something
later.
Thanks for taking the time for this!

Someday a tool to codify this into a wizard like thing would be awesome. :)

On Thu, Jun 23, 2016 at 11:31 PM, Henry Saputra 
wrote:

> Justin,
>
> Thank you for putting this up. This is super helpful.
>
> - Henry
>
> On Thu, Jun 23, 2016 at 7:16 AM, Justin Mclean 
> wrote:
>
> > Hi,
> >
> > At the last ApacheCon I was discussing with Marvin about some of the
> > issues around assembling license and notice files. One of the ideas we
> come
> > up with was to have some worked examples.
> >
> > So here is a small example I put together of a fictional Apache project
> > using Bootstrap. Code is on github [1] and the checkins show each step
> > needed to bring LICENSE and NOTICE into complicance. I’ve also made a
> short
> > (4 minutes) screen cast of the process here [2].
> >
> > Feedback, spelling errors, legal corrections/queries etc etc all welcome.
> > Do people think this is useful and would they like to see more examples?
> >
> > Thanks,
> > Justin
> >
> > 1. https://github.com/justinmclean/ApacheWombat
> > 2. https://vimeo.com/171210141
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Worked LICENSE and NOTICE example

[larry mccay]

I can buy that, Justin.
Starting to better communicate that knowledge is very much appreciated!

On Fri, Jun 24, 2016 at 10:34 AM, Justin Mclean 
wrote:

> Hi,
>
> > Someday a tool to codify this into a wizard like thing would be awesome.
> :)
>
> IMO (and I know others have different opinions) I don’t think that
> actually possible other than in simple cases. if you know the policy it’s
> reasonably obvious what needs to be done and a tool would not actually be
> helpful.
>
> Also there’s often more than one way to comply with both 3rd party license
> legal obligations and ASF policy. Just look at for instance the variation
> in top level projects LICENSE and NOTICE files.
>
> Sometimes it’s not known what may be required without some discussion.
> Some of this knowledge is not clearly documented or rather clearly
> communicatted.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Hammock to incubate at the ASF as Apache Hammock (incubating)

[larry mccay]

no
> reason to change that.
>  * The project leverages VersionEye for dependency up-to-date checks.
>  * The project would like to plan to leverage coveralls for test coverage
> verification.
>  * The project currently uses Github wiki
>
> == Initial Committers ==
>
>  * John D. Ament (johndament AT apache DOT org)
>  * Antoine Sabot-Durand (antoinesd AT apache DOT org)
>  * Libor Kramoliš (libor DOT kramolis AT gmail DOT com)
>  * Irimia Dragos (irimia DOT dragos AT gmail DOT com)
>  * Gerald Mücke (gerald DOT muecke AT gmail DOT com)
>
> == Affiliations ==
>
>  * John D. Ament - Sparta Systems
>  * Dragos Irimia - ​SII Romania
>
> == Sponsors ==
>
> === Champion ===
>
> John D. Ament johndament AT apache DOT org
>
> === Nominated Mentors ===
>
>  * John D. Ament johndament AT apache DOT org
>
> === Informal Mentors ===
>
>  * Larry McCay larry DOT mccay AT apache DOT org
>
> === Sponsoring Entity ===
>
> We are requesting the Incubator to sponsor this project.
>

Re: [VOTE] Apache Metron podling Graduation

[larry mccay]

+1 (binding)

On Wed, Mar 29, 2017 at 4:15 PM, P. Taylor Goetz  wrote:

> +1 (binding)
>
> -Taylor
>
> > On Mar 29, 2017, at 10:39 AM, Casey Stella  wrote:
> >
> > Hi Everyone,
> >
> > I propose that we graduate Apache Metron (incubating) from the incubator.
> > The full text of the proposal is below, with requisite modifications
> > applied from the discussion thread.
> >
> > The discuss thread can be found at
> > https://lists.apache.org/thread.html/e5d106456b28562bdc947624c6f33e
> 3281297dfd3803aab3d171bbad@%3Cgeneral.incubator.apache.org%3E
> >
> >
> > Best,
> >
> > Casey
> >
> > Resolution:
> >
> > Establish the Apache Metron Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best
> > interests of the Foundation and consistent with the
> > Foundation's purpose to establish a Project Management
> > Committee charged with the creation and maintenance of
> > open-source software, for distribution at no charge to the
> > public, related to a security analytics platform for big data use cases.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Metron Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Metron Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to:
> > (a) A mechanism to capture, store, and normalize any type of security
> > telemetry at extremely high rates.
> > (b) Real time processing and application of enrichments
> > (c) Efficient information storage
> > (d) An interface that gives a security investigator a centralized view
> > of data and alerts passed through the system.
> >
> > RESOLVED, that the office of "Vice President, Apache Metron" be
> > and hereby is created, the person holding such office to
> > serve at the direction of the Board of Directors as the chair
> > of the Apache Metron Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Metron Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and
> > hereby are appointed to serve as the initial members of the
> > Apache Metron Project:
> >
> >
> > PPMC by Affiliation:
> >
> > Hortonworks:
> >  Sheetal Dolas (sheetal_dolas)
> >  Ryan Merriman (rmerriman)
> >  Larry McCay (lmccay)
> >  P. Taylor Goetz (ptgoetz)
> >  Nick Allen (nickallen)
> >  David Lyle (lyle)
> >  George Vetticaden (gvetticaden)
> >  James Sirota (jsirota)
> >  Casey Stella (cstella)
> >  Michael Perez (mperez)
> >  Kiran Komaravolu (kirankom)
> >  Vinod Kumar Vavilapalli (vinodkv)
> >
> > Cisco:
> >  Debo Dutta (ddutta)
> >  Discovery Gerdes (discovery)
> >
> > Rackspace:
> >  Oskar Zabik (smogg)
> >  Andrew Hartnett (dev_warlord)
> >  Paul Kehrer (reaperhulk)
> >  Sean Schulte (sirsean)
> >
> > B23:
> >  Mark Bittmann (mbittmann)
> >  Dave Hirko (dbhirko)
> >  Brad Kolarov (bjkolly)
> >
> > Mantech:
> >  Charles Porter (cporter)
> >  Ray Urciuoli (rurcioli)
> >
> > Fogbeam Labs:
> >  Phillip Rhodes (prhodes)
> >
> >
> >
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Casey Stella
> > be appointed to the office of Vice President, Apache Metron, to
> > serve in accordance with and subject to the direction of the
> > Board of Directors and the Bylaws of the Foundation until
> > death, resignation, retirement, removal or disqualification,
> > or until a successor is appointed; and be it further
> >
> > RESOLVED, that the initial Apache Metron PMC be and hereby is
> > tasked with the creation of a set of bylaws intended to
> > encourage open development and increased participation in the
> > Apache Metron Project; and be it further
> >
> > RESOLVED, that the Apache Metron Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Metron podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Metron podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Metron podling Graduation

[larry mccay]

Ooops - I may not be able to claim (binding) for general incubator...

My +1 (non-binding) still holds though. :)

Metron has demonstrated a terrific commitment to the Apache Way.
They get it and are definitely ready for graduation.


On Wed, Mar 29, 2017 at 9:33 PM, larry mccay  wrote:

> +1 (binding)
>
> On Wed, Mar 29, 2017 at 4:15 PM, P. Taylor Goetz 
> wrote:
>
>> +1 (binding)
>>
>> -Taylor
>>
>> > On Mar 29, 2017, at 10:39 AM, Casey Stella  wrote:
>> >
>> > Hi Everyone,
>> >
>> > I propose that we graduate Apache Metron (incubating) from the
>> incubator.
>> > The full text of the proposal is below, with requisite modifications
>> > applied from the discussion thread.
>> >
>> > The discuss thread can be found at
>> > https://lists.apache.org/thread.html/e5d106456b28562bdc94762
>> 4c6f33e3281297dfd3803aab3d171bbad@%3Cgeneral.incubator.apache.org%3E
>> >
>> >
>> > Best,
>> >
>> > Casey
>> >
>> > Resolution:
>> >
>> > Establish the Apache Metron Project
>> >
>> > WHEREAS, the Board of Directors deems it to be in the best
>> > interests of the Foundation and consistent with the
>> > Foundation's purpose to establish a Project Management
>> > Committee charged with the creation and maintenance of
>> > open-source software, for distribution at no charge to the
>> > public, related to a security analytics platform for big data use cases.
>> >
>> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>> > Committee (PMC), to be known as the "Apache Metron Project",
>> > be and hereby is established pursuant to Bylaws of the
>> > Foundation; and be it further
>> >
>> > RESOLVED, that the Apache Metron Project be and hereby is
>> > responsible for the creation and maintenance of software
>> > related to:
>> > (a) A mechanism to capture, store, and normalize any type of security
>> > telemetry at extremely high rates.
>> > (b) Real time processing and application of enrichments
>> > (c) Efficient information storage
>> > (d) An interface that gives a security investigator a centralized view
>> > of data and alerts passed through the system.
>> >
>> > RESOLVED, that the office of "Vice President, Apache Metron" be
>> > and hereby is created, the person holding such office to
>> > serve at the direction of the Board of Directors as the chair
>> > of the Apache Metron Project, and to have primary responsibility
>> > for management of the projects within the scope of
>> > responsibility of the Apache Metron Project; and be it further
>> >
>> > RESOLVED, that the persons listed immediately below be and
>> > hereby are appointed to serve as the initial members of the
>> > Apache Metron Project:
>> >
>> >
>> > PPMC by Affiliation:
>> >
>> > Hortonworks:
>> >  Sheetal Dolas (sheetal_dolas)
>> >  Ryan Merriman (rmerriman)
>> >  Larry McCay (lmccay)
>> >  P. Taylor Goetz (ptgoetz)
>> >  Nick Allen (nickallen)
>> >  David Lyle (lyle)
>> >  George Vetticaden (gvetticaden)
>> >  James Sirota (jsirota)
>> >  Casey Stella (cstella)
>> >  Michael Perez (mperez)
>> >  Kiran Komaravolu (kirankom)
>> >  Vinod Kumar Vavilapalli (vinodkv)
>> >
>> > Cisco:
>> >  Debo Dutta (ddutta)
>> >  Discovery Gerdes (discovery)
>> >
>> > Rackspace:
>> >  Oskar Zabik (smogg)
>> >  Andrew Hartnett (dev_warlord)
>> >  Paul Kehrer (reaperhulk)
>> >  Sean Schulte (sirsean)
>> >
>> > B23:
>> >  Mark Bittmann (mbittmann)
>> >  Dave Hirko (dbhirko)
>> >  Brad Kolarov (bjkolly)
>> >
>> > Mantech:
>> >  Charles Porter (cporter)
>> >  Ray Urciuoli (rurcioli)
>> >
>> > Fogbeam Labs:
>> >  Phillip Rhodes (prhodes)
>> >
>> >
>> >
>> >
>> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Casey Stella
>> > be appointed to the office of Vice President, Apache Metron, to
>> > serve in accordance with and subject to the direction of the
>> > Board of Directors and the Bylaws of the Foundation until
>> > death, resignation, retirement, removal or disqualification,
>> > or until a successor is appointed; and be it further
>> >
>> > RESOLVED, that the initial Apache Metron PMC be and hereby is
>> > tasked with the creation of a set of bylaws intended to
>> > encourage open development and increased participation in the
>> > Apache Metron Project; and be it further
>> >
>> > RESOLVED, that the Apache Metron Project be and hereby
>> > is tasked with the migration and rationalization of the Apache
>> > Incubator Metron podling; and be it further
>> >
>> > RESOLVED, that all responsibilities pertaining to the Apache
>> > Incubator Metron podling encumbered upon the Apache Incubator
>> > Project are hereafter discharged.
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Request to Join IPMC

[larry mccay]

Hello -

I would be interested in joining the IPMC and lending a hand within the
incubator.

I have recently been made an ASF member, am a committer on Apache Knox,
Hadoop, Ranger and Metron.

Please let me know if there is anything that you need from me.

thanks,

--larry

Re: Request to Join IPMC

[larry mccay]

Hi John -

Sorry about that - that makes sense.

thanks,

--larry

On Thu, Apr 13, 2017 at 10:09 PM, John D. Ament 
wrote:

> Larry,
>
> Notice has been sent.  Typically we process this on the private list, but
> this is fine.  Since you are a member, you can use whimsy to subscribe to
> our private list.
>
> http://incubator.apache.org/guides/pmc.html
>
> John
>
> On Thu, Apr 13, 2017 at 9:57 PM larry mccay  wrote:
>
> > Hello -
> >
> > I would be interested in joining the IPMC and lending a hand within the
> > incubator.
> >
> > I have recently been made an ASF member, am a committer on Apache Knox,
> > Hadoop, Ranger and Metron.
> >
> > Please let me know if there is anything that you need from me.
> >
> > thanks,
> >
> > --larry
> >
>

Re: The state of Sirona

[larry mccay]

Well said.
It is healthy to not have a podling graduate and subsequently struggle as a
TLP.
This is actually a success of sorts.

At least until a majority of podlings have trouble. :)

On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning  wrote:

> I think that we need to get over thinking of this state of affairs is a
> "failure".
>
> It is just one of the many different possible outcomes for incubation. To
> my mind, having multiple possible outcomes is a *feature*, not a bug.
>
> Obviously, we should not admit podlings that we aren't committed to helping
> become TLP's and we should help those podlings become TLP's. But there are
> lots of different possible outcomes and only the podling can really
> determine which outcome it will have.
>
> It is a fact of nature that we cannot always know whether a new podling
> really has the right intent and contributor mix to become a good TLP.
> Sometimes it is apparent that the project will be a great fit and sometimes
> it is apparent that it won't be, but many times we won't exactly know.
> There will be cases where a community will melt away and there will be
> cases where a community really didn't get the point of the Apache license.
> In many cases, the world just changes and by the time it is time to
> graduate, the project just isn't the right thing to do any more.
>
> As such, I think we need to (somewhat) over-admit podlings when there is
> doubt. That doesn't mean admit projects that just won't ever succeed, but
> it does mean we should be a little generous in terms of admission. We
> should vote to admit in cases of some doubt.
>
> If that is true, then we have to expect that there will be a variety of
> outcomes and we have to take that as a consequence of our initial
> generosity. This is not a cause for tears. Frankly, every project that
> becomes an obvious candidate for retirement means that there is another
> successful project that we admitted even though there was doubt.
>
> IF it is time to retire Sirona, let's just do it.
>
>
>
> On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits 
> wrote:
>
> > It is very sad to see a project failing at growing a community. Looking
> at
> > the various public sources, I see:
> >
> >- just 2 pull request since its start in incubation
> >- no postings on the user ml since December 2015
> >- only 3 committing contributors since start in incubation
> >- No description (readme) in github
> >- No mission statement/goal description of the project on the
> project's
> >home page
> >
> > I fear this will not turn around due to the lack of interest in the world
> > beyond the project. At the moment I am inclined to say: time for
> > retirement.
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Sat, Apr 15, 2017 at 5:07 PM, Jean-Baptiste Onofré 
> > wrote:
> >
> > > Hi John
> > >
> > > I think you did the right thing by bringing the point on the table.
> > >
> > > AFAIR I already stated some months ago that, regarding the activity and
> > > regarding the community around, we should really think about retirement
> > of
> > > Sirona. Some can argue about the fact that Sirona is a "stable" project
> > > that's not really valid: if it's valid we should see questions, feature
> > > requests, etc coming from the user community. And obviously it's not
> the
> > > case. So I think that Sirona is just use for specific use cases in a
> very
> > > limited community.
> > >
> > > My €0.01 ;)
> > >
> > > Regards
> > > JB
> > >
> > > On Apr 15, 2017, 15:49, at 15:49, "John D. Ament" <
> johndam...@apache.org
> > >
> > > wrote:
> > > >All,
> > > >
> > > >I hate bringing up these topics.  But I think we as the IPMC we have
> to
> > > >take a close look at how Sirona is running and figure out what to do
> > > >next.
> > > >
> > > >- The podling has not reported in several months (this is their 3rd
> > > >attempt
> > > >at monthly).
> > > >- Every time the thought of retirement comes up, a little bit of
> > > >activity
> > > >on the project happens.  It doesn't sustain.
> > > >- There is some limited project history, but no real contribution in 6
> > > >months ( https://github.com/apache/sirona/commits/trunk )
> > > >
> > > >I personally don't want to see projects go, and I don't want to force
> a
> > > >project to leave, but at the same time I'm not convinced that there's
> > > >enough of a community behind the project to sustain it going forward.
> > > >They've put together a limited plan to get a release out the door, but
> > > >other than that I'm not sure they're going to be able to move forward.
> > > >
> > > >So I want to ask, as the IPMC, do we want to give them time to
> regroup?
> > > >
> > > >John
> > >
> >
>

Re: The state of Sirona

[larry mccay]

H - interesting points about incubator vs github and overhead.
I do think my statement was unclear though.

I was saying exactly the same thing about struggling podlings.
Much better to find out in the incubator than as a TLP that the apache way
isn't really going to work for them at the moment.


On Sun, Apr 16, 2017 at 7:21 AM, John D. Ament 
wrote:

> On Sat, Apr 15, 2017 at 3:04 PM larry mccay  wrote:
>
> > Well said.
> > It is healthy to not have a podling graduate and subsequently struggle
> as a
> > TLP.
> > This is actually a success of sorts.
> >
> > At least until a majority of podlings have trouble. :)
> >
> >
> I may be reading Ted's email differently.  Or I might be reading your
> response wrong.
>
> Retirement isn't a failure.  Podlings are meant to be experiments in some
> cases.  Can I build a strong enough community, can we follow the apache
> way.
>
> There's a notion that the incubator adds over head to smaller projects.  If
> you're a one-or-two developer group, who can commit one small change and
> cut a release in an afternoon, coming to apache with our 3 day voting
> periods seems crazy.
>
> For small projects like Sirona, they may benefit from rapid iterate,
> release, feedback cycles. This is where tooling like GitHub becomes much
> more useful.  Once you get wikis, websites going, you can iterate and seem
> like a strong community.  Until you become a community of 100's of users.
>
> We don't want to see struggling podlings graduate.  This is why the
> incubator has no time limit.  We do get worried when a podling's been here
> for too long.
>
> Basically, Sirona may see some success retiring from Apache, moving
> development to github, until they've been able to build a bigger community.
>
>
> > On Sat, Apr 15, 2017 at 2:55 PM, Ted Dunning 
> > wrote:
> >
> > > I think that we need to get over thinking of this state of affairs is a
> > > "failure".
> > >
> > > It is just one of the many different possible outcomes for incubation.
> To
> > > my mind, having multiple possible outcomes is a *feature*, not a bug.
> > >
> > > Obviously, we should not admit podlings that we aren't committed to
> > helping
> > > become TLP's and we should help those podlings become TLP's. But there
> > are
> > > lots of different possible outcomes and only the podling can really
> > > determine which outcome it will have.
> > >
> > > It is a fact of nature that we cannot always know whether a new podling
> > > really has the right intent and contributor mix to become a good TLP.
> > > Sometimes it is apparent that the project will be a great fit and
> > sometimes
> > > it is apparent that it won't be, but many times we won't exactly know.
> > > There will be cases where a community will melt away and there will be
> > > cases where a community really didn't get the point of the Apache
> > license.
> > > In many cases, the world just changes and by the time it is time to
> > > graduate, the project just isn't the right thing to do any more.
> > >
> > > As such, I think we need to (somewhat) over-admit podlings when there
> is
> > > doubt. That doesn't mean admit projects that just won't ever succeed,
> but
> > > it does mean we should be a little generous in terms of admission. We
> > > should vote to admit in cases of some doubt.
> > >
> > > If that is true, then we have to expect that there will be a variety of
> > > outcomes and we have to take that as a consequence of our initial
> > > generosity. This is not a cause for tears. Frankly, every project that
> > > becomes an obvious candidate for retirement means that there is another
> > > successful project that we admitted even though there was doubt.
> > >
> > > IF it is time to retire Sirona, let's just do it.
> > >
> > >
> > >
> > > On Sat, Apr 15, 2017 at 10:09 AM, Pierre Smits  >
> > > wrote:
> > >
> > > > It is very sad to see a project failing at growing a community.
> Looking
> > > at
> > > > the various public sources, I see:
> > > >
> > > >- just 2 pull request since its start in incubation
> > > >- no postings on the user ml since December 2015
> > > >- only 3 committing contributors since start in incubation
> > > >- No description (readme) in github
> > > >- No mission

Re: [VOTE] Livy to enter Apache Incubator

[larry mccay]

This will be a great addition.

+1

On Wed, May 31, 2017 at 9:03 AM, Sean Busbey  wrote:

> Hi folks!
>
> I'm calling a vote to accept "Livy" into the Apache Incubator.
>
> The full proposal is available below, and is also available in the wiki:
>
> https://wiki.apache.org/incubator/LivyProposal
>
> For additional context, please see the discussion thread:
>
> https://s.apache.org/incubator-livy-proposal-thread
>
> Please cast your vote:
>
> [ ] +1, bring Livy into Incubator
> [ ] -1, do not bring Livy into Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
>
> I start with my vote:
> +1
>
> 
>
> = Abstract =
>
> Livy is web service that exposes a REST interface for managing long running
> Apache Spark contexts in your cluster. With Livy, new applications can be
> built on top of Apache Spark that require fine grained interaction with
> many
> Spark contexts.
>
> = Proposal =
>
> Livy is an open-source REST service for Apache Spark. Livy enables
> applications to submit Spark applications and retrieve results without a
> co-location requirement on the Spark cluster.
>
> We propose to contribute the Livy codebase and associated artifacts (e.g.
> documentation, web-site context etc) to the Apache Software Foundation.
>
> = Background =
>
> Apache Spark is a fast and general purpose distributed compute engine, with
> a versatile API. It enables processing of large quantities of static data
> distributed over a cluster of machines, as well as processing of continuous
> streams of data. It is the preferred distributed data processing engine for
> data engineering, stream processing and data science workloads. Each Spark
> application uses a construct called the SparkContext, which is the
> application’s connection or entry point to the Spark engine. Each Spark
> application will have its own SparkContext.
>
> Livy enables clients to interact with one or more Spark sessions through
> the
> Livy Server, which acts as a proxy layer. Livy Clients have fine grained
> control over the lifecycle of the Spark sessions, as well as the ability to
> submit jobs and retrieve results, all over HTTP. Clients have two modes of
> interaction: RPC Client API, available in Java and Python, which allows
> results to be retrieved as Java or Python objects. The serialization and
> deserialization of the results is handled by the Livy framework. HTTP based
> API that allows submission of code snippets, and retrieval of the results
> in
> different formats.
>
> Multi-tenant resource allocation and security: Livy enables multiple
> independent Spark sessions to be managed simultaneously. Multiple clients
> can also interact simultaneously with the same Spark session and share the
> resources of that Spark session. Livy can also enforce secure,
> authenticated
> communication between the clients and their respective Spark sessions.
>
> More information on Livy can be found at the existing open source website:
> http://livy.io/
>
> = Rationale =
>
> Users want to use Spark’s powerful processing engine and API as the data
> processing backend for interactive applications. However, the job
> submission
> and application interaction mechanisms built into Apache Spark are
> insufficient and cumbersome for multi-user interactive applications.
>
> The primary mechanism for applications to submit Spark jobs is via
> spark-submit
> (http://spark.apache.org/docs/latest/submitting-applications.html), which
> is
> available as a command line tool as well as a programmatic API. However,
> spark-submit has the following limitations that make it difficult to build
> interactive applications: It is slow: each invocation of spark-submit
> involves a setup phase where cluster resources are acquired, new processes
> are forked, etc. This setup phase runs for many seconds, or even minutes,
> and hence is too slow for interactive applications. It is cumbersome and
> lacks flexibility: application code and dependencies have to be
> pre-compiled
> and submitted as jars, and can not be submitted interactively.
>
> Apache Spark comes with an ODBC/JDBC server, which can be used to submit
> SQL
> queries to Spark. However, this solution is limited to SQL and does not
> allow the client to leverage the rest of the Spark API, such as RDDs, MLlib
> and Streaming.
>
> A third way of using Spark is via its command-line shell, which allows the
> interactive submission of snippets of Spark code. However, the shell
> entails
> running Spark code on the client machine and hence is not a viable
> mechanism
> for remote clients to submit Spark jobs.
>
> Livy solves the limitations of the above three mechanisms, and provides the
> full Spark API as a multi-tenant service to remote clients.
>
> Since the open source release of Livy in late 2015, we have seen tremendous
> interest among a diverse set of application developers and ISVs that want
> to
> build applications with Apache Spark. To make Livy a 

Re: [MENTOR] Re: Missing Release Distribution in Clutch Status?

[larry mccay]

Great!
Thanks for the quick response and sorry for missing that on the page.

We will remedy the naming convention issue.


On Thu, Jun 20, 2013 at 10:05 PM, David Crossley wrote:

> Mattmann, Chris A (398J) wrote:
> > Hey Guys,
> >
> > Sorry I missed this.
> >
> > Real quick CC to general@i.a.o. I'm not an expert in the Clutch.
> > IPMC peeps that know the clutch, Knox has a release in the dist
> > area:
> >
> > http://www.apache.org/dyn/closer.cgi/incubator/knox/
> >
> >
> > (^^ for example the 0.2.0 release)
> >
> > Can someone give us some insight as to why the clutch indicates
> > we don't have a release in the distro area?
>
> See the Knox entry in the "Other issues" section:
> http://incubator.apache.org/clutch.html#other
>
> It is because Knox is missing the required file naming convention:
> http://incubator.apache.org/clutch.html#h-hasRelease
> So the cron job that scans for releases does not find it.
>
> -David
>
> > Thank you!
> >
> > Cheers,
> > Chris
> >
> > ++
> > Chris Mattmann, Ph.D.
> > Senior Computer Scientist
> > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > Office: 171-266B, Mailstop: 171-246
> > Email: chris.a.mattm...@nasa.gov
> > WWW:  http://sunset.usc.edu/~mattmann/
> > ++
> > Adjunct Assistant Professor, Computer Science Department
> > University of Southern California, Los Angeles, CA 90089 USA
> > ++
> >
> >
> >
> >
> >
> >
> > -Original Message-
> > From: larry mccay 
> > Reply-To: "d...@knox.incubator.apache.org"  >
> > Date: Thursday, June 20, 2013 11:46 AM
> > To: "d...@knox.incubator.apache.org" 
> > Subject: [MENTOR] Re: Missing Release Distribution in Clutch Status?
> >
> > >adding mentor prefix...
> > >
> > >
> > >On Mon, Jun 17, 2013 at 3:40 PM, larry mccay 
> > >wrote:
> > >
> > >> Touching this to bring it back to the top...
> > >>
> > >> @Chris - do you have any insight into this status indicator for us?
> > >>
> > >>
> > >>
> > >> On Thu, Jun 13, 2013 at 2:51 PM, larry mccay
> > >>wrote:
> > >>
> > >>>
> > >>> Here is the location of ambari - who has a true for release bits
> > >>>column -
> > >>> of course this is just one mirror - not sure how to map the mirrors:
> > >>>
> > >>>
> http://www.us.apache.org/dist/incubator/ambari/ambari-0.9-incubating/
> > >>>
> > >>> relative path seems to map correctly to me...
> > >>>
> > >>>
> > >>> On Thu, Jun 13, 2013 at 2:32 PM, Kevin Minder <
> > >>> kevin.min...@hortonworks.com> wrote:
> > >>>
> > >>>> We do have release bits in
> > >>>>
> > >>>>http://www.apache.org/dist/**incubator/knox/0.2.0/<
> http://www.apache.or
> > >>>>g/dist/incubator/knox/0.2.0/>
> > >>>>
> > >>>> I wonder if they need to be in the root?
> > >>>>
> > >>>>
> > >>>> On 6/13/13 1:29 PM, larry mccay wrote:
> > >>>>
> > >>>>> All -
> > >>>>>
> > >>>>> This page shows the "status of clutch currently in incubation".
> > >>>>>
> > >>>>> It indicates that we don't have a release in our distribution area.
> > >>>>> Does this mean that we don't have our release in the right place?
> > >>>>>
> > >>>>>
> > >>>>>http://incubator.apache.org/**clutch.html<
> http://incubator.apache.org/
> > >>>>>clutch.html>
> > >>>>>
> > >>>>> thanks,
> > >>>>>
> > >>>>> --larry
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Sentry for Incubator

[Larry McCay]

Hi Shreepadma -

Interesting work.

Given some more diversity on the mentor list, I would give a +1.

Being on the IPMC for Knox, I can easily imagine Sentry and Knox being 
complementary to each other and look forward to contributing to and/or 
leveraging this work within Knox.
I'd be interested in throwing around some ideas for Knox and Sentry assuming 
you get accepted into the incubator.

We can start discussions on either list - once established.

thanks,

--larry

On Jul 30, 2013, at 3:40 PM, Shreepadma Venugopalan  
wrote:

> Thanks for your feedback, Bertrand.
> 
> At this time, we are talking to a few other people to be mentors. If you're
> interested in being a mentor for Sentry, please drop me a line directly. No
> promises though, because it will be a collective decision.
> 
> Regards.
> Shreepadma
> 
> 
> On Tue, Jul 30, 2013 at 12:39 AM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
> 
>> Hi,
>> 
>> On Tue, Jul 30, 2013 at 12:58 AM, Shreepadma Venugopalan
>>  wrote:
>> ...
>>> === Nominated Mentors ===
>>>  * Arvind Prabhakar (Cloudera)
>>>  * David Nalley (Citrix)
>>>  * Patrick Hunt (Cloudera)
>>>  * Tom White (Cloudera)
>> ...
>> 
>> IMO a more diverse set of mentors affiliations would be better, any
>> volunteers?
>> 
>> -Bertrand
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Sentry for Incubator

[larry mccay]

Correction: I am a member of the PPMC for Knox - sorry for the typo in my
previous reply.


On Tue, Jul 30, 2013 at 5:07 PM, Larry McCay  wrote:

> Hi Shreepadma -
>
> Interesting work.
>
> Given some more diversity on the mentor list, I would give a +1.
>
> Being on the IPMC for Knox, I can easily imagine Sentry and Knox being
> complementary to each other and look forward to contributing to and/or
> leveraging this work within Knox.
> I'd be interested in throwing around some ideas for Knox and Sentry
> assuming you get accepted into the incubator.
>
> We can start discussions on either list - once established.
>
> thanks,
>
> --larry
>
> On Jul 30, 2013, at 3:40 PM, Shreepadma Venugopalan <
> shreepa...@cloudera.com> wrote:
>
> > Thanks for your feedback, Bertrand.
> >
> > At this time, we are talking to a few other people to be mentors. If
> you're
> > interested in being a mentor for Sentry, please drop me a line directly.
> No
> > promises though, because it will be a collective decision.
> >
> > Regards.
> > Shreepadma
> >
> >
> > On Tue, Jul 30, 2013 at 12:39 AM, Bertrand Delacretaz <
> > bdelacre...@apache.org> wrote:
> >
> >> Hi,
> >>
> >> On Tue, Jul 30, 2013 at 12:58 AM, Shreepadma Venugopalan
> >>  wrote:
> >> ...
> >>> === Nominated Mentors ===
> >>>  * Arvind Prabhakar (Cloudera)
> >>>  * David Nalley (Citrix)
> >>>  * Patrick Hunt (Cloudera)
> >>>  * Tom White (Cloudera)
> >> ...
> >>
> >> IMO a more diverse set of mentors affiliations would be better, any
> >> volunteers?
> >>
> >> -Bertrand
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE]: Accept Sentry in Apache Incubator

[Larry McCay]

+1 (non-binding)

On Aug 5, 2013, at 9:23 AM, Shreepadma Venugopalan  
wrote:

> Following the discussions last week, I'm calling a vote to accept Sentry as
> a new project in the Apache Incubator.
> 
> The proposal draft is available at:
> https://wiki.apache.org/incubator/SentryProposal and is also pasted to the
> bottom of this email. It is identical to what was proposed except for a)
> addition of two new mentors, and b) removal of the user list for now, per
> Marvin's suggestion. The proposal thread is available at:
> http://goo.gl/bvvJPh
> 
> [ ] +1 Accept Sentry in the Incubator
> [ ] +/-0 Don't care
> [ ] -1 Don't accept Sentry in the Incubator because...
> 
> Thanks.
> Shreepadma
> 
> 
> = Sentry - A fine-grained Authorization System for the Hadoop ecosystem =
> 
> == Abstract ==
> 
> Sentry is a highly modular system for providing fine grained role based
> authorization to both data and metadata stored on an Apache Hadoop cluster.
> Sentry can be used to enforce various access policy rules when accessing
> data stored on Hadoop Distributed File System through various Hadoop
> ecosystem components such as Apache Hive, Apache Pig or others.
> 
> == Proposal ==
> 
> Traditionally, user access control in Apache Hadoop has been implemented
> using file based permissions on HDFS. Following the UNIX permissions model,
> HDFS offers all or nothing semantics allowing administrator to configure
> system to allow certain users or user groups read, write or perform both
> operations on files. This system does not enable more fine grained
> permissions that allow access policies for logical parts within one file.
> Furthermore, this model can't be used to restrict access to the rich set of
> objects in the metadata catalog that are stored outside HDFS.
> 
> Sentry will provide true role-based fine-grained user access control for
> Apache Hadoop and its ecosystem components such as Hive, Pig or HBase. This
> includes providing fine- grained role based access to both data as well as
> the metadata, which provides a rich object based abstraction such as
> databases, tables or columns.
> 
> == Background ==
> 
> Sentry was initially developed by Cloudera to allow users fine grained
> access to data as well as the metadata in Apache Hadoop.
> 
> Sentry has been maintained as an open source project on Cloudera’s github.
> Sentry was previously called “Access”. All code in Sentry is open source
> and has been made publicly available under the Apache 2 license. During
> this time, Sentry has been formally released two times as versions 1.0.0
> and 1.1.0.
> 
> == Rationale ==
> 
> Currently, users don't have a way to achieve fine grained enforceable user
> access control to data stored in HDFS and their associated metadata. While
> users can use file based permissions to control access to specific
> directories and files, it is insufficient because access can't be
> restricted to file parts i.e., to specific lines or logical columns. In the
> absence of such support, users have to resort to duplicating data.
> Furthermore, file based permissions are insufficient to provide any form of
> access control to the metadata that provides an object abstraction such as
> databases, tables, columns or partitions over the data stored in HDFS.
> 
> Current Sentry developers subscribe to the mission of ASF and are familiar
> with the open source development process. Several members are already
> committers and PMC members of various other Apache projects.
> 
> == Initial Goals ==
> 
> Sentry is currently in its first major release with a considerable number
> of enhancement requests, tasks, and issues recorded towards its future
> development. The initial goal of this project will be to continue to build
> community in the spirit of the "Apache Way", and to address the highly
> requested features and bug-fixes towards the next dot release.
> 
> == Current Status ==
> === Meritocracy ===
> 
> Intent of the proposal is to build a diverse community of developers around
> Sentry. Sentry started as a open source project on Github, driven in the
> spirit of open source and we would like to continue in this spirit by, for
> example, encouraging contributors from a variety of organizations.
> 
> === Community ===
> 
> Sentry stakeholders desire to expand the user and developer base of Sentry
> further in the future. The current sets of developers in Sentry are
> committed to building a strong user base and open source community around
> the project. Development discussions within the current team have been on a
> public mailing [[
> https://groups.google.com/a/cloudera.org/forum/#!forum/access-dev | list]].
> 
> === Core Developers ===
> 
> The core developers for the Sentry project are Brock Noland, Shreepadma
> Venugopalan, Prasad Mujumdar and  Jarek Jarcec Cecho. Other contributors
> include Arvind Prabhakar and Xuefu Zhang. All engineers have deep expertise
> in Hadoop and various other ecosystem components.
> 
> === Alignment ===
> 

Re: [VOTE] Usergrid BaaS Stack for Apache Incubator

[larry mccay]

+1 (non-binding)

Good luck!

I would be interested in being a committer on user-grid due to the
synergies that seem possible between Apache Knox (incubating) and user-grid.

If this is something that you would welcome then I would be happy to join
as an initial committer.

Regardless, good luck and enjoy!


On Tue, Sep 24, 2013 at 12:57 PM, Senaka Fernando  wrote:

> +1 (binding)
>
> Thanks,
> Senaka.
>
>
> On Tue, Sep 24, 2013 at 6:49 PM, Olivier Lamy  wrote:
>
> > +1
> >
> > On 23 September 2013 22:44, Jim Jagielski  wrote:
> > > After a useful and successful proposal cycle, I would like to propose
> > > a VOTE on accepting Usergrid, a multi-tenant Backend-as-a-Service
> > > stack for web & mobile applications based on RESTful APIs, as an Apache
> > > Incubator podling.
> > >
> > > Voting to run for 72+ hours...
> > >
> > > Here is a link to the proposal:
> > >   https://wiki.apache.org/incubator/UsergridProposal
> > >
> > > It is also pasted below:
> > >
> > > = Usergrid Proposal =
> > >
> > > == Abstract ==
> > >
> > > Usergrid is a multi-tenant Backend-as-a-Service stack for web & mobile
> > > applications, based on RESTful APIs.
> > >
> > >
> > > == Proposal ==
> > >
> > > Usergrid is an open-source Backend-as-a-Service (“BaaS” or “mBaaS”)
> > composed
> > > of an integrated distributed NoSQL database, application layer and
> client
> > > tier with SDKs for developers looking to rapidly build web and/or
> mobile
> > > applications. It provides elementary services (user registration &
> > > management, data storage, file storage, queues) and retrieval features
> > (full
> > > text search, geolocation search, joins) to power common app features.
> > >
> > > It is a multi-tenant system designed for deployment to public cloud
> > > environments (such as Amazon Web Services, Rackspace, etc.) or to run
> on
> > > traditional server infrastructures so that anyone can run their own
> > private
> > > BaaS deployment.
> > >
> > > For architects and back-end teams, it aims to provide a distributed,
> > easily
> > > extendable, operationally predictable and highly scalable solution. For
> > > front-end developers, it aims to simplify the development process by
> > > enabling them to rapidly build and operate mobile and web applications
> > > without requiring backend expertise.
> > >
> > >
> > > == Background ==
> > >
> > > Developing web or mobile applications obviously necessitates writing
> and
> > > maintaining more than just front-end code. Even simple applications can
> > > implicitly rely on server code being run to store users, perform
> database
> > > queries, serve images and video files, etc. Developing and maintaining
> > such
> > > backend services requires skills not always available or expected of
> app
> > > development teams. Beyond that, the proliferation of apps inside of
> > > companies leads to the creation of many different, ad-hoc, unequally
> > > maintained backend solutions created by employees and contractors alike
> > and
> > > hosted on a wide variety of environments. This is causing poor resource
> > > usage, operational issues, as well as security, privacy & compliance
> > > concerns.
> > >
> > > In response to this problem, companies have long tried to standardize
> > their
> > > server-side stack or unify them behind an ESB or API strategy.
> > > Backends-as-a-Service follow a similar approach but their unique
> > > characteristic is strongly tying  1) a persistence tier (typically a
> > > database), 2) a server-side application tier delivering a set of common
> > > services and 3) a set of client-side application interface mechanisms.
> > For
> > > example, a BaaS could package 1) MongoDB with 2) a node.js application
> > that
> > > offers access through 3) WebSockets. In the case of Usergrid, the
> > trifecta
> > > is 1) Cassandra, 2) Java + Jersey and 3) a RESTful API.
> > >
> > > The Backend-as-a-Service approach has steadily gained popularity in the
> > last
> > > few years with cloud providers such Parse.com, Stackmob.com and
> > Kinvey.com,
> > > each operating tens of thousands of apps for tens of thousands of
> > > developers. The trend has already reached large organizations as well,
> > with
> > > global companies such as Korea Telecom internally building a
> > privately-run
> > > BaaS platform. But so far, there have been limited options for
> developers
> > > that want a non-proprietary, open option for hosting and providing
> these
> > > services themselves, or for enterprise and government users who want to
> > > provide these capabilities from their own data centers, especially on a
> > very
> > > large scale.
> > >
> > >
> > > == Rationale ==
> > >
> > > The issue this proposal deals with is implicit in the name.
> > > Backend-as-a-Service platforms are usually offered solely as
> proprietary
> > > cloud services. They are typically closed sourced, hosted on public
> > clouds,
> > > and require subscription payment. Usergrid opens the playing field, by
> > > maki

Re: The podling initial committers issue

[larry mccay]

I was under the impression that what you describe was the policy - if it is
not then is should certainly be clarified.

In the event that podlings continue to or are to be given such a choice, I
believe that there needs to be a clear understanding between the incoming
community and those volunteers that are shepherding them through the
process as to what the choice is and some of the nuances that will be
encountered in the execution.

If there is no choice there then this consensus step is less necessary and
the process can be more easily executed by the champion, mentors and
incoming community.

That shared understanding seems to be what was missing in this case.


On Wed, Sep 25, 2013 at 1:06 PM, Dave  wrote:

> Or better yet, a change like that could be made to the Incubator Policy.
>
>http://incubator.apache.org/incubation/Incubation_Policy.html
>
> Thoughts?
>
> - Dave
>
>
>
> On Wed, Sep 25, 2013 at 1:01 PM, Dave  wrote:
>
> > How do we go about changing the Incubator Proposal Guide so that the
> rules
> > around adding new committers to a podling at proposal time? As much fun
> as
> > a good email thread can be, we don't want to have to relive the same ones
> > over and over.
> >
> > Can we come up with a consensus view and get it into the guide here?
> >
> >
> >
> http://incubator.apache.org/guides/proposal.html#template-initial-committers
> > Here's what I think we should add:
> >
> > After a proposal is submitted to the incubator but before a vote is
> called
> > the proposing community may choose to add additional committers who ask
> to
> > be committers or may chose to defer adding new committers until the
> podling
> > is in the Incubator and can use the normal ways of ASF meritocracy,
> > nominate new committers, etc.
> >
> > Do people agree with that text?
> >
> > What's the process for getting a change like this into the guide?
> >
> > Thanks,
> > Dave
> >
> >
> >
>

Re: The podling initial committers issue

[larry mccay]

I propose that this then be seen as a learning experience and determine
what questions a champion needs to ask of the mentors and incoming
community on the outset in order to execute.

This has been an unfortunate bit of thrashing that was avoidable through
communication. That is not to say that it is anyone's fault or anyone is
right or wrong.

We just need the champion/mentor survey questions established.


On Wed, Sep 25, 2013 at 2:09 PM, Jim Jagielski  wrote:

>
> On Sep 25, 2013, at 1:33 PM, larry mccay  wrote:
> >
> > That shared understanding seems to be what was missing in this case.
> >
>
> Indeed that was the case, as I indicated in a previous post.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)

[larry mccay]

+1 (non-binding)


On Tue, Oct 1, 2013 at 1:09 AM, Lieven Govaerts
wrote:

> On Mon, Sep 30, 2013 at 9:27 PM, Dave  wrote:
> > I would like to call for a new vote on Usergrid, a multi-tenant
> > Backend-as-a-Service stack for web & mobile applications based on RESTful
> > APIs, as an Apache Incubator podling.
> >
> +1 (non-binding)
>
> I hope to be able to contribute to this project during incubation.
>
> Lieven
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: please follow through to publish doc changes

[Larry McCay]

Jake, thank you for taking care of that!

I didn't see anything on the Knox mailing list - should I have?
Can you tell me exactly what was fixed and where?

We will be sure to investigate what went wrong and document the proper
procedure going forward.

Is there anything that is outstanding that is still needed from the Knox
community?

Thanks,

--larry


On Tue, Oct 29, 2013 at 11:42 PM, Jake Farrell  wrote:

> I went ahead and fixed the missing  tag Knox had and this should
> resolve the issue you saw David. I also have cleaned up some of the issues
> seen on the voter status page and I just saw that Olivier Lamy committed
> the batchee.xml missing project status page (Thanks Olivier). All changes
> are published and on the incubator website
>
> -Jake
>
>
>
>
> On Tue, Oct 29, 2013 at 9:19 PM, Marvin Humphrey  >wrote:
>
> > On Tue, Oct 29, 2013 at 5:12 PM, David Crossley 
> > wrote:
> >
> > > This continues to be a problem. It is now exacerbated
> > > because someone has made source content errors (knox)
> > > but because people do not bother to try to publish
> > > changes, these errors are not noticed or attended to.
> > >
> > > It is preventing other people from working.
> >
> > Same with podlings.xml.  I don't suppose DeltaSpike is ever going to
> > perform
> > the post-graduation cleanup -- they're going to be getting incubating
> > reporting reminders forever.  Also, somebody's dropped the ball with
> > BatchEE.
> >
> > Marvin Humphrey
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [VOTE] Accept Twill for Incubation

[larry mccay]

+1 (non-binding)


On Fri, Nov 8, 2013 at 6:40 PM, Andrew Purtell  wrote:

> +1 (non-binding)
>
>
> On Thu, Nov 7, 2013 at 1:04 PM, Andreas Neumann  wrote:
>
> > The discussion about the Weave proposal has calmed. As the outcome of the
> > discussion, we have chosen a new name for the project, Twill. I would
> like
> > to call a vote for Twill to become an incubated project.
> >
> > The proposal is pasted below, and also available at:
> > https://wiki.apache.org/incubator/TwillProposal
> >
> > Let's keep this vote open for three business days, closing the voting on
> > Tuesday 11/12.
> >
> > [ ] +1 Accept Twill into the Incubator
> > [ ] +0 Don't care.
> > [ ] -1 Don't accept Twill because...
> >
> > -Andreas.
> >
> > = Abstract =
> >
> > Twill is an abstraction over Apache Hadoop® YARN that reduces the
> > complexity of developing distributed applications, allowing developers to
> > focus more on their business logic.
> >
> > = Proposal =
> >
> > Twill is a set of libraries that reduces the complexity of developing
> > distributed applications. It exposes the distributed capabilities of
> Apache
> > Hadoop® YARN via a simple and intuitive programming model similar to Java
> > threads. Twill also has built-in capabilities required by many
> distributed
> > applications, such as real-time application logs and metrics collection,
> > application lifecycle management, and network service discovery.
> >
> > = Background =
> >
> > Hadoop YARN is a generic cluster resource manager that supports any type
> of
> > distributed application. However, YARN’s interfaces are too low level for
> > rapid application development. It requires a great deal of boilerplate
> code
> > even for a simple application, creating a high ramp up cost that can turn
> > developers away.
> >
> > Twill is designed to improve this situation with a programming model that
> > makes running distributed applications as easy as running Java threads.
> > With the abstraction provided by Twill, applications can be executed in
> > process threads during development and unit testing and then be deployed
> to
> > a YARN cluster without any modifications.
> >
> > Twill also has built-in support for real-time application logs and
> metrics
> > collection, delegation token renewal, application lifecycle management,
> and
> > network service discovery. This greatly reduces the pain that developers
> > face when developing, debugging, deploying and monitoring distributed
> > applications.
> >
> > Twill is not a replacement for YARN, it’s a framework that operates on
> top
> > of YARN.
> >
> > = Rationale =
> >
> > Developers who write YARN applications typically find themselves
> > implementing the same (or similar) boilerplate code over and over again
> > for every application. It makes sense to distill this common code into a
> > reusable set of libraries that is perpetually maintained and improved by
> a
> > diverse community of developers.
> >
> > Twill’s simple thread-like programming model will enable many Java
> > programmers to develop distributed applications. We believe that this
> > simplicity will attract developers who would otherwise be discouraged by
> > complexity, and many new use cases will emerge for the usage of YARN.
> >
> > Incubating Twill as an Apache project makes sense because Twill is a
> > framework built on top of YARN, and Twill uses Apache Zookeeper, HDFS,
> > Kafka, and other Apache software (see the External Dependencies section).
> >
> > = Current Status =
> >
> > Twill was initially developed at Continuuity under the name of Weave. The
> > Weave codebase is currently hosted in a public repository at github.com,
> > which will seed the Apache git repository after renaming to Twill.
> >
> > == Meritocracy ==
> >
> > Our intent with this incubator proposal is to start building a diverse
> > developer community around Twill following the Apache meritocracy model.
> > Since Twill was initially developed in early 2013, we have had fast
> > adoption and contributions within Continuuity. We are looking forward to
> > new contributors. We wish to build a community based on Apache's
> > meritocracy principles, working with those who contribute significantly
> to
> > the project and welcoming them to be committers both during the
> incubation
> > process and beyond.
> >
> > == Community ==
> >
> > Twill is currently being used internally at Continuuity and is at the
> core
> > of our products. We hope to extend our contributor base significantly and
> > we will invite all who are interested in simplifying the development of
> > distributed applications to participate.
> >
> > == Core Developers ==
> >
> > Twill is currently being developed by five engineers at Continuuity:
> > Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert
> > Shau.
> > Terence Yim is an Apache committer for Helix, Andreas is an Apache
> > committer and PMC member for Oozie, and Gary Helmling is an Apache
> > committer and PMC member for HB

[VOTE] Release Apache Knox-0.3.1-incubating RC3

[larry mccay]

Hello All,

This is a call for a vote on Apache Knox Gateway 0.3.1 incubating.

A vote was held on developer mailing list and it passed with 3 +1's, and 0
-1's or +0's and now
requires a vote on general@incubator.apache.org.

The [VOTE] thread can be found at:
http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E

The release candidate is a zip archive of the sources in:
https://git-wip-us.apache.org/repos/asf/incubator-knox.git
Branch v0.3.1 (git checkout -b v0.3.1)

Tag:
https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9

Source archive zip file and signature are available from:
https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip
https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc

Checksums of the source archive:
  SHA1:   04bb11360f57c0431c30cfb181e3199868fe6053

The KEYS file can be found at:

https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/KEYS

The release changes file can be found at:

https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/CHANGES

The release has been signed with key (587C089B):
  http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x82F9C371587C089B

Vote will be open for 72 hours.

thanks,

--larry

Larry McCay

Re: [DISCUSS] Re: [VOTE] Release Apache Knox-0.3.1-incubating RC3

[larry mccay]

Hi Dave -

I'm sorry, we have one Mentor +1 on the PPMC vote.
We will be sure to list those going forward.

Thanks,

--larry


On Fri, Nov 22, 2013 at 7:23 PM, Dave Fisher  wrote:

> How many +1 IPMC Binding Votes did you have from your Mentors?
>
> Putting this information clearly in the thread is very helpful.
>
> Regards,
> Dave
>
> On Nov 20, 2013, at 8:09 AM, larry mccay wrote:
>
> > Hello All,
> >
> > This is a call for a vote on Apache Knox Gateway 0.3.1 incubating.
> >
> > A vote was held on developer mailing list and it passed with 3 +1's, and
> 0
> > -1's or +0's and now
> > requires a vote on general@incubator.apache.org.
> >
> > The [VOTE] thread can be found at:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E
> >
> > The release candidate is a zip archive of the sources in:
> > https://git-wip-us.apache.org/repos/asf/incubator-knox.git
> > Branch v0.3.1 (git checkout -b v0.3.1)
> >
> > Tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9
> >
> > Source archive zip file and signature are available from:
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc
> >
> > Checksums of the source archive:
> >  SHA1:   04bb11360f57c0431c30cfb181e3199868fe6053
> >
> > The KEYS file can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/KEYS
> >
> > The release changes file can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/CHANGES
> >
> > The release has been signed with key (587C089B):
> >  http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x82F9C371587C089B
> >
> > Vote will be open for 72 hours.
> >
> > thanks,
> >
> > --larry
> >
> > Larry McCay
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Knox-0.3.1-incubating RC3

[larry mccay]

Hi Sebb -

Thank you for your review and insight!

We will make these changes immediately and insure that they are correct
going forward.

Do these issues require a new release candidate - or would that only be
indicated by a -1?

thanks,

--larry


On Sat, Nov 23, 2013 at 10:23 AM, sebb  wrote:

> On 20 November 2013 16:09, larry mccay  wrote:
> > Hello All,
> >
> > This is a call for a vote on Apache Knox Gateway 0.3.1 incubating.
> >
> > A vote was held on developer mailing list and it passed with 3 +1's, and
> 0
> > -1's or +0's and now
> > requires a vote on general@incubator.apache.org.
> >
> > The [VOTE] thread can be found at:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E
> >
> > The release candidate is a zip archive of the sources in:
> > https://git-wip-us.apache.org/repos/asf/incubator-knox.git
> > Branch v0.3.1 (git checkout -b v0.3.1)
> >
> > Tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9
>
> The NOTICE file is wrong; the first 6 lines should be removed (i.e.
> lines with == and following blank line)
>
> Also, the text should be:
>
> "This product includes software developed at"
> not
> "This product includes software developed by"
>
> > Source archive zip file and signature are available from:
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc
> >
> > Checksums of the source archive:
> >   SHA1:   04bb11360f57c0431c30cfb181e3199868fe6053
> >
> > The KEYS file can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/KEYS
>
> The KEYS file should really be at the top level of the release area, i.e.
>
> https://dist.apache.org/repos/dist/release/incubator/knox/KEYS
>
> > The release changes file can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/CHANGES
> >
> > The release has been signed with key (587C089B):
> >
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x82F9C371587C089B
> >
> > Vote will be open for 72 hours.
> >
> > thanks,
> >
> > --larry
> >
> > Larry McCay
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Knox-0.3.1-incubating RC3

[larry mccay]

Hello All -

Just to follow up on this thread, we will have these NOTICES file issues
corrected in the next release and assume that this VOTE will continue in
the absence of a -1 vote.

Thank you again, for the insight here.

--larry


On Sat, Nov 23, 2013 at 10:40 AM, larry mccay  wrote:

> Hi Sebb -
>
> Thank you for your review and insight!
>
> We will make these changes immediately and insure that they are correct
> going forward.
>
> Do these issues require a new release candidate - or would that only be
> indicated by a -1?
>
> thanks,
>
> --larry
>
>
> On Sat, Nov 23, 2013 at 10:23 AM, sebb  wrote:
>
>> On 20 November 2013 16:09, larry mccay  wrote:
>> > Hello All,
>> >
>> > This is a call for a vote on Apache Knox Gateway 0.3.1 incubating.
>> >
>> > A vote was held on developer mailing list and it passed with 3 +1's,
>> and 0
>> > -1's or +0's and now
>> > requires a vote on general@incubator.apache.org.
>> >
>> > The [VOTE] thread can be found at:
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E
>> >
>> > The release candidate is a zip archive of the sources in:
>> > https://git-wip-us.apache.org/repos/asf/incubator-knox.git
>> > Branch v0.3.1 (git checkout -b v0.3.1)
>> >
>> > Tag:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9
>>
>> The NOTICE file is wrong; the first 6 lines should be removed (i.e.
>> lines with == and following blank line)
>>
>> Also, the text should be:
>>
>> "This product includes software developed at"
>> not
>> "This product includes software developed by"
>>
>> > Source archive zip file and signature are available from:
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc
>> >
>> > Checksums of the source archive:
>> >   SHA1:   04bb11360f57c0431c30cfb181e3199868fe6053
>> >
>> > The KEYS file can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/KEYS
>>
>> The KEYS file should really be at the top level of the release area, i.e.
>>
>> https://dist.apache.org/repos/dist/release/incubator/knox/KEYS
>>
>> > The release changes file can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/CHANGES
>> >
>> > The release has been signed with key (587C089B):
>> >
>> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x82F9C371587C089B
>> >
>> > Vote will be open for 72 hours.
>> >
>> > thanks,
>> >
>> > --larry
>> >
>> > Larry McCay
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Re: [VOTE] Release Apache Knox-0.3.1-incubating RC3

[Larry McCay]

Will do.
Thank you for the review and vote, Owen!


On Mon, Dec 2, 2013 at 1:09 PM, Owen O'Malley  wrote:

> On further inspection, I see the header is there, but not at the top of the
> file. Please move it in a future release.
>
> -- Owen
>
>
> On Mon, Dec 2, 2013 at 9:56 AM, Owen O'Malley  wrote:
>
> > +1 on the RC. I checked the signatures, looked for license headers,
> built,
> > and ran unit tests.
> >
> > For the next release, please add a license header
> > to
> gateway-shell/src/main/java/org/apache/hadoop/gateway/shell/BasicResponse.java.
> >
> >
> > On Wed, Nov 27, 2013 at 4:26 PM, Devaraj Das 
> wrote:
> >
> >> +1 on the RC. Downloaded, built and ran unit tests.
> >>
> >>
> >> On Mon, Nov 25, 2013 at 8:00 PM, larry mccay  wrote:
> >>
> >> > Hello All -
> >> >
> >> > Just to follow up on this thread, we will have these NOTICES file
> issues
> >> > corrected in the next release and assume that this VOTE will continue
> in
> >> > the absence of a -1 vote.
> >> >
> >> > Thank you again, for the insight here.
> >> >
> >> > --larry
> >> >
> >> >
> >> > On Sat, Nov 23, 2013 at 10:40 AM, larry mccay 
> >> > wrote:
> >> >
> >> > > Hi Sebb -
> >> > >
> >> > > Thank you for your review and insight!
> >> > >
> >> > > We will make these changes immediately and insure that they are
> >> correct
> >> > > going forward.
> >> > >
> >> > > Do these issues require a new release candidate - or would that only
> >> be
> >> > > indicated by a -1?
> >> > >
> >> > > thanks,
> >> > >
> >> > > --larry
> >> > >
> >> > >
> >> > > On Sat, Nov 23, 2013 at 10:23 AM, sebb  wrote:
> >> > >
> >> > >> On 20 November 2013 16:09, larry mccay 
> >> wrote:
> >> > >> > Hello All,
> >> > >> >
> >> > >> > This is a call for a vote on Apache Knox Gateway 0.3.1
> incubating.
> >> > >> >
> >> > >> > A vote was held on developer mailing list and it passed with 3
> >> +1's,
> >> > >> and 0
> >> > >> > -1's or +0's and now
> >> > >> > requires a vote on general@incubator.apache.org.
> >> > >> >
> >> > >> > The [VOTE] thread can be found at:
> >> > >> >
> >> > >>
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E
> >> > >> >
> >> > >> > The release candidate is a zip archive of the sources in:
> >> > >> > https://git-wip-us.apache.org/repos/asf/incubator-knox.git
> >> > >> > Branch v0.3.1 (git checkout -b v0.3.1)
> >> > >> >
> >> > >> > Tag:
> >> > >> >
> >> > >>
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9
> >> > >>
> >> > >> The NOTICE file is wrong; the first 6 lines should be removed (i.e.
> >> > >> lines with == and following blank line)
> >> > >>
> >> > >> Also, the text should be:
> >> > >>
> >> > >> "This product includes software developed at"
> >> > >> not
> >> > >> "This product includes software developed by"
> >> > >>
> >> > >> > Source archive zip file and signature are available from:
> >> > >> >
> >> > >>
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip
> >> > >> >
> >> > >>
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc
> >> > >> >
> >> > >> > Checksums of the source archive:
> >> > >> >   SHA1:   04bb11360f57c0431c30cfb181e3199868fe6053
> >> > >> >
> >> > >>

Re: [VOTE] Release Apache Knox-0.3.1-incubating RC3

[Larry McCay]

Thank you  again, Sebb.
I am noting your new findings here and will fix them asap for the next
release.

I assume that your lack of an actual vote indicates that these fixes can be
made in the next release and that you are not indicating that this RC
should be abandoned. Please let me know if this is an inappropriate
assumption.


On Mon, Dec 2, 2013 at 2:30 PM, sebb  wrote:

> On 20 November 2013 16:09, larry mccay  wrote:
> > Hello All,
> >
> > This is a call for a vote on Apache Knox Gateway 0.3.1 incubating.
> >
> > A vote was held on developer mailing list and it passed with 3 +1's, and
> 0
> > -1's or +0's and now
> > requires a vote on general@incubator.apache.org.
> >
> > The [VOTE] thread can be found at:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E
> >
> > The release candidate is a zip archive of the sources in:
> > https://git-wip-us.apache.org/repos/asf/incubator-knox.git
> > Branch v0.3.1 (git checkout -b v0.3.1)
> >
> > Tag:
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9
>
> The NOTICE file is wrong:
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=blob_plain;f=NOTICE;hb=61e85e0b89b415361159bb973d050bdd8ab92acb
>
> The lines enclosed in == need to be removed.
>
> "This product includes software developed by"
> should be
> "This product includes software developed at"
>
> There is another NOTICE and LICENSE file at
> gatway-release/home
> These are completely different from the ones at the top-level, and
> mention a lot of 3rd party products.
>
> Does the source archive really contain all the 3rd party products as
> source?
> If so, then this needs to be in the NOTICE and LICENSE files at the
> top-level of SCM and the source archive.
> If not, the references need to be removed.
>
> The N&L files must only relate to bits which are actually included in
> the distribution (SCM/source archive/binary archive).
>
> > Source archive zip file and signature are available from:
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc
>
> The source archive contains two copies of the binary archive
> hadoop-examples.jar.
> External binary dependencies should not be bundled in the source (nor
> in the SCM).
>
> > Checksums of the source archive:
> >   SHA1:   04bb11360f57c0431c30cfb181e3199868fe6053
> >
> > The KEYS file can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/KEYS
> >
> > The release changes file can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/CHANGES
> >
> > The release has been signed with key (587C089B):
> >
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x82F9C371587C089B
> >
> > Vote will be open for 72 hours.
>
> (a minimum of)
>
> >
> > thanks,
> >
> > --larry
> >
> > Larry McCay
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

[CANCELLED] [VOTE] Release Apache Knox-0.3.1-incubating RC3

[Larry McCay]

Thank you for your review and insight.
We are canceling this vote to address the NOTICE files and other issues and
then create a new release candidate.


On Mon, Dec 2, 2013 at 4:29 PM, sebb  wrote:

> On 2 December 2013 20:44, Kevin Minder  wrote:
> > Sebb,
> >
> > Thanks for your careful review.  I'd like your continued insight into two
> > specific issues that you have raised.
> >
> > WRT the NOTICE files in root vs gatway-release/home, this is actually an
> > issue that I struggled with when laying things out initially.  We
> certainly
> > don't include the source for 3rd party products anywhere.  This covers
> why
> > they are not mentioned in NOTICE at the top level of the source
> > repo/archive.  The NOTICE file in gatway-release/home ends up in the root
> > of our binary distributions.  This binary distribution does contain the
> > JARs for those 3rd party products.  Therefore I thought I was following
> the
> > rules by having these two NOTICE files be different and represent the
> > actual content of the respective archives.
>
> I see.
> In which case it would be better if the files were called something
> like NOTICE.binary or NOTICE_binary and copied to the appropriate file
> names as part of the assembly descriptor. That would avoid any
> possible confusion for end-users.
>
>
> The binary NOTICE still has "developed by" when it should be "developed
> at".
>
> It's important that the NOTICE file only contains required attributions.
> See http://www.apache.org/dev/licensing-howto.html#mod-notice
>
> It seems to me that some (most?) of the references are *not* required.
> For example the ANTLR license should be covered by the inclusion of
> the text in the LICENSE file. It does not also need to be in NOTICE.
> Similarly for ASM, Bouncy Castle etc.
>
> See the following page for more info on what licenses are permitted in
> binary distributions:
> http://www.apache.org/legal/resolved.html
>
> > For hadoop-examples.jar I understand your reaction.  I would like to try
> > and justify the inclusion for this specific use case however.  This JAR
> is
> > included for "ease of use", especially for first time users.  Basically
> to
> > use Knox with Hadoop you need to have an existing Hadoop "application".
> > Our user's guide walks through an example of uploading and running this
> > sample Hadoop application. (It is not used at compile time at all).  If
> we
> > don't check this into SCM and build it as part of Knox, that would
> create a
> > tight coupling between Knox and a specific Hadoop version only used to
> > create this post-install sample JAR file.  I think about this similar to
> > including a sample JPEG in a image processor distribution.  There you
> > wouldn't expect the JPEG to be build from source.
>
> That's not a good analogy as jpegs are rarely built from source.
>
> There has to be a better way to handle the Hadoop jar.
>
> > All that being said, we
> > certainly shouldn't have two copies, although fixing that will be an
> > interesting maven challenge.
>
> Assembly descriptors allow files to be copied to a different place in
> the archive.
> This is trivial, so there is definitely no need for *two* copies.
>
> AFAIK Maven also allows jars to be included from the local repo, so it
> should be possible to remove the copies from the source entirely.
>
> > Thanks again for your continued feedback!
> >
> > Kevin.
> >
> >
> > On Mon, Dec 2, 2013 at 3:24 PM, sebb  wrote:
> >
> >> On 2 December 2013 20:17, Larry McCay  wrote:
> >> > Thank you  again, Sebb.
> >> > I am noting your new findings here and will fix them asap for the next
> >> > release.
> >> >
> >> > I assume that your lack of an actual vote indicates that these fixes
> can
> >> be
> >> > made in the next release and that you are not indicating that this RC
> >> > should be abandoned. Please let me know if this is an inappropriate
> >> > assumption.
> >>
> >> Sorry, I should have said - I think the problems are blockers.
> >> It's vital that the NOTICE and LICENSE files are correct for ASF
> releases.
> >>
> >> So if I were the RM, I would want to redo the release.
> >>
> >> >
> >> > On Mon, Dec 2, 2013 at 2:30 PM, sebb  wrote:
> >> >
> >> >> On 20 November 2013 16:09, larry mccay 
> wrote:
> >> >> > Hello All,
> >> >> >
> >

Re: [ANNOUNCE] Billie Rinaldi joins the IPMC

[larry mccay]

Congrats, Billie!


On Thu, Dec 12, 2013 at 3:34 PM, Marvin Humphrey wrote:

> Apache Member Billie Rinaldi, the PMC Chair for Accumulo and a member of
> the
> Ambari PMC, has elected to join the Incubator PMC.
>
> May you have as much success as an IPMC member as you had as a PPMC member
> of
> the Accumulo podling!
>
> Marvin Humphrey, on behalf of the Incubator PMC
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Wiki write permissions for LarryMcCay

[larry mccay]

Could I please have wiki write access for LarryMcCay to contribute to the
Hoya
incubator proposal?

Thanks!

Re: Wiki write permissions for LarryMcCay

[larry mccay]

Thanks, sebb!


On Wed, Jan 8, 2014 at 5:31 PM, sebb  wrote:

> Done
>
> On 8 January 2014 18:42, larry mccay  wrote:
> > Could I please have wiki write access for LarryMcCay to contribute to the
> > Hoya
> > incubator proposal?
> >
> > Thanks!
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Hoya Proposal

[larry mccay]

Hi Alejandro -

I believe that Steve has already acknowledged that a package rename is
required and that the project is likely not appropriate for Hadoop proper.

thanks,

--larry


On Thu, Jan 9, 2014 at 11:46 AM, Alejandro Abdelnur wrote:

> I may have not been clear enough, I was referring to using
> 'org.apache.hadoop' as package prefix for a project other than hadoop.
>
> Thanks
>
>
> On Thu, Jan 9, 2014 at 8:36 AM, Benson Margulies  >wrote:
>
> > If you can work out a plan to do this directly in Hadoop, there's no
> > need for the incubator. You just build and and contribute it in
> > cahoots with them, and earn commit over there as you go.
> >
> > On Thu, Jan 9, 2014 at 11:14 AM, Alejandro Abdelnur 
> > wrote:
> > > Mmmh, if i recall correctly this has come up in the past with other
> > projects and it was decided against it. Could you please check with the
> > hadoop folks about it?
> > >
> > > Thx
> > >
> > >> On Jan 9, 2014, at 1:19 AM, Steve Loughran 
> > wrote:
> > >>
> > >> no its wrong, it should all be under org.apache.hoya.
> > >>
> > >> I had the hadoop prefix so that I could perhaps put it straight into
> the
> > >> hadoop code as another tools module -no need for incubation. But as
> the
> > >> actual providers and all tests are related to the deployment of hbase
> > and
> > >> accumulo, it really comes downstream of those.
> > >>
> > >> so a rename is needed.
> > >>
> > >> but yes, ASF headers everywhere
> > >>
> > >>
> > >>> On 8 January 2014 22:48, Henry Saputra 
> > wrote:
> > >>>
> > >>> I like how the initial code already put under "
> > >>> org.apache.hadoop.hoya"  with correct ASF header =)
> > >>>
> > >>> - Henry
> > >>>
> > >>> On Wed, Jan 8, 2014 at 7:08 AM, Steve Loughran <
> ste...@hortonworks.com
> > >
> > >>> wrote:
> >  I'm starting to put together the incubation proposal for Hoya: a
> tool
> > to
> >  dynamically deploy applications such as HBase or Accumulo on YARN
> > 
> >  https://wiki.apache.org/incubator/HoyaProposal
> > 
> >  It does already work to the extent that it can bring up either
> > >>> application,
> >  run different clusters of different versions, and remember where
> > >>> containers
> >  were allocated so that on application restart it can ask for them
> > back.
> >  That increases data locality and makes a big difference with HBase.
> > 
> >  It also needs a lot more work -YARN-896 is adding YARN features that
> > >>> help,
> >  but there's lots of fun to be had in Hoya including
> >  -leading edge work in failure handling, modelling cluster
> > unreliability
> >  and reacting to it. Can we move beyond simple blacklisting to
> >  "greylisting", accepting unreliable boxes if we have no altenatives
> > 
> >  Then there's adding more providers, to support different application
> >  installations -I'm starting to write a functional test framework
> which
> > >>> need
> >  provider-specific workload generations
> > 
> >  Other features: AM should have a web ui that redirects to the live
> >  endpoints to all the app-specific UIs (e.g. HBase Master GUI), as
> > well as
> >  displaying cluster state itself, for people and for management
> > tools
> > 
> >  To summarise: lots of fun to be had
> > 
> >  -steve
> > 
> >  --
> >  CONFIDENTIALITY NOTICE
> >  NOTICE: This message is intended for the use of the individual or
> > entity
> > >>> to
> >  which it is addressed and may contain information that is
> > confidential,
> >  privileged and exempt from disclosure under applicable law. If the
> > reader
> >  of this message is not the intended recipient, you are hereby
> notified
> > >>> that
> >  any printing, copying, dissemination, distribution, disclosure or
> >  forwarding of this communication is strictly prohibited. If you have
> >  received this communication in error, please contact the sender
> > >>> immediately
> >  and delete it from your system. Thank You.
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >>> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >> --
> > >> CONFIDENTIALITY NOTICE
> > >> NOTICE: This message is intended for the use of the individual or
> > entity to
> > >> which it is addressed and may contain information that is
> confidential,
> > >> privileged and exempt from disclosure under applicable law. If the
> > reader
> > >> of this message is not the intended recipient, you are hereby notified
> > that
> > >> any printing, copying, dissemination, distribution, disclosure or
> > >> forwarding of this communication is strictly prohibited. If you have
> > >> received this communication in error, please contact the sender
> > immediately
> > >> and delete it from your system. Thank You.
> > >
> > > --

Re: Hoya Proposal

[larry mccay]

I agree with Marvin. Either works fine.
The original meaning of Hoya doesn't have to continue to be acknowledged.



On Mon, Jan 13, 2014 at 12:02 PM, Marvin Humphrey wrote:

> On Mon, Jan 13, 2014 at 6:33 AM, Steve Loughran 
> wrote:
>
> > On that note, I know we've used the acronym "hoya", HBase on YARN, but
> it is
> > already a bit out of date.
> >
> > What do people think about a project name "Hyena"? It's close enough,
> lives
> > in the savannah...
>
> Based on Google searches for `hoya software` and `hyena software`, it would
> seem that Hoya is more distinctive.
>
> I don't think either of them specifically conveys what the software
> does.  Neither
> is hard to spell or pronounce.  Both are nice and short.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Hoya Proposal

[larry mccay]

Hoya - Hadoop Oriented Yarn Applications.
:)

As Andrew indicates - stick with Hoya.


On Mon, Jan 13, 2014 at 7:18 PM, Andrew Purtell  wrote:

> There isn't anything in the same domain named Hoya that I am aware of. One
> can get to Hoya from other avenues - it is a county and city in Germany; or
> it is the genus for several hundred tropical plants. According to
> http://en.wikipedia.org/wiki/Hoya, hoya flowers grow in a configuration
> referred to as an "umbel", which resembles what one might draw of the
> logical relationship of YARN application processes on the cluster.
>
>
> On Mon, Jan 13, 2014 at 11:07 AM, larry mccay 
> wrote:
>
> > I agree with Marvin. Either works fine.
> > The original meaning of Hoya doesn't have to continue to be acknowledged.
> >
> >
> >
> > On Mon, Jan 13, 2014 at 12:02 PM, Marvin Humphrey <
> mar...@rectangular.com
> > >wrote:
> >
> > > On Mon, Jan 13, 2014 at 6:33 AM, Steve Loughran <
> ste...@hortonworks.com>
> > > wrote:
> > >
> > > > On that note, I know we've used the acronym "hoya", HBase on YARN,
> but
> > > it is
> > > > already a bit out of date.
> > > >
> > > > What do people think about a project name "Hyena"? It's close enough,
> > > lives
> > > > in the savannah...
> > >
> > > Based on Google searches for `hoya software` and `hyena software`, it
> > would
> > > seem that Hoya is more distinctive.
> > >
> > > I don't think either of them specifically conveys what the software
> > > does.  Neither
> > > is hard to spell or pronounce.  Both are nice and short.
> > >
> > > Marvin Humphrey
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: [VOTE] Accept Slider into the incubator

[larry mccay]

+1 (non-binding)
On Apr 17, 2014 9:02 AM, "Steve Loughran"  wrote:

> I'd like to call a vote on accepting Slider into the incubator
>
>
> https://wiki.apache.org/incubator/SliderProposal
>
> [ ] +1 Accept Slider into the Incubator
> [ ] +0 Indifferent to the acceptance of Slider
> [ ] -1 Do not accept Slider because …
>
>
> The vote will be open until Thursday April 24 13:00 UTC
>
> -Steve
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Re: [VOTE] Argus as a new incubator project

[Larry McCay]

+1 (non-binding)


On Mon, Jul 21, 2014 at 12:03 PM, Owen O'Malley  wrote:

> Following the discussion earlier, I'm calling a vote to accept Argus as a
> new Incubator project.
>
>  The proposal draft is available at:
> https://wiki.apache.org/incubator/ArgusProposal, and is also included
>  below.
>
>  Vote is open for 72h and closes at 24 July 2014 at 10am PST.
>
>  [ ] +1 accept Argus in the Incubator
>  [ ] +/-0
>  [ ] -1 because...
>
> I'm +1.
>
> .. Owen
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [DISCUSS] Eagle incubator proposal

[larry mccay]

Arun -

This is a very interesting proposal and I can imagine at least a couple
ways that it and Apache Knox could work together.
I would like to be a contributor to Eagle as well - if you are interested.

I am a committer and PMC member on Knox and Ranger and have contributed to
a number of ecosystem projects on security issues.

Good luck!

--larry

On Thu, Oct 22, 2015 at 4:27 AM, Luke Han  wrote:

> Thanks Henry, I'm also happy to help Eagle for incubating, the experience
> we have
> learnt during Kylin's incubating will share to Eagle team and community.
>
> Sign off reports and vote for release is not only things mentors will help,
> for the process, setup, policy, infrastructure, guidance, workflow, the
> Apache Way and
> so on...a lots of things require mentor's efforts, several active mentors
> are really important
> for new podling committers to learn and practices in their daily work,
>
> We have got help from our mentors very much, hope such experience from
> Kylin will also
> benefits Eagle even other project.
>
>
> Thanks.
>
>
>
>
>
> Best Regards!
> -
>
> Luke Han
>
> On Thu, Oct 22, 2015 at 1:16 PM, Greg Stein  wrote:
>
> > On Thu, Oct 22, 2015 at 12:09 AM, Owen O'Malley 
> > wrote:
> >
> > > On Mon, Oct 19, 2015 at 9:00 AM, Ted Dunning 
> > > wrote:
> > >
> > > > I would suggest that Owen O'Malley has not had enough time to be a
> > viable
> > > > mentor recently and should not be on the list of mentors.
> > > >
> > >
> > > I have been helping Kylin out and it is graduating, so I'm down to just
> > > Hawq. I'd like to help Eagle out.
> > >
> >
> > No need to be on the official list of mentors ... just help out anyways
> ...
> > heck, then you don't have to be responsible for signing off reports ;-)
> >
>

Re: [VOTE] Accept Eagle into Apache Incubation

[larry mccay]

+1 (non-binding)

On Fri, Oct 23, 2015 at 7:11 AM, Manoharan, Arun 
wrote:

> Hello Everyone,
>
> Thanks for all the feedback on the Eagle Proposal.
>
> I would like to call for a [VOTE] on Eagle joining the ASF as an
> incubation project.
>
> The vote is open for 72 hours:
>
> [ ] +1 accept Eagle in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
>
> Eagle is a Monitoring solution for Hadoop to instantly identify access to
> sensitive data, recognize attacks, malicious activities and take actions in
> real time. Eagle supports a wide variety of policies on HDFS data and Hive.
> Eagle also provides machine learning models for detecting anomalous user
> behavior in Hadoop.
>
> The proposal is available on the wiki here:
> https://wiki.apache.org/incubator/EagleProposal
>
> The text of the proposal is also available at the end of this email.
>
> Thanks for your time and help.
>
> Thanks,
> Arun
>
> 
>
> Eagle
>
> Abstract
> Eagle is an Open Source Monitoring solution for Hadoop to instantly
> identify access to sensitive data, recognize attacks, malicious activities
> in hadoop and take actions.
>
> Proposal
> Eagle audits access to HDFS files, Hive and HBase tables in real time,
> enforces policies defined on sensitive data access and alerts or blocks
> user’s access to that sensitive data in real time. Eagle also creates user
> profiles based on the typical access behaviour for HDFS and Hive and sends
> alerts when anomalous behaviour is detected. Eagle can also import
> sensitive data information classified by external classification engines to
> help define its policies.
>
> Overview of Eagle
> Eagle has 3 main parts.
> 1.Data collection and storage - Eagle collects data from various hadoop
> logs in real time using Kafka/Yarn API and uses HDFS and HBase for storage.
> 2.Data processing and policy engine - Eagle allows users to create
> policies based on various metadata properties on HDFS, Hive and HBase data.
> 3.Eagle services - Eagle services include policy manager, query service
> and the visualization component. Eagle provides intuitive user interface to
> administer Eagle and an alert dashboard to respond to real time alerts.
>
> Data Collection and Storage:
> Eagle provides programming API for extending Eagle to integrate any data
> source into Eagle policy evaluation framework. For example, Eagle hdfs
> audit monitoring collects data from Kafka which is populated from namenode
> log4j appender or from logstash agent. Eagle hive monitoring collects hive
> query logs from running job through YARN API, which is designed to be
> scalable and fault-tolerant. Eagle uses HBase as storage for storing
> metadata and metrics data, and also supports relational database through
> configuration change.
>
> Data Processing and Policy Engine:
> Processing Engine: Eagle provides stream processing API which is an
> abstraction of Apache Storm. It can also be extended to other streaming
> engines. This abstraction allows developers to assemble data
> transformation, filtering, external data join etc. without physically bound
> to a specific streaming platform. Eagle streaming API allows developers to
> easily integrate business logic with Eagle policy engine and internally
> Eagle framework compiles business logic execution DAG into program
> primitives of underlying stream infrastructure e.g. Apache Storm. For
> example, Eagle HDFS monitoring transforms audit log from Namenode to object
> and joins sensitivity metadata, security zone metadata which are generated
> from external programs or configured by user. Eagle hive monitoring filters
> running jobs to get hive query string and parses query string into object
> and then joins sensitivity metadata.
> Alerting Framework: Eagle Alert Framework includes stream metadata API,
> scalable policy engine framework, extensible policy engine framework.
> Stream metadata API allows developers to declare event schema including
> what attributes constitute an event, what is the type for each attribute,
> and how to dynamically resolve attribute value in runtime when user
> configures policy. Scalable policy engine framework allows policies to be
> executed on different physical nodes in parallel. It is also used to define
> your own policy partitioner class. Policy engine framework together with
> streaming partitioning capability provided by all streaming platforms will
> make sure policies and events can be evaluated in a fully distributed way.
> Extensible policy engine framework allows developer to plugin a new policy
> engine with a few lines of codes. WSO2 Siddhi CEP engine is the policy
> engine which Eagle supports as first-class citizen.
> Machine Learning module: Eagle provides capabilities to define user
> activity patterns or user profiles for Hadoop users based on the user
> behaviour in the platform. These user profiles are modeled using Machine
> Learning algorithms and used for detection of anomalous users activities.
> Eagle uses Eigen Value Decomposi

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[larry mccay]

+1 - I am concerned by the trend that I see developing here.

A set of interview questions for evaluation is one thing but criteria
checkboxes that will encourage behaviors by rote will not actually develop
more healthy communities just communities that can get the boxes checked.

While certain metrics like adding PMC members may be indicators of natural
growth they should not be required otherwise they will be done artificially.

On Thu, Nov 5, 2015 at 7:30 AM, Justin Erenkrantz 
wrote:

> On Wed, Nov 4, 2015 at 12:50 PM, Roman Shaposhnik 
> wrote:
> > Correct. It is a tool, but not a requirement (at least not yet).
> > And since I repeatedly suggested this tool on this thread let me explain
> why.
>
> And, this is the root of my concern expressed in the other general@
> thread: I fear that this is going to quickly evolve to yet another
> bureaucratic form that the IPMC is going to quickly require all
> projects to complete.
>
> We should not be trying to force rote learning.  Every community is
> different.
>
> Trust the mentors or don't - but, I am very much opposed to more
> overhead.  Forcing projects to feel like they have to report monthly
> is against what we should be about.  I believe that the IPMC should be
> imposing the barest amount of overhead to what the Board requires from
> the full projects.  To that end, having mentors explicitly sign-off is
> fair - but, additional paperwork is not.  -- justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[larry mccay]

Hi Caleb -

I am glad that it is useful for your projects.

I think that the use of it that you describe is valuable.
It should be used as guidance and interpreted by the mentors for each
podling.

"These sort of metrics can be used to indicate health in this way or that"
- this is different from "these specific metrics must be met".

We can certainly articulate requirements but they should be more specific
to behaving in accordance to "the apache way" then dictating very specific
community decisions or milestones.

As mentor training, guidelines, etc - this is quite valuable and should
help in guiding podlings to graduation rather than deciding whether they
graduate or not.

thanks,

--larry

On Thu, Nov 5, 2015 at 1:12 PM, Caleb Welton  wrote:

> I am not in favor of bureaucracy, However...
>
> Having reviewed the maturity model and speaking as a member of a newly
> incubating podling I would like to chime in to say that I find it very
> useful.  It helps frame discussions around what we can be doing as a
> community to embrace the apache way, move towards more inclusive
> development and communication models, and gives a sense of direction we
> need to be moving towards.
>
> Especially starting with an established team working on close source
> project and bringing it into Apache requires some cultural change and
> entering into a newly incubating podling can feel a bit like diving into
> the unknown. Having some structured recommendations on what we can do to
> help move things in the right direction is useful and helps provide
> guidance.  For the communities that I'm engaged with I'm actively
> encouraging us to voluntarily use this tool because I think it provides
> useful guidance.
>
> If you think the tool as expressed enforces "rote learning" how would you
> suggest improving it to account for differences in communities?  Are there
> particular points within the tool that you find less useful, or things that
> are missing?
>
> Regards,
>   Caleb
>
> On Thu, Nov 5, 2015 at 9:49 AM, larry mccay  wrote:
>
> > +1 - I am concerned by the trend that I see developing here.
> >
> > A set of interview questions for evaluation is one thing but criteria
> > checkboxes that will encourage behaviors by rote will not actually
> develop
> > more healthy communities just communities that can get the boxes checked.
> >
> > While certain metrics like adding PMC members may be indicators of
> natural
> > growth they should not be required otherwise they will be done
> > artificially.
> >
> > On Thu, Nov 5, 2015 at 7:30 AM, Justin Erenkrantz  >
> > wrote:
> >
> > > On Wed, Nov 4, 2015 at 12:50 PM, Roman Shaposhnik <
> ro...@shaposhnik.org>
> > > wrote:
> > > > Correct. It is a tool, but not a requirement (at least not yet).
> > > > And since I repeatedly suggested this tool on this thread let me
> > explain
> > > why.
> > >
> > > And, this is the root of my concern expressed in the other general@
> > > thread: I fear that this is going to quickly evolve to yet another
> > > bureaucratic form that the IPMC is going to quickly require all
> > > projects to complete.
> > >
> > > We should not be trying to force rote learning.  Every community is
> > > different.
> > >
> > > Trust the mentors or don't - but, I am very much opposed to more
> > > overhead.  Forcing projects to feel like they have to report monthly
> > > is against what we should be about.  I believe that the IPMC should be
> > > imposing the barest amount of overhead to what the Board requires from
> > > the full projects.  To that end, having mentors explicitly sign-off is
> > > fair - but, additional paperwork is not.  -- justin
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[larry mccay]

Hi Rich -

I have read it and I think that it is really good.
My concern isn't with the document at all - I think that it would have been
great to have earlier.
IMHO, it should not be a measuring stick as much as a teaching tool.

Mentors helping podlings learn what is meant by The Apache Way and what
sorts of things can be seen in successful podlings and TLPs.

Once the mentors feel that a podling has achieved this understanding this
document doesn't really need to be used as criteria.
As soon as it does then the metrics begin to lose their meaning.

The concerns about adding of PPMC members began to feel like we were going
down that road even though that doesn't seem to be in the maturity model
explicitly. It just highlighted a concern that I have about such metrics.

I don't want to take away from the value of the maturity model and the work
that has been put into it in any way.
The 7 Habits of Successful Podlings really is a great idea and would make
an interesting article. :)

Thanks,

--larry

On Fri, Nov 6, 2015 at 2:55 PM, Rich Bowen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 11/05/2015 12:49 PM, larry mccay wrote:
> > +1 - I am concerned by the trend that I see developing here.
> >
> > A set of interview questions for evaluation is one thing but
> > criteria checkboxes that will encourage behaviors by rote will not
> > actually develop more healthy communities just communities that can
> > get the boxes checked.
> >
> > While certain metrics like adding PMC members may be indicators of
> > natural growth they should not be required otherwise they will be
> > done artificially.
>
> Given your comments, I'm curious if you've read the document we're
> discussing. It's here:
> https://community.apache.org/apache-way/apache-project-maturity-model.ht
> ml
>
> It's a set of interview questions for evaluation. None of them can
> really be considered checkboxes, since every one of them requires
> quite a bit of research and thought to fill out, and hardly any of
> them will have a clear yes or no answer, but are rather a goal that we
> all continually strive towards. (Sure, some of them are clearly yes or
> no, but most are not.)
>
>
> >
> > On Thu, Nov 5, 2015 at 7:30 AM, Justin Erenkrantz
> >  wrote:
> >
> >> On Wed, Nov 4, 2015 at 12:50 PM, Roman Shaposhnik
> >>  wrote:
> >>> Correct. It is a tool, but not a requirement (at least not
> >>> yet). And since I repeatedly suggested this tool on this thread
> >>> let me explain
> >> why.
> >>
> >> And, this is the root of my concern expressed in the other
> >> general@ thread: I fear that this is going to quickly evolve to
> >> yet another bureaucratic form that the IPMC is going to quickly
> >> require all projects to complete.
> >>
> >> We should not be trying to force rote learning.  Every community
> >> is different.
> >>
> >> Trust the mentors or don't - but, I am very much opposed to more
> >> overhead.  Forcing projects to feel like they have to report
> >> monthly is against what we should be about.  I believe that the
> >> IPMC should be imposing the barest amount of overhead to what the
> >> Board requires from the full projects.  To that end, having
> >> mentors explicitly sign-off is fair - but, additional paperwork
> >> is not.  -- justin
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail:
> >> general-h...@incubator.apache.org
> >>
> >>
> >
>
>
> - --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iEYEARECAAYFAlY9BcIACgkQXP03+sx4yJPiSgCeJCN75hYHUk4ZQFsSGgq/yKsw
> nIsAnRM7MS6FmrRJfNvZL3f3Hi8TzdIm
> =QDyV
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Project Website Template

[larry mccay]

+1 - this would be a great resource for bootstrapping a new project!

On Sat, Nov 7, 2015 at 5:35 PM, Julian Hyde  wrote:

> +1
>
> I had the same thought when I built Calcite’s site based on jekyll
> (actually cloned from Orc’s site). Thanks for making this template — I’m
> sure it will be helpful to new projects.
>
> We should make it clear that it is optional, of course. But when Calcite
> entered the incubator there were entirely too many choices (and
> opportunities to make mistakes). The whole svnpubsub vs cms question, for
> instance, delayed our web site by about 6 months because we weren’t sure
> whether we could backtrack once we had made a decision. So I think it would
> be useful if there were some default choices to get incubator projects off
> and running quickly.
>
> I also think it would be useful to provide a template for maven/java based
> projects. There would be a pom.xml, module/pom.xml and
> module/org/apache/foo/Foo.java, and just enough content in the pom.xml to
> be able to make a release by typing “mvn release:prepare … mvn
> release:perform”. If anyone is interested I’ll do it.
>
> Luciano, Did you have a place in mind to put your template site? I think
> it would need to be in an apache project, not in github, so that any
> podling can import it without worrying about IP contamination.
>
> Julian
>
>
>
> > On Nov 7, 2015, at 1:21 PM, Ted Dunning  wrote:
> >
> >
> > Easy is good
> >
> >
> > The Jekyll work flow has worked well in the project I have mentored.
> >
> > Sent from my iPhone
> >
> >> On Nov 7, 2015, at 10:04, Luciano Resende  wrote:
> >>
> >> I have just spent a day or so building a new podling website based on
> >> Jekyll and I tried to model it as a template, where a new
> project/podling
> >> can easily modify _data/project.yml and configure it's name, dev list,
> user
> >> list, jira, source repository, etc.
> >>
> >> I was wondering if this would be good as a "template" where new projects
> >> that come on board could easily fork to start their website and just
> change
> >> the styles and contents of main page, and voila, the site would be
> ready,
> >> with all the required trademarks and other apache requirements, etc
> >>
> >> Thoughts ?
> >>
> >> --
> >> Luciano Resende
> >> http://people.apache.org/~lresende
> >> http://twitter.com/lresende1975
> >> http://lresende.blogspot.com/
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Metron incubator proposal

[larry mccay]

This is an interesting proposal that seems would build a community where an
open one doesn't really exist at the moment.
A project like this needs a healthy community to survive and scale with the
pace of changes in attacks.
I for one would be interested in lending a hand as a contributor or
committer - if that would be welcomed.


On Mon, Nov 30, 2015 at 11:55 AM, Owen O'Malley  wrote:

> Hi all,
>
>  We'd like to start a discussion proposing creating Metron as an incubator
> podling. The proposal is on the wiki here:
> https://wiki.apache.org/incubator/MetronProposal
>
> I would call your attention to the background section in particular. The
> condensed version is that the original code base (OpenSOC) was created by a
> company (Cisco) that put it on github as ALv2, but then hasn't been working
> on it. We posted a message
> 
> to the OpenSOC support group a month ago proposing a move to Apache and got
> a single positive response.
>
> The text of the proposal is included below for easy quoting during
> discussion.
>
> Thanks,
>Owen
>
> = Apache Metron Proposal =
>
> == Abstract ==
>
> The Metron project is an open source project dedicated to providing an
> extensible and scalable advanced security analytics tool. It has strong
> foundations in the Apache Hadoop ecosystem.
>
> == Proposal ==
>
> Metron integrates a variety of open source big data technologies in order
> to offer a centralized tool for security monitoring and analysis. Metron
> provides capabilities for log aggregation, full packet capture indexing,
> storage, advanced behavioral analytics and data enrichment, while applying
> the most current threat-intelligence information to security telemetry
> within a single platform.
>
> Metron can be divided into 4 areas:
>
>   1. '''A mechanism to capture, store, and normalize any type of security
> telemetry at extremely high rates.''' Because security telemetry is
> constantly being generated, it requires a method for ingesting the data at
> high speeds and pushing it to various processing units for advanced
> computation and analytics.
>   1. '''Real time processing and application of enrichments''' such as
> threat intelligence, geolocation, and DNS information to telemetry being
> collected. The immediate application of this information to incoming
> telemetry provides the context and situational awareness, as well as the
> “who” and “where” information that is critical for investigation.
>   1. '''Efficient information storage''' based on how the information will
> be used:
> a. Logs and telemetry are stored such that they can be efficiently
> mined and analyzed for concise security visibility
> a. The ability to extract and reconstruct full packets helps an analyst
> answer questions such as who the true attacker was, what data was leaked,
> and where that data was sent
> a. Long-term storage not only increases visibility over time, but also
> enables advanced analytics such as machine learning techniques to be used
> to create models on the information. Incoming data can then be scored
> against these stored models for advanced anomaly detection.
>   1. '''An interface that gives a security investigator a centralized view
> of data and alerts passed through the system.''' Metron’s interface
> presents alert summaries with threat intelligence and enrichment data
> specific to that alert on one single page. Furthermore, advanced search
> capabilities and full packet extraction tools are presented to the analyst
> for investigation without the need to pivot into additional tools.
>
> Big data is a natural fit for powerful security analytics. The Metron
> framework integrates a number of elements from the Hadoop ecosystem to
> provide a scalable platform for security analytics, incorporating such
> functionality as full-packet capture, stream processing, batch processing,
> real-time search, and telemetry aggregation. With Metron, our goal is to
> tie big data into security analytics and drive towards an extensible
> centralized platform to effectively enable rapid detection and rapid
> response for advanced security threats.
>
> == Background ==
>
> OpenSOC was developed by Cisco over the last two years and pushed out to
> Github (https://github.com/OpenSOC/opensoc) under the ALv2. However, the
> development was mostly closed and has largely stopped. As evidence of the
> inactivity, users have complained that pull requests are not answered for a
> while
> https://groups.google.com/d/msg/opensoc-support/R2W-ZFux8Vk/Y-5tL-EmAAAJ.
> Finally, no public releases of OpenSOC have been made. From an Apache point
> of view, the current community is not viable.
>
> However, some of the developers of the project have left Cisco and have
> found interest from several others that would like to work together to form
> an active and open community at Apache starting from the current OpenSOC
> code base. A message to 

Re: [DISCUSS] Metron incubator proposal

[larry mccay]

Terrific - thank you!


On Wed, Dec 2, 2015 at 1:38 AM, Owen O'Malley  wrote:

> On Mon, Nov 30, 2015 at 4:06 PM, P. Taylor Goetz 
> wrote:
>
> > I'm interested as well, particularly given the ties to Storm.
> >
> > I'd be happy to volunteer as mentor and/or committer if it would be
> > welcome. I have some familiarity with both projects (obviously one more
> so
> > than the other ;) ).
> >
>
> I had the project vote off-list on adding Larry and Taylor to the project
> and the result of both votes was 12 +1's and no -1's. I've added them to
> the proposal.
>
> .. Owen
>
>
> >
> > -Taylor
> >
> > > On Nov 30, 2015, at 1:15 PM, larry mccay  wrote:
> > >
> > > This is an interesting proposal that seems would build a community
> where
> > an
> > > open one doesn't really exist at the moment.
> > > A project like this needs a healthy community to survive and scale with
> > the
> > > pace of changes in attacks.
> > > I for one would be interested in lending a hand as a contributor or
> > > committer - if that would be welcomed.
> > >
> > >
> > >> On Mon, Nov 30, 2015 at 11:55 AM, Owen O'Malley 
> > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> We'd like to start a discussion proposing creating Metron as an
> > incubator
> > >> podling. The proposal is on the wiki here:
> > >> https://wiki.apache.org/incubator/MetronProposal
> > >>
> > >> I would call your attention to the background section in particular.
> The
> > >> condensed version is that the original code base (OpenSOC) was created
> > by a
> > >> company (Cisco) that put it on github as ALv2, but then hasn't been
> > working
> > >> on it. We posted a message
> > >> <
> > https://groups.google.com/d/msg/opensoc-support/rFlW2uSSvmU/Sw_cO-T2AAAJ
> >
> > >> to the OpenSOC support group a month ago proposing a move to Apache
> and
> > got
> > >> a single positive response.
> > >>
> > >> The text of the proposal is included below for easy quoting during
> > >> discussion.
> > >>
> > >> Thanks,
> > >>   Owen
> > >>
> > >> = Apache Metron Proposal =
> > >>
> > >> == Abstract ==
> > >>
> > >> The Metron project is an open source project dedicated to providing an
> > >> extensible and scalable advanced security analytics tool. It has
> strong
> > >> foundations in the Apache Hadoop ecosystem.
> > >>
> > >> == Proposal ==
> > >>
> > >> Metron integrates a variety of open source big data technologies in
> > order
> > >> to offer a centralized tool for security monitoring and analysis.
> Metron
> > >> provides capabilities for log aggregation, full packet capture
> indexing,
> > >> storage, advanced behavioral analytics and data enrichment, while
> > applying
> > >> the most current threat-intelligence information to security telemetry
> > >> within a single platform.
> > >>
> > >> Metron can be divided into 4 areas:
> > >>
> > >>  1. '''A mechanism to capture, store, and normalize any type of
> security
> > >> telemetry at extremely high rates.''' Because security telemetry is
> > >> constantly being generated, it requires a method for ingesting the
> data
> > at
> > >> high speeds and pushing it to various processing units for advanced
> > >> computation and analytics.
> > >>  1. '''Real time processing and application of enrichments''' such as
> > >> threat intelligence, geolocation, and DNS information to telemetry
> being
> > >> collected. The immediate application of this information to incoming
> > >> telemetry provides the context and situational awareness, as well as
> the
> > >> “who” and “where” information that is critical for investigation.
> > >>  1. '''Efficient information storage''' based on how the information
> > will
> > >> be used:
> > >>a. Logs and telemetry are stored such that they can be efficiently
> > >> mined and analyzed for concise security visibility
> > >>a. The ability to extract and reconstruct full packets helps an
> > analyst
> > >

Re: [VOTE] Accept Metron into Apache Incubator

[larry mccay]

+1 (non-binding)

On Thu, Dec 3, 2015 at 12:43 PM, Chris Nauroth 
wrote:

> +1 (binding)
>
> --Chris Nauroth
>
>
>
>
> On 12/3/15, 9:33 AM, "Owen O'Malley"  wrote:
>
> >The [DISCUSS] thread has would down, so I'd like to start a VOTE on
> >whether
> >Apache Incubator should accept Metron as a podling. The proposal is pasted
> >below and is available on the wiki as well.
> >
> >https://wiki.apache.org/incubator/MetronProposal
> >
> >We've added a paragraph in the background section discussing how Apache
> >avoids hostile forks of projects, because we don't want to fork
> >communities. We've also added Larry McCay, P. Taylor Goetz, and Phillip
> >Rhodes to the proposal.
> >
> >The vote will run until 12pm PST on Sunday.
> >
> >Thanks,
> >   Owen
> >
> >= Apache Metron Proposal =
> >
> >
> >/!\ '''FINAL''' /!\
> >
> >This proposal is now complete and has been submitted for a VOTE.
> >
> >
> >== Abstract ==
> >
> >The Metron project is an open source project dedicated to providing an
> >extensible and scalable advanced security analytics tool. It has strong
> >foundations in the Apache Hadoop ecosystem.
> >
> >== Proposal ==
> >
> >Metron integrates a variety of open source big data technologies in order
> >to offer a centralized tool for security monitoring and analysis. Metron
> >provides capabilities for log aggregation, full packet capture indexing,
> >storage, advanced behavioral analytics and data enrichment, while applying
> >the most current threat-intelligence information to security telemetry
> >within a single platform.
> >
> >Metron can be divided into 4 areas:
> >
> >  1. '''A mechanism to capture, store, and normalize any type of security
> >telemetry at extremely high rates.''' Because security telemetry is
> >constantly being generated, it requires a method for ingesting the data at
> >high speeds and pushing it to various processing units for advanced
> >computation and analytics.
> >  1. '''Real time processing and application of enrichments''' such as
> >threat intelligence, geolocation, and DNS information to telemetry being
> >collected. The immediate application of this information to incoming
> >telemetry provides the context and situational awareness, as well as the
> >³who² and ³where² information that is critical for investigation.
> >  1. '''Efficient information storage''' based on how the information will
> >be used:
> >a. Logs and telemetry are stored such that they can be efficiently
> >mined and analyzed for concise security visibility
> >a. The ability to extract and reconstruct full packets helps an
> >analyst
> >answer questions such as who the true attacker was, what data was leaked,
> >and where that data was sent
> >a. Long-term storage not only increases visibility over time, but also
> >enables advanced analytics such as machine learning techniques to be used
> >to create models on the information. Incoming data can then be scored
> >against these stored models for advanced anomaly detection.
> >  1. '''An interface that gives a security investigator a centralized view
> >of data and alerts passed through the system.''' Metron¹s interface
> >presents alert summaries with threat intelligence and enrichment data
> >specific to that alert on one single page. Furthermore, advanced search
> >capabilities and full packet extraction tools are presented to the analyst
> >for investigation without the need to pivot into additional tools.
> >
> >Big data is a natural fit for powerful security analytics. The Metron
> >framework integrates a number of elements from the Hadoop ecosystem to
> >provide a scalable platform for security analytics, incorporating such
> >functionality as full-packet capture, stream processing, batch processing,
> >real-time search, and telemetry aggregation. With Metron, our goal is to
> >tie big data into security analytics and drive towards an extensible
> >centralized platform to effectively enable rapid detection and rapid
> >response for advanced security threats.
> >
> >== Background ==
> >
> >OpenSOC was developed by Cisco over the last two years and pushed out to
> >Github (https://github.com/OpenSOC/opensoc) under the ALv2. However, the
> >development was mostly closed and has largely stopped. As evidence of the
>

Re: [VOTE] Release of Apache Tephra-0.14.0-incubating [rc1]

[larry mccay]

* built from source and ran all unit tests - over 1hr!
* checked LICENSE and NOTICE files
* Noticed things that others have already noted
* Noted that there is no CHANGES file in the release artifact - there is a
CHANGES.txt in
https://dist.apache.org/repos/dist/dev/incubator/tephra/0.14.0-incubating-rc1/
but this is not
cumulative across releases which is what I would expect

Nothing that should block the release.

+1


On Wed, May 23, 2018 at 8:13 PM, Billie Rinaldi  wrote:

> +1 binding.
>
> One odd thing I noticed was the existence of these directories in the
> source tarball, but since they don't contain any files they can be
> addressed in the next release:
> apache-tephra-0.14.0-incubating/${project.basedir}/
> apache-tephra-0.14.0-incubating/${project.basedir}/src
> apache-tephra-0.14.0-incubating/${project.basedir}/src/main
> apache-tephra-0.14.0-incubating/${project.basedir}/src/main/site
> apache-tephra-0.14.0-incubating/${project.basedir}/src/main/site/resources
> apache-tephra-0.14.0-incubating/${project.basedir}/
> src/main/site/resources/repo
>
> Another thing I would suggest addressing is that the jars published to the
> maven repo don't contain LICENSE and NOTICE files. I'm not sure how this
> happened, since these files are typically added by default when projects
> use the ASF parent pom.
>
> Billie
>
> On 5/21/18 6:51 PM, James Taylor wrote:
>
> > Hi all,
> >
> > This is a call for a vote on releasing Apache Tephra 0.14.0-incubating,
> > release candidate 1. This is the seventh release of Tephra. The Tephra
> dev
> > community has voted on and approved a proposal to release Tephra
> > 0.14.0-incubating, release candidate 1.
> >
> > PPMC Vote Call: https://s.apache.org/jWVD
> >
> > PPMC Vote Result: https://s.apache.org/zwog
> >
> > The source tarball, including signatures, digests, etc. can be found at:
> > https://dist.apache.org/repos/dist/dev/incubator/tephra/0.14
> > .0-incubating-rc1/src
> >
> > The tag to be voted upon is v0.14.0-incubating:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-tephra.g
> > it;a=shortlog;h=refs/tags/v0.14.0-incubating
> >
> > The release hash is e93942adae0ece286157a8f6a2e5c63b53669e03:
> > https://git-wip-us.apache.org/repos/asf?p=incubator-tephra.g
> > it;a=commit;h=e93942adae0ece286157a8f6a2e5c63b53669e03
> >
> > The Nexus Staging URL:
> > https://repository.apache.org/content/repositories/orgapachetephra-1011
> >
> > Release artifacts are signed with the following key:
> > http://people.apache.org/keys/committer/jamestaylor
> >
> > KEYS file available:
> > https://dist.apache.org/repos/dist/dev/incubator/tephra/KEYS
> >
> > For information about the contents of this release, see:
> > https://dist.apache.org/repos/dist/dev/incubator/tephra/0.14
> > .0-incubating-rc1/CHANGES.txt
> >
> > Please vote on releasing this package as Apache Tephra 0.14.0-incubating
> >
> > The vote will be open for 72 hours.
> >
> > [ ] +1 Release this package as Apache Tephra 0.14.0-incubating
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because ...
> >
> > Thanks,
> > James
>

Re: Is Livy podling still active?

[larry mccay]

I would be willing to join livy as a committer and mentor in a reboot if
there is interest.


On Mon, Jul 4, 2022, 3:05 AM Calvin Kirs  wrote:

> We had discussions last year, graduate or retire[1], but the project
> still keep has remained downturn.
>
> Therefore, I agree to retire.
>
> [1]https://lists.apache.org/thread/3w2bbotwqr8sr59ojhqkcwt3p9wbq793
>
> Jean-Baptiste Onofré  于2022年7月4日周一 13:30写道：
> >
> > Agree to move forward with a formal retirement vote.
> >
> > Regards
> > JB
> >
> > On Mon, May 9, 2022 at 12:13 AM John D. Ament 
> wrote:
> > >
> > > Hi all
> > >
> > > Based on the discussions, it seems like we should start a formal
> retirement
> > > vote.  I will plan to start it within the next couple of days unless
> > > someone else does.
> > >
> > > John
> > >
> > > On Tue, Apr 5, 2022 at 9:38 AM sebb  wrote:
> > >
> > > > On Tue, 5 Apr 2022 at 13:27, Jean-Baptiste Onofré 
> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > AFAIR, a report has been submitted since. Report on cwiki doesn't
> mean
> > > > > it's the last send, we should check in the incubator board report.
> > > > >
> > > > > It's true that Livy is a "stable" project and kind of "mature"
> > > > > podling. IMHO, it should have graduated to TLP.
> > > >
> > > > Huh?
> > > > That would require an active PMC, for which there is little evidence.
> > > >
> > > > > As said, I tried to restart podling activity, but I didn't get a
> lot
> > > > > of updates: most people are Livy users but they don't seem to want
> to
> > > > > become contributors.
> > > >
> > > > Nor does anyone seem to want to deal with issues.
> > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > > On Tue, Apr 5, 2022 at 8:56 AM Javi Roman 
> wrote:
> > > > > >
> > > > > > Hi community!
> > > > > >
> > > > > > I see that the project is losing interest from the community,
> however
> > > > it is
> > > > > > a project widely used by companies (I know personally). It is a
> pity
> > > > that
> > > > > > the project may die.
> > > > > >
> > > > > > In my opinion one of the first actions to take is to recreate the
> > > > reports
> > > > > > correctly (Podling reports). I have seen that the last one sent
> was in
> > > > > > August last year [1].
> > > > > >
> > > > > > Personally I would like to get involved in this project and help
> in
> > > > > > restarting it. If you like, I could be in charge of the next
> report, if
> > > > > > there is no inconvenience.
> > > > > >
> > > > > > [1]
> https://cwiki.apache.org/confluence/display/INCUBATOR/August2021
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 4, 2022 at 9:44 AM Jean-Baptiste Onofré <
> j...@nanthrax.net>
> > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > You are right, I tried to bring Livy podling back to active.
> We had
> > > > > > > few PRs/contributions and I also worked on reload4j switch and
> so on.
> > > > > > >
> > > > > > > If the activity around the code is low, there are few.
> Unfortunately,
> > > > > > > the mailing list is pretty quiet.
> > > > > > >
> > > > > > > Regards
> > > > > > > JB
> > > > > > >
> > > > > > > On Sun, Apr 3, 2022 at 11:46 PM Luciano Resende <
> > > > luckbr1...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > There seem to have been a couple of initiatives to reboot the
> > > > podling and
> > > > > > > > make it healthy again but without much success.
> > > > > > > >
> > > > > > > > What are other mentors' thoughts?
> > > > > > > >
> > > > > > > > On Sun, Apr 3, 2022 at 12:59 PM sebb 
> wrote:
> > > > > > > >
> > > > > > > > > There doesn't seem to be any recent activity on the mailing
> > > > lists, and
> > > > > > > > > no recent commits.
> > > > > > > > >
> > > > > > > > > Sebb
> > > > > > > > >
> > > > > > > > >
> > > > -
> > > > > > > > > To unsubscribe, e-mail:
> general-unsubscr...@incubator.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > > general-h...@incubator.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Luciano Resende
> > > > > > > > http://twitter.com/lresende1975
> > > > > > > > http://lresende.blogspot.com/
> > > > > > >
> > > > > > >
> -
> > > > > > > To unsubscribe, e-mail:
> general-unsubscr...@incubator.apache.org
> > > > > > > For additional commands, e-mail:
> general-h...@incubator.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >

Re: Is Livy podling still active?

[larry mccay]

Haven't seen any additional movement on this thread.
Just curious whether anyone has considered a graduation into an existing
TLP like Spark which would be very appropriate.

Interesting and well stated post on the need for Livy here:
https://www.linkedin.com/posts/activity-6953087197935763456-yoDW/?utm_source=linkedin_share&utm_medium=member_desktop_web


On Mon, Jul 4, 2022 at 9:55 AM larry mccay  wrote:

> I would be willing to join livy as a committer and mentor in a reboot if
> there is interest.
>
>
> On Mon, Jul 4, 2022, 3:05 AM Calvin Kirs  wrote:
>
>> We had discussions last year, graduate or retire[1], but the project
>> still keep has remained downturn.
>>
>> Therefore, I agree to retire.
>>
>> [1]https://lists.apache.org/thread/3w2bbotwqr8sr59ojhqkcwt3p9wbq793
>>
>> Jean-Baptiste Onofré  于2022年7月4日周一 13:30写道：
>> >
>> > Agree to move forward with a formal retirement vote.
>> >
>> > Regards
>> > JB
>> >
>> > On Mon, May 9, 2022 at 12:13 AM John D. Ament 
>> wrote:
>> > >
>> > > Hi all
>> > >
>> > > Based on the discussions, it seems like we should start a formal
>> retirement
>> > > vote.  I will plan to start it within the next couple of days unless
>> > > someone else does.
>> > >
>> > > John
>> > >
>> > > On Tue, Apr 5, 2022 at 9:38 AM sebb  wrote:
>> > >
>> > > > On Tue, 5 Apr 2022 at 13:27, Jean-Baptiste Onofré 
>> wrote:
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > AFAIR, a report has been submitted since. Report on cwiki doesn't
>> mean
>> > > > > it's the last send, we should check in the incubator board report.
>> > > > >
>> > > > > It's true that Livy is a "stable" project and kind of "mature"
>> > > > > podling. IMHO, it should have graduated to TLP.
>> > > >
>> > > > Huh?
>> > > > That would require an active PMC, for which there is little
>> evidence.
>> > > >
>> > > > > As said, I tried to restart podling activity, but I didn't get a
>> lot
>> > > > > of updates: most people are Livy users but they don't seem to
>> want to
>> > > > > become contributors.
>> > > >
>> > > > Nor does anyone seem to want to deal with issues.
>> > > >
>> > > > > Regards
>> > > > > JB
>> > > > >
>> > > > > On Tue, Apr 5, 2022 at 8:56 AM Javi Roman 
>> wrote:
>> > > > > >
>> > > > > > Hi community!
>> > > > > >
>> > > > > > I see that the project is losing interest from the community,
>> however
>> > > > it is
>> > > > > > a project widely used by companies (I know personally). It is a
>> pity
>> > > > that
>> > > > > > the project may die.
>> > > > > >
>> > > > > > In my opinion one of the first actions to take is to recreate
>> the
>> > > > reports
>> > > > > > correctly (Podling reports). I have seen that the last one sent
>> was in
>> > > > > > August last year [1].
>> > > > > >
>> > > > > > Personally I would like to get involved in this project and
>> help in
>> > > > > > restarting it. If you like, I could be in charge of the next
>> report, if
>> > > > > > there is no inconvenience.
>> > > > > >
>> > > > > > [1]
>> https://cwiki.apache.org/confluence/display/INCUBATOR/August2021
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Apr 4, 2022 at 9:44 AM Jean-Baptiste Onofré <
>> j...@nanthrax.net>
>> > > > wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > You are right, I tried to bring Livy podling back to active.
>> We had
>> > > > > > > few PRs/contributions and I also worked on reload4j switch
>> and so on.
>> > > > > > >
>> > > > > > > If the activity around the code is low, there are few.
>> Unfortunately,
>> > > > > > > the ma

Re: [DISCUSS] Retire Livy podling

[larry mccay]

Folks,

As I mentioned in a previous thread [1], I would like to help avoid sending
a well regarded, actively consumed and mature product to the attic. There
have been discussions internally at my employer and we have also struggled
getting our contributions committed. The original group of committers seem
to have all moved on, and this is the core challenge for those that are
trying to contribute, but are not committers.  This doesn’t represent a
lack of interest in doing so and I think there are others in this position.

We are interested in trying to reboot with additional PPMC leadership and
investing in contributors that we would like to install as new committers.

I’d like to hear what the incubator would think about a Reproposal for the
Livy project that would be open to existing PMC members and committers as
well as new contributors with a vested interest in this project and the
health of its community.

How would we best propose such a thing here?

Thanks,

–larry


   1.

   https://lists.apache.org/list?general@incubator.apache.org:2022-7


On Thu, Oct 6, 2022 at 5:21 AM Luciano Resende  wrote:

> Based on the failed attempts to resurrect a community, +1 for retirement.
>
> On Wed, Oct 5, 2022 at 07:26 Jean-Baptiste Onofré  wrote:
>
> > Hi guys,
> >
> > After several attempts, we are struggling to execute Livy podling: the
> > activity is pretty low, and even after a couple of calls for action,
> > we don't have a clear sign of community around Livy.
> >
> > I would like to discuss/propose to retire the Livy podling.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > --
> Sent from my Mobile device
>

Re: [DISCUSS] Retire Livy podling

[larry mccay]

I was hoping that we could bring a set of contributors as:

* mentors - 1 or 2 plus whoever wants to remain
* PPMC/Committers - 2 or 3 plus whoever wants to remain
* election of a PPMC chair if needed

Also open it up for folks to ask to join (as well as go emeritus) as I know
there are others that have tried to contribute and have gotten know where
or have long since decided it wasn't worth trying anymore.

So, my thought was almost a new Proposal and solicitation for community
bootstrap with a few seeds planted to help it grow.
I was also considering a goal of getting it back off the ground with some
number of releases and proof of health as a project to fast track to a
graduation discussion.
A bit early to talk about that now but that was a detail that I thought
would possibly go into such a reboot proposal.

@Jean-Baptiste - we have compiled a list of features/improvements that we
would be able to bring to the table with the reboot as well.
These are improvements that have been made internally due the sense of not
being able to get them in. I lack the details around the attempts at this
time but we would be bringing source as well.
We could list these as part of the proposal/concrete plans.

If you think this proposal can be done more casually, that's fine too. I
just would like to make it clear that we would open it up to new folks as
well.

However you'd like to see it done, we can have concrete commitments to you
within a week or so more than likely.

BTW, I did note that Ambari was sent to the attic and then pulled back out
[1] back in June into July of this year.
I would hope that we could avoid the administrative headache that seems to
have been involved in that reinstatement.

1. https://issues.apache.org/jira/browse/ATTIC-205

On Fri, Oct 7, 2022 at 11:04 AM Claude Warren, Jr
 wrote:

> Larry et.al.
>
> I think we need concrete steps. So if Larry produced a list of new
> committers could we get them added to the list and see if development
> starts again?
>
> Mentors / Champion does that work for you?
>
> Larry, can you produce such a list?
>
> Is there an objection to proceeding along these lines?
>
> Claude
>
> On Fri 7 Oct 2022, 03:07 Jean-Baptiste Onofré,  wrote:
>
> > Hi Larry,
> >
> > I tried maybe 3 times to get Livy back to active, without success.
> > I was a volunteer to contribute, but not alone, we need a community
> around
> > Livy.
> >
> > I don't remember having seen new active contributions on the mailing
> > list, and very limited on source code.
> >
> > If you really think we can have a team, that would be great, and I
> > still agree to support. But it has to be concrete.
> >
> > Let's see what the other IPMC members are thinking, but IMHO, I doubt
> > we will have Livy back to life in the short term.
> >
> > Regards
> > JB
> >
> > On Thu, Oct 6, 2022 at 5:29 PM larry mccay  wrote:
> > >
> > > Folks,
> > >
> > > As I mentioned in a previous thread [1], I would like to help avoid
> > sending
> > > a well regarded, actively consumed and mature product to the attic.
> There
> > > have been discussions internally at my employer and we have also
> > struggled
> > > getting our contributions committed. The original group of committers
> > seem
> > > to have all moved on, and this is the core challenge for those that are
> > > trying to contribute, but are not committers.  This doesn’t represent a
> > > lack of interest in doing so and I think there are others in this
> > position.
> > >
> > > We are interested in trying to reboot with additional PPMC leadership
> and
> > > investing in contributors that we would like to install as new
> > committers.
> > >
> > > I’d like to hear what the incubator would think about a Reproposal for
> > the
> > > Livy project that would be open to existing PMC members and committers
> as
> > > well as new contributors with a vested interest in this project and the
> > > health of its community.
> > >
> > > How would we best propose such a thing here?
> > >
> > > Thanks,
> > >
> > > –larry
> > >
> > >
> > >1.
> > >
> > >https://lists.apache.org/list?general@incubator.apache.org:2022-7
> > >
> > >
> > > On Thu, Oct 6, 2022 at 5:21 AM Luciano Resende 
> > wrote:
> > >
> > > > Based on the failed attempts to resurrect a community, +1 for
> > retirement.
> > > >
> > > > On Wed, Oct 5, 2022 at 07:26 Jean-Baptiste Onofré 
> > wrote:
> > > >
> > > > 

Re: [DISCUSS] Retire Livy podling

[larry mccay]

Good to hear, Jean-Baptiste!
We will send the proposal both here and to the Livy private list, I guess.
Once we come to an agreement and direction we can share with the dev@ and
user@ lists.

Thanks again!

--larry

On Sat, Oct 8, 2022 at 12:49 AM Jean-Baptiste Onofré 
wrote:

> Hi Larry,
>
> Agree with Claude: if we can have concrete proposal (in terms of
> community and roadmap), it's OK. We are not in a rush, if we can have
> this in the commit weeks, it's fine.
> I would sent this on the Livy mailing list.
>
> Again, I would be more than happy to help and contribute on Livy.
>
> Regards
> JB
>
> On Fri, Oct 7, 2022 at 6:08 PM larry mccay  wrote:
> >
> > I was hoping that we could bring a set of contributors as:
> >
> > * mentors - 1 or 2 plus whoever wants to remain
> > * PPMC/Committers - 2 or 3 plus whoever wants to remain
> > * election of a PPMC chair if needed
> >
> > Also open it up for folks to ask to join (as well as go emeritus) as I
> know
> > there are others that have tried to contribute and have gotten know where
> > or have long since decided it wasn't worth trying anymore.
> >
> > So, my thought was almost a new Proposal and solicitation for community
> > bootstrap with a few seeds planted to help it grow.
> > I was also considering a goal of getting it back off the ground with some
> > number of releases and proof of health as a project to fast track to a
> > graduation discussion.
> > A bit early to talk about that now but that was a detail that I thought
> > would possibly go into such a reboot proposal.
> >
> > @Jean-Baptiste - we have compiled a list of features/improvements that we
> > would be able to bring to the table with the reboot as well.
> > These are improvements that have been made internally due the sense of
> not
> > being able to get them in. I lack the details around the attempts at this
> > time but we would be bringing source as well.
> > We could list these as part of the proposal/concrete plans.
> >
> > If you think this proposal can be done more casually, that's fine too. I
> > just would like to make it clear that we would open it up to new folks as
> > well.
> >
> > However you'd like to see it done, we can have concrete commitments to
> you
> > within a week or so more than likely.
> >
> > BTW, I did note that Ambari was sent to the attic and then pulled back
> out
> > [1] back in June into July of this year.
> > I would hope that we could avoid the administrative headache that seems
> to
> > have been involved in that reinstatement.
> >
> > 1. https://issues.apache.org/jira/browse/ATTIC-205
> >
> > On Fri, Oct 7, 2022 at 11:04 AM Claude Warren, Jr
> >  wrote:
> >
> > > Larry et.al.
> > >
> > > I think we need concrete steps. So if Larry produced a list of new
> > > committers could we get them added to the list and see if development
> > > starts again?
> > >
> > > Mentors / Champion does that work for you?
> > >
> > > Larry, can you produce such a list?
> > >
> > > Is there an objection to proceeding along these lines?
> > >
> > > Claude
> > >
> > > On Fri 7 Oct 2022, 03:07 Jean-Baptiste Onofré, 
> wrote:
> > >
> > > > Hi Larry,
> > > >
> > > > I tried maybe 3 times to get Livy back to active, without success.
> > > > I was a volunteer to contribute, but not alone, we need a community
> > > around
> > > > Livy.
> > > >
> > > > I don't remember having seen new active contributions on the mailing
> > > > list, and very limited on source code.
> > > >
> > > > If you really think we can have a team, that would be great, and I
> > > > still agree to support. But it has to be concrete.
> > > >
> > > > Let's see what the other IPMC members are thinking, but IMHO, I doubt
> > > > we will have Livy back to life in the short term.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Thu, Oct 6, 2022 at 5:29 PM larry mccay 
> wrote:
> > > > >
> > > > > Folks,
> > > > >
> > > > > As I mentioned in a previous thread [1], I would like to help avoid
> > > > sending
> > > > > a well regarded, actively consumed and mature product to the attic.
> > > There
> > > > > have been discussions internally at my employer and we have also
> 

Re: [DISCUSS] Retire Livy podling

[larry mccay]

Sure.
Thanks, Craig.

--larry

On Sun, Oct 9, 2022, 5:38 PM Craig Russell  wrote:

> Hi Larry,
>
> > On Oct 8, 2022, at 10:30, larry mccay  wrote:
> >
> > Good to hear, Jean-Baptiste!
> > We will send the proposal both here and to the Livy private list, I
> guess.
> > Once we come to an agreement and direction we can share with the dev@
> and
> > user@ lists.
>
> I support the effort to revive the Livy podling, but I'd advise against
> using the private list to discuss it. The incubator general list is public
> and the livy dev list is public, so these are the lists I'd suggest you use
> for further discussion.
>
> Again, good luck with the effort,
> Craig
> >
> > Thanks again!
> >
> > --larry
> >
> > On Sat, Oct 8, 2022 at 12:49 AM Jean-Baptiste Onofré 
> > wrote:
> >
> >> Hi Larry,
> >>
> >> Agree with Claude: if we can have concrete proposal (in terms of
> >> community and roadmap), it's OK. We are not in a rush, if we can have
> >> this in the commit weeks, it's fine.
> >> I would sent this on the Livy mailing list.
> >>
> >> Again, I would be more than happy to help and contribute on Livy.
> >>
> >> Regards
> >> JB
> >>
> >> On Fri, Oct 7, 2022 at 6:08 PM larry mccay  wrote:
> >>>
> >>> I was hoping that we could bring a set of contributors as:
> >>>
> >>> * mentors - 1 or 2 plus whoever wants to remain
> >>> * PPMC/Committers - 2 or 3 plus whoever wants to remain
> >>> * election of a PPMC chair if needed
> >>>
> >>> Also open it up for folks to ask to join (as well as go emeritus) as I
> >> know
> >>> there are others that have tried to contribute and have gotten know
> where
> >>> or have long since decided it wasn't worth trying anymore.
> >>>
> >>> So, my thought was almost a new Proposal and solicitation for community
> >>> bootstrap with a few seeds planted to help it grow.
> >>> I was also considering a goal of getting it back off the ground with
> some
> >>> number of releases and proof of health as a project to fast track to a
> >>> graduation discussion.
> >>> A bit early to talk about that now but that was a detail that I thought
> >>> would possibly go into such a reboot proposal.
> >>>
> >>> @Jean-Baptiste - we have compiled a list of features/improvements that
> we
> >>> would be able to bring to the table with the reboot as well.
> >>> These are improvements that have been made internally due the sense of
> >> not
> >>> being able to get them in. I lack the details around the attempts at
> this
> >>> time but we would be bringing source as well.
> >>> We could list these as part of the proposal/concrete plans.
> >>>
> >>> If you think this proposal can be done more casually, that's fine too.
> I
> >>> just would like to make it clear that we would open it up to new folks
> as
> >>> well.
> >>>
> >>> However you'd like to see it done, we can have concrete commitments to
> >> you
> >>> within a week or so more than likely.
> >>>
> >>> BTW, I did note that Ambari was sent to the attic and then pulled back
> >> out
> >>> [1] back in June into July of this year.
> >>> I would hope that we could avoid the administrative headache that seems
> >> to
> >>> have been involved in that reinstatement.
> >>>
> >>> 1. https://issues.apache.org/jira/browse/ATTIC-205
> >>>
> >>> On Fri, Oct 7, 2022 at 11:04 AM Claude Warren, Jr
> >>>  wrote:
> >>>
> >>>> Larry et.al.
> >>>>
> >>>> I think we need concrete steps. So if Larry produced a list of new
> >>>> committers could we get them added to the list and see if development
> >>>> starts again?
> >>>>
> >>>> Mentors / Champion does that work for you?
> >>>>
> >>>> Larry, can you produce such a list?
> >>>>
> >>>> Is there an objection to proceeding along these lines?
> >>>>
> >>>> Claude
> >>>>
> >>>> On Fri 7 Oct 2022, 03:07 Jean-Baptiste Onofré, 
> >> wrote:
> >>>>
> >>>>> Hi Larry,
> >>>>>
> >>>>> I tried maybe 3 tim

Re: [DISCUSS] Retire Livy podling

[larry mccay]

Exciting to see interest growing!
I think rather than try and gather all of these things now, we follow up
the proposal with a roadmap discussion.

Just as we often entertain new committers during the proposal consideration
we can do that then as well.
If you'd like to provide your names and affiliations here, I can add them
to the upcoming proposal.
If you'd like to wait to agree on the proposal first that would work too.

Again, very good to see traction building here!

--larry

On Mon, Oct 10, 2022 at 8:56 AM 严细浪  wrote:

> So glad to see there is new progress on Livy community. We have a huge
> Livy cluster on our prod environment with nearly one million Spark
> applications submitted everyday, currently we have to maintain Livy
> ourselves.
> Some common features we finished:
> Livy rest cluster, I engaged in the Livy rest cluster design but after
> that there is no progress so we implement it ourselves, although has a
> little difference with design
> Support multi Spark versions
> Implemented a metrics system for Livy
> Support customize batch/interactive session lifecycle event handler,
> default log event with log4j, very helpful for trouble shooting
> Optimize log to track which session id the log message came from, also
> very helpful for trouble shooting
> Support customize Spark config optimization rules, can be used to optimize
> config for users’ job
> A sets of command line tool which can be used to replace Spark’s
> spark-submit, pyspark, spark-sql but actually submit application in Livy
>
> We are planning to implement a JDBC state store, and allow multi Livy
> Thrift session to share one backend Spark application in next few months.
>
> We can deliver our changes if it is in Livy’s plan.
>
> Thanks,
> Jeffrey
>
>
> On 2022/10/10 09:27:46 Jean-Baptiste Onofré wrote:
> > Hi,
> >
> > If you plan to contribute on Livy, you are welcome to be part of the
> > proposal imho.
> >
> > Regards
> > JB
> >
> > On Mon, Oct 10, 2022 at 7:19 AM Brahma Reddy Battula 
> wrote:
> > >
> > > Hi Larry,
> > >
> > > Nice to hear from you that you are planning propose new features and
> make
> > > active.
> > >
> > > We do use Livy in our prod clusters, any chance to include us in your
> > > proposal so that we can also contribute.
> > >
> > >
> > >
> > > On Mon, 10 Oct 2022 at 3:54 AM, larry mccay  wrote:
> > >
> > > > Sure.
> > > > Thanks, Craig.
> > > >
> > > > --larry
> > > >
> > > > On Sun, Oct 9, 2022, 5:38 PM Craig Russell  wrote:
> > > >
> > > > > Hi Larry,
> > > > >
> > > > > > On Oct 8, 2022, at 10:30, larry mccay  wrote:
> > > > > >
> > > > > > Good to hear, Jean-Baptiste!
> > > > > > We will send the proposal both here and to the Livy private
> list, I
> > > > > guess.
> > > > > > Once we come to an agreement and direction we can share with the
> dev@
> > > > > and
> > > > > > user@ lists.
> > > > >
> > > > > I support the effort to revive the Livy podling, but I'd advise
> against
> > > > > using the private list to discuss it. The incubator general list is
> > > > public
> > > > > and the livy dev list is public, so these are the lists I'd
> suggest you
> > > > use
> > > > > for further discussion.
> > > > >
> > > > > Again, good luck with the effort,
> > > > > Craig
> > > > > >
> > > > > > Thanks again!
> > > > > >
> > > > > > --larry
> > > > > >
> > > > > > On Sat, Oct 8, 2022 at 12:49 AM Jean-Baptiste Onofré <
> jb...@nanthrax.net>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Larry,
> > > > > >>
> > > > > >> Agree with Claude: if we can have concrete proposal (in terms of
> > > > > >> community and roadmap), it's OK. We are not in a rush, if we
> can have
> > > > > >> this in the commit weeks, it's fine.
> > > > > >> I would sent this on the Livy mailing list.
> > > > > >>
> > > > > >> Again, I would be more than happy to help and contribute on
> Livy.
> > > > > >>
> > > > > >> Regards
> > > > > >> JB
> > > &

Re: [DISCUSS] Retire Livy podling

[larry mccay]

I have a simplified proposal nearly ready to send. Since there weren't any
requirements for it provided here it is just declaring the intent and new
members from this thread and my employer.

If there is anything else you'd like to see in it just let me know.

On Fri, Oct 14, 2022, 9:46 AM Jean-Baptiste Onofré  wrote:

> There's no need to reestablished the podling as it's still running ;)
>
> I think we can just update the original proposal, reshape the PPMC and
> move forward.
>
> Thoughts ?
>
> Regards
> JB
>
> On Fri, Oct 14, 2022 at 9:55 AM Brahma Reddy Battula 
> wrote:
> >
> > Hi Justin,
> >
> > Any chance to re-establish podding or add some members to existing
> > community so that it can be active ,as we can see so many people are
> > interested to contribute to Livy podling?
> >
> >
> >
> > On Thu, 13 Oct 2022 at 10:02 PM, Justin Mclean  >
> > wrote:
> >
> > > Hi,
> > >
> > > Just a note, poddlings do not go to the attic, only top level projects
> do.
> > > Most often a podling in this state will continue to live on GitHub as
> long
> > > as there is a community to support it.
> > >
> > > Kind Regards,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Proposal to Revive Apache Livy Community

[larry mccay]

Abstract

Livy is a web service that exposes a REST interface for managing long
running Apache Spark contexts in your cluster. With Livy, new applications
can be built on top of Apache Spark that require fine grained interaction
with many Spark contexts [1].

While this project has been well regarded and used in many contexts as the
defacto standard API to Spark environments, it has been incubating for over
5 years without graduation to a TLP and it has become difficult to
impossible for fixes and improvements to be contributed as the current
community seems to have moved on.

There has been discussion regarding retirement of this podling where there
seems to be some increasing interest in joining and reviving the community
[2].

The intent of this proposal is to avoid retiring a well regarded, actively
used and rather mature project by reviving the PPMC and community with new
folks that have a vested interest in the project and health of the
community.
Proposal

We propose to revive the PPMC with a set of contributors and maintainers as
mentors, PPMC members and committers.

The retirement DISCUSS thread [2] has shown a growing interest in providing
new committers and bringing improvements and fixes from organization’s
internally maintained forks back to a revived community.

General Approach to Revival:

   -

   Add new Mentors
   -

  Larry McCay, lmc...@apache.org , Cloudera
  -

  Sunil Govindan, sun...@apache.org, Cloudera
  -

  Imran Rashid - iras...@apache.org, Cloudera



   -

   Add new Committers/PPMC
   -

  Larry McCay, lmc...@apache.org, Cloudera
  -

  Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
  -

  Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
  -

  Wing Yew Poon, wyp...@cloudera.com, Cloudera
  -

  Xilang Yan, xilang@gmail.com, Shopee
  -

  Jianzhen Wu, myjianz...@gmail.com, Shopee
  -

  Nagella Jagadeewara Rao, jnage...@visa.com, Visa
  -

  Pralab Kumar, pralk...@visa.com, Visa
  -

  Prasad Shrikant, shrikant@gmail.com, Visa
  -

  Brahma Reddy Battula, bra...@apache.org, Visa



   -

   Invite existing PPMC members to opt-in or otherwise go emeritus
   -

  Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
  Retirement DISCUSS thread [2])



   -

   Invite existing Committers/PPMC members to opt-in or otherwise go
   emeritus



   -

   Establish Roadmap via follow up DISCUSS thread
   -

  Known Improvements from Forks which will need proposals and
  discussion:
  -

 Adding HA for Livy
 -

 Updating security capabilities (eg. kerberos for jdbc, fixing bugs
 in encryption)
 -

 Expanding the support for kubernetes
 -

 Responding to CVEs in dependencies (eg. log4j, thrift)
 -

 Livy rest cluster - IS THIS SAME AS HA for Livy ABOVE?
 -

 Support multi Spark versions
 -

 Implemented a metrics system for Livy
 -

 Support customize batch/interactive session lifecycle event
 handler, default log event with log4j, very helpful for
trouble shooting
 -

 Optimize log to track which session id the log message came from,
 also very helpful for trouble shooting
 -

 Support customize Spark config optimization rules, can be used to
 optimize config for users’ job
 -

 A set of command line tool which can be used to replace Spark’s
 spark-submit, pyspark, spark-sql but actually submit
application in Livy
 -

 We are planning to implement a JDBC state store, and allow multi
 Livy Thrift sessions to share one backend Spark application
in the next few
 months.
 -

  These items and others that are brought to community may need
  consolidation or multiple configurable options and will need to
be part of
  the discussion
  -

 One-pager Livy Improvement Proposals (LIP) may make sense to drive
 these discussions and convergence
 -

 Feature Branch Strategy for large changes
 -

Large features are hard to review we will need to define a
strategy
-

  Determine the Improvements to be delivered across first 3 Releases
  with Target Release Dates



   -

   Ensure CVE and Dependency management hygiene is in place


The above approach will usher the community back to an active status with a
Roadmap of 3 or more release plans and security hygiene in place.
Development Practices

The Livy project follows a review before commit philosophy. Every commit
automatically runs through the unit tests and generates coverage reports
presented as a pull request comment. Our experience with this process leads
us to believe that it helps ease new contributors into the project. They
get feedback quickly on common

Re: Proposal to Revive Apache Livy Community

[larry mccay]

+d...@livy.incubator.apache.org 


On Fri, Oct 14, 2022 at 2:38 PM larry mccay  wrote:

> Abstract
>
> Livy is a web service that exposes a REST interface for managing long
> running Apache Spark contexts in your cluster. With Livy, new applications
> can be built on top of Apache Spark that require fine grained interaction
> with many Spark contexts [1].
>
> While this project has been well regarded and used in many contexts as the
> defacto standard API to Spark environments, it has been incubating for over
> 5 years without graduation to a TLP and it has become difficult to
> impossible for fixes and improvements to be contributed as the current
> community seems to have moved on.
>
> There has been discussion regarding retirement of this podling where there
> seems to be some increasing interest in joining and reviving the community
> [2].
>
> The intent of this proposal is to avoid retiring a well regarded, actively
> used and rather mature project by reviving the PPMC and community with new
> folks that have a vested interest in the project and health of the
> community.
> Proposal
>
> We propose to revive the PPMC with a set of contributors and maintainers
> as mentors, PPMC members and committers.
>
> The retirement DISCUSS thread [2] has shown a growing interest in
> providing new committers and bringing improvements and fixes from
> organization’s internally maintained forks back to a revived community.
>
> General Approach to Revival:
>
>-
>
>Add new Mentors
>-
>
>   Larry McCay, lmc...@apache.org , Cloudera
>   -
>
>   Sunil Govindan, sun...@apache.org, Cloudera
>       -
>
>   Imran Rashid - iras...@apache.org, Cloudera
>
>
>
>-
>
>Add new Committers/PPMC
>-
>
>   Larry McCay, lmc...@apache.org, Cloudera
>   -
>
>   Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>   -
>
>   Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>   -
>
>   Wing Yew Poon, wyp...@cloudera.com, Cloudera
>   -
>
>   Xilang Yan, xilang@gmail.com, Shopee
>   -
>
>   Jianzhen Wu, myjianz...@gmail.com, Shopee
>   -
>
>   Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>   -
>
>   Pralab Kumar, pralk...@visa.com, Visa
>   -
>
>   Prasad Shrikant, shrikant@gmail.com, Visa
>   -
>
>   Brahma Reddy Battula, bra...@apache.org, Visa
>
>
>
>-
>
>Invite existing PPMC members to opt-in or otherwise go emeritus
>-
>
>   Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>   Retirement DISCUSS thread [2])
>
>
>
>-
>
>Invite existing Committers/PPMC members to opt-in or otherwise go
>emeritus
>
>
>
>-
>
>Establish Roadmap via follow up DISCUSS thread
>-
>
>   Known Improvements from Forks which will need proposals and
>   discussion:
>   -
>
>  Adding HA for Livy
>  -
>
>  Updating security capabilities (eg. kerberos for jdbc, fixing
>  bugs in encryption)
>  -
>
>  Expanding the support for kubernetes
>  -
>
>  Responding to CVEs in dependencies (eg. log4j, thrift)
>  -
>
>  Livy rest cluster - IS THIS SAME AS HA for Livy ABOVE?
>  -
>
>  Support multi Spark versions
>  -
>
>  Implemented a metrics system for Livy
>  -
>
>  Support customize batch/interactive session lifecycle event
>  handler, default log event with log4j, very helpful for trouble 
> shooting
>  -
>
>  Optimize log to track which session id the log message came
>  from, also very helpful for trouble shooting
>  -
>
>  Support customize Spark config optimization rules, can be used
>  to optimize config for users’ job
>  -
>
>  A set of command line tool which can be used to replace Spark’s
>  spark-submit, pyspark, spark-sql but actually submit application in 
> Livy
>  -
>
>  We are planning to implement a JDBC state store, and allow multi
>  Livy Thrift sessions to share one backend Spark application in the 
> next few
>  months.
>  -
>
>   These items and others that are brought to community may need
>   consolidation or multiple configurable options and will need to be part 
> of
>   the discussion
>   -
>
>  One-pager Livy Improvement Proposals (LIP) may make sense to
>  drive these discussions and convergenc

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Hi Justin -

Thanks for the feedback.
I can buy all of that other than the dev practices suggestion.
The project originally used RTC as per the original proposal and being a
more mature podling, I don't think we need to move that fast.
With new committers, it will also be good to ensure others are familiar
with the code going in.

For pulling in large features from forks, we can have feature branches that
are CTR and define merge criteria.

I believe that I was an IPMC member at some point and have been a mentor on
other podlings (still am???)  but maybe somehow that went away?
We would certainly welcome any other mentors as well.
JB is currently listed as a Mentor on the site - I added him as a committer.
@JB do you intend to be a Committer or Mentor going forward?

The proposal was sent to the d...@livy.incubator.org list as well in order
to get their thoughts.
There have also been public threads about retiring it where this has been
discussed as you know.
Do you have further suggestions for how to reach out and/or how long to
wait?

Thanks again!

--larry

On Sat, Oct 15, 2022 at 12:24 AM Justin Mclean 
wrote:

> Hi,
>
> A couple of things stand out here to me:
> - Your mentors need to be IPMC members.
> - It would be helpful to include mentors who are not all affiliated with
> one company
> - It would be helpful to know what the existing PMC and the wider
> community think about this reboot. It may be there’s no one left, and no
> objections from those who are still about, but we should give them some
> time to speak up.
> - RTC can slow development and, in some cases, limit contributions,
> particularly when you have a less active project. Have you considered CTR?
> - While asking existing PPMC members to opt-in is probably fine, I think
> you should leave existing committers as they are and not remove anyone
> unless they asked to be removed.
> - Existing PPMC members who don’t explicitly opt-out should be able to
> rejoin the PPMC later if they ask.
>
> Kind Regards,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Awesome - thanks, Justin!

On Sat, Oct 15, 2022, 11:51 AM Justin Mclean 
wrote:

> Hi,
>
> The project is free to choose RTC or RTC. I just wanted to check if it was
> considered. I’ve seen in some cases, CTR tends to put a lot of work onto
> existing committers and cause frustration when contributions are not
> reviewed in a timely way.
>
> Another thing to consider is what someone would have to do to become a
> committer. A RTC with a low committer bar would probably work better than a
> RTC with a high committer bar.
>
> You are not an IPMC member but can ask to become one as you are an ASF
> member.
>
> I started a roll call on the Livy private list that may get the attention
> of any existing PMC members.
>
> Kind Regards,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Revised Proposal with opt-out for committers and JB as a mentor which adds
more diversity to the company based mentors.
These were items suggested on this thread. Thanks again, Justin!
Abstract

Livy is a web service that exposes a REST interface for managing long
running Apache Spark contexts in your cluster. With Livy, new applications
can be built on top of Apache Spark that require fine grained interaction
with many Spark contexts [1].

While this project has been well regarded and used in many contexts as the
defacto standard API to Spark environments, it has been incubating for over
5 years without graduation to a TLP and it has become difficult to
impossible for fixes and improvements to be contributed as the current
community seems to have moved on.

There has been discussion regarding retirement of this podling where there
seems to be some increasing interest in joining and reviving the community
[2].

The intent of this proposal is to avoid retiring a well regarded, actively
used and rather mature project by reviving the PPMC and community with new
folks that have a vested interest in the project and health of the
community.
Proposal

We propose to revive the PPMC with a set of contributors and maintainers as
mentors, PPMC members and committers.

The retirement DISCUSS thread [2] has shown a growing interest in providing
new committers and bringing improvements and fixes from organization’s
internally maintained forks back to a revived community.

General Approach to Revival:

   -

   Add new Mentors
   -

  Larry McCay, lmc...@apache.org , Cloudera
  -

  Sunil Govindan, sun...@apache.org, Cloudera
  -

  Imran Rashid - iras...@apache.org, Cloudera
  -

  Jean-Baptiste Onofré, jbono...@apache.org, Talend



   -

   Add new Committers/PPMC
   -

  Larry McCay, lmc...@apache.org, Cloudera
  -

  Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
  -

  Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
  -

  Wing Yew Poon, wyp...@cloudera.com, Cloudera
  -

  Xilang Yan, xilang@gmail.com, Shopee
  -

  Jianzhen Wu, myjianz...@gmail.com, Shopee
  -

  Nagella Jagadeewara Rao, jnage...@visa.com, Visa
  -

  Pralab Kumar, pralk...@visa.com, Visa
  -

  Prasad Shrikant, shrikant@gmail.com, Visa
  -

  Brahma Reddy Battula, bra...@apache.org, Visa



   -

   Invite existing PPMC members to opt-in or otherwise go emeritus
   -

  Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
  Retirement DISCUSS thread [2])



   -

   Invite existing Committers to opt-out or otherwise continue



   -

   Establish Roadmap via follow up DISCUSS thread
   -

  Known Improvements from Forks which will need proposals and
  discussion:
  -

 Adding HA for Livy
 -

 Updating security capabilities (eg. kerberos for jdbc, fixing bugs
 in encryption)
 -

 Expanding the support for kubernetes
 -

 Responding to CVEs in dependencies (eg. log4j, thrift)
 -

 Livy rest cluster - IS THIS SAME AS HA for Livy ABOVE?
 -

 Support multi Spark versions
 -

 Implemented a metrics system for Livy
 -

 Support customize batch/interactive session lifecycle event
 handler, default log event with log4j, very helpful for troubleshooting
 -

 Optimize log to track which session id the log message came from,
 also very helpful for troubleshooting
 -

 Support customize Spark config optimization rules, can be used to
 optimize config for users’ job
 -

 A set of command line tool which can be used to replace Spark’s
 spark-submit, pyspark, spark-sql but actually submit
application in Livy
 -

 We are planning to implement a JDBC state store, and allow multi
 Livy Thrift sessions to share one backend Spark application
in the next few
 months.
 -

  These items and others that are brought to community may need
  consolidation or multiple configurable options and will need to
be part of
  the discussion
  -

 One-pager Livy Improvement Proposals (LIP) may make sense to drive
 these discussions and convergence
 -

 Feature Branch Strategy for large changes
 -

Large features are hard to review we will need to define a
strategy
-

CTR for feature branches and a we will define a walkthrough of
implementation details to aid in review for merge
-

  Determine the Improvements to be delivered across first 3 Releases
  with Target Release Dates



   -

   Ensure CVE and Dependency management hygiene is in place


The above approach will usher the community back to an active status with a
Roadmap of 3 or more release plans

Re: Proposal to Revive Apache Livy Community

[larry mccay]

I will ask in a separate thread, @Justin Mclean  -
thanks.
Adding JB adds another company and we are certainly open to anyone else
that would like to join as a mentor.
At the end of the day, the mentors are for instilling the Apache Way
knowledge and steering toward graduation.
I feel that this diversity, while nice to have, is less important than that
of the PPMC and committers for the long term health of the community.

We need to push this podling to graduation as quickly as possible since it
is rather mature and needs to get to the next level.

Again, any potential Mentors that would like to join are more than welcome.

On Tue, Oct 18, 2022 at 12:38 PM Justin Mclean 
wrote:

> Hi,
>
> I’m sorry, but Imran Rashid can’t be a mentor for the project as they are
> not an IPMC member. Currently, both Sunil and Larry (as they are ASF
> members) need to ask to join the IPMC and NOTICE sent to the ASF board. I
> would also prefer that mentors come from different companies.
>
> There is also no concept as an emeritus PPMC member at the ASF.
>
> Kind Regards,
> Justin
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Request to have me added as an IPMC Member

[larry mccay]

Hi -

It has come to my attention that I don't seem to be an IPMC member
(anymore?) and I would like to officially Mentor the reboot of Livy.

thanks!

--larry

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Sorry, I missed commenting on this:

"There is also no concept as an emeritus PPMC member at the ASF."

I assume that we can remove PPMC members that do not opt-in explicitly at
this point.
They will have every opportunity to rejoin.

On Tue, Oct 18, 2022 at 12:48 PM larry mccay  wrote:

> I will ask in a separate thread, @Justin Mclean  -
> thanks.
> Adding JB adds another company and we are certainly open to anyone else
> that would like to join as a mentor.
> At the end of the day, the mentors are for instilling the Apache Way
> knowledge and steering toward graduation.
> I feel that this diversity, while nice to have, is less important than
> that of the PPMC and committers for the long term health of the community.
>
> We need to push this podling to graduation as quickly as possible since it
> is rather mature and needs to get to the next level.
>
> Again, any potential Mentors that would like to join are more than welcome.
>
> On Tue, Oct 18, 2022 at 12:38 PM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> I’m sorry, but Imran Rashid can’t be a mentor for the project as they are
>> not an IPMC member. Currently, both Sunil and Larry (as they are ASF
>> members) need to ask to join the IPMC and NOTICE sent to the ASF board. I
>> would also prefer that mentors come from different companies.
>>
>> There is also no concept as an emeritus PPMC member at the ASF.
>>
>> Kind Regards,
>> Justin
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Hi Madhawa -

That's awesome!
Are you already a member of IPMC?
If not, are you an ASF member?
If you are an ASF member you can request that you be added as an IPMC
member.

Can you provide your company affiliation for the proposal and preferred
email?

thanks!

--larry

On Tue, Oct 18, 2022 at 2:18 PM Madhawa Gunasekara 
wrote:

> Hi Larry,
>
> I'm interested in working with Livy and would like to join as a Mentor.
>
> Thanks,
> Madhawa
>
>
> On Tue, Oct 18, 2022 at 6:57 PM larry mccay  wrote:
>
> > Sorry, I missed commenting on this:
> >
> > "There is also no concept as an emeritus PPMC member at the ASF."
> >
> > I assume that we can remove PPMC members that do not opt-in explicitly at
> > this point.
> > They will have every opportunity to rejoin.
> >
> > On Tue, Oct 18, 2022 at 12:48 PM larry mccay  wrote:
> >
> > > I will ask in a separate thread, @Justin Mclean 
> -
> > > thanks.
> > > Adding JB adds another company and we are certainly open to anyone else
> > > that would like to join as a mentor.
> > > At the end of the day, the mentors are for instilling the Apache Way
> > > knowledge and steering toward graduation.
> > > I feel that this diversity, while nice to have, is less important than
> > > that of the PPMC and committers for the long term health of the
> > community.
> > >
> > > We need to push this podling to graduation as quickly as possible since
> > it
> > > is rather mature and needs to get to the next level.
> > >
> > > Again, any potential Mentors that would like to join are more than
> > welcome.
> > >
> > > On Tue, Oct 18, 2022 at 12:38 PM Justin Mclean <
> jus...@classsoftware.com
> > >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I’m sorry, but Imran Rashid can’t be a mentor for the project as they
> > are
> > >> not an IPMC member. Currently, both Sunil and Larry (as they are ASF
> > >> members) need to ask to join the IPMC and NOTICE sent to the ASF
> board.
> > I
> > >> would also prefer that mentors come from different companies.
> > >>
> > >> There is also no concept as an emeritus PPMC member at the ASF.
> > >>
> > >> Kind Regards,
> > >> Justin
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> >
>

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Very good, here is the latest revision with updated Mentors.
Sunil and I have been added to the IPMC as well.
Welcome Madhawa and thanks for stepping up as a Mentor for Livy!

Abstract

Livy is a web service that exposes a REST interface for managing long
running Apache Spark contexts in your cluster. With Livy, new applications
can be built on top of Apache Spark that require fine grained interaction
with many Spark contexts [1].

While this project has been well regarded and used in many contexts as the
defacto standard API to Spark environments, it has been incubating for over
5 years without graduation to a TLP and it has become difficult to
impossible for fixes and improvements to be contributed as the current
community seems to have moved on.

There has been discussion regarding retirement of this podling where there
seems to be some increasing interest in joining and reviving the community
[2].

The intent of this proposal is to avoid retiring a well regarded, actively
used and rather mature project by reviving the PPMC and community with new
folks that have a vested interest in the project and health of the
community.
Proposal

We propose to revive the PPMC with a set of contributors and maintainers as
mentors, PPMC members and committers.

The retirement DISCUSS thread [2] has shown a growing interest in providing
new committers and bringing improvements and fixes from organization’s
internally maintained forks back to a revived community.

General Approach to Revival:

   -

   Add new Mentors
   -

  Larry McCay, lmc...@apache.org , Cloudera
  -

  Sunil Govindan, sun...@apache.org, Cloudera
  -

  Jean-Baptiste Onofré, jbono...@apache.org, Talend
  -

  Madhawa Gunasekara, madhaw...@gmail.com, Independent



   -

   Add new Committers/PPMC
   -

  Larry McCay, lmc...@apache.org, Cloudera
  -

  Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
  -

  Imran Rashid - iras...@apache.org, Cloudera
  -

  Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
  -

  Wing Yew Poon, wyp...@cloudera.com, Cloudera
  -

  Xilang Yan, xilang@gmail.com, Shopee
  -

  Jianzhen Wu, myjianz...@gmail.com, Shopee
  -

  Nagella Jagadeewara Rao, jnage...@visa.com, Visa
  -

  Pralab Kumar, pralk...@visa.com, Visa
  -

  Prasad Shrikant, shrikant@gmail.com, Visa
  -

  Brahma Reddy Battula, bra...@apache.org, Visa



   -

   Invite existing PPMC members to opt-in or otherwise go emeritus
   -

  Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
  Retirement DISCUSS thread [2])



   -

   Invite existing Committers to opt-out or otherwise continue



   -

   Establish Roadmap via follow up DISCUSS thread
   -

  Known Improvements from Forks which will need proposals and
  discussion:
  -

 Adding HA for Livy
 -

 Updating security capabilities (eg. kerberos for jdbc, fixing bugs
 in encryption)
 -

 Expanding the support for kubernetes
 -

 Responding to CVEs in dependencies (eg. log4j, thrift)
 -

 Livy rest cluster - IS THIS SAME AS HA for Livy ABOVE?
 -

 Support multi Spark versions
 -

 Implemented a metrics system for Livy
 -

 Support customize batch/interactive session lifecycle event
 handler, default log event with log4j, very helpful for troubleshooting
 -

 Optimize log to track which session id the log message came from,
 also very helpful for troubleshooting
 -

 Support customize Spark config optimization rules, can be used to
 optimize config for users’ job
 -

 A set of command line tool which can be used to replace Spark’s
 spark-submit, pyspark, spark-sql but actually submit
application in Livy
 -

 We are planning to implement a JDBC state store, and allow multi
 Livy Thrift sessions to share one backend Spark application
in the next few
 months.
 -

  These items and others that are brought to community may need
  consolidation or multiple configurable options and will need to
be part of
  the discussion
  -

 One-pager Livy Improvement Proposals (LIP) may make sense to drive
 these discussions and convergence
 -

 Feature Branch Strategy for large changes
 -

Large features are hard to review we will need to define a
strategy
-

  Determine the Improvements to be delivered across first 3 Releases
  with Target Release Dates



   -

   Ensure CVE and Dependency management hygiene is in place


The above approach will usher the community back to an active status with a
Roadmap of 3 or more release plans and security hygiene in place.
Development Practices

The Livy project follows a review

Re: [DISCUSS] What to do with long incubating projects?

[larry mccay]

I've been wondering about this as well.
It seems that we can have a rather mature project still incubating after a
number of years.
We can have active consumers relying on it but the momentum of the original
project and maintainers waned.
Multiple external forks have been made with the inability to get
contributions accepted.

In the example of Livy, action was triggered by the threat of retirement.
We certainly need an earlier flag than this.

Perhaps a specific trigger in the board report reminder email for podlings
that are getting long in the tooth that they should include various metrics:

* Graduation Status
* Community issues for both users and maintainers
   - what are the barriers of entry for each - complexity in maintenance,
language use, continued relevance, etc
* Are there known forks with extensions that would have rather contributed
back?

Based on this, some intervention with new Mentor/s to assess and guide can
be advised?

Unfortunately, this would require some oversight from the IPMC to identify
these podlings before they get too far down the abandoned road.
Maybe this is a simple report to see how long they have been incubating
though?

On Tue, Oct 18, 2022 at 3:55 PM Josh Fischer  wrote:

> > One might even do this review (gasp!) over Zoom, so that people can
> ask questions and have them answered in real time
>
> + 1 Julian.  I appreciate this.
>
> I'm on one of these projects (Heron) that has been in the incubator for far
> too long.  I think where Heron fell short in its journey was the steep
> learning curve it takes to build, maintain, and use Heron which caused our
> community to dwindle over time.  So in Heron's case, I don't feel it's
> anything that happened in the incubator. It's mainly the complexity of
> maintenance.
>
>
>
>
> On Tue, Oct 18, 2022 at 2:35 PM Julian Hyde  wrote:
>
> > One idea is to schedule a review after the project has been in the
> > incubator longer than the median time (say after 2 years). Deep-dive
> > into what is going right and wrong, identify things that can be fixed,
> > and set targets. And schedule another review a year later. Or schedule
> > a vote to retire.
> >
> > One might even do this review (gasp!) over Zoom, so that people can
> > ask questions and have them answered in real time.
> >
> > It sounds shockingly invasive, considering we at Apache tend to do
> > everything asynchronously. But it's better than the alternative, which
> > is a slow death as mentors and initial committers drift away.
> >
> > Julian
> >
> >
> >
> >
> > On Tue, Oct 18, 2022 at 12:27 PM Justin Mclean  >
> > wrote:
> > >
> > > Hi,
> > >
> > > Looking at the longest incubating projects, one has graduated and needs
> > some cleanup, one had a reboot, one is discussing a reboot, and several
> > have roll calls in progress or are discussing retirement. However there
> are
> > two or three other projects that either should retire or graduate and
> have
> > been incubating for far too long.
> > >
> > > But taking a step back what can we do to make projects life though the
> > incubator shorter? Would having more resources help? (If so what
> > resources?) What else might we be able to do - offer training for
> instance?
> > >
> > > Kind Regards,
> > > Justin
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Request to have me added as an IPMC Member

[larry mccay]

Thanks!

On Tue, Oct 18, 2022, 9:54 PM tison  wrote:

> Good to know :)
>
> Best,
> tison.
>
>
> Justin Mclean  于2022年10月19日周三 09:46写道：
>
> > There is no need for the 3 day wait anymore
> >
> > On Tue, 18 Oct 2022, 6:14 pm tison,  wrote:
> >
> > > I noticed that Justin has sent a NOTICE:
> > > https://lists.apache.org/thread/8ftfqgmq1tztdb6fwvmg9obckp7nbpbo
> > >
> > > Generally, you will be added to the IPMC in three days.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > larry mccay  于2022年10月19日周三 00:51写道：
> > >
> > > > Hi -
> > > >
> > > > It has come to my attention that I don't seem to be an IPMC member
> > > > (anymore?) and I would like to officially Mentor the reboot of Livy.
> > > >
> > > > thanks!
> > > >
> > > > --larry
> > > >
> > >
> >
>

Re: Proposal to Revive Apache Livy Community

[larry mccay]

@Justin Mclean  - any insights on next steps here?


On Tue, Oct 18, 2022 at 5:44 PM larry mccay  wrote:

> Very good, here is the latest revision with updated Mentors.
> Sunil and I have been added to the IPMC as well.
> Welcome Madhawa and thanks for stepping up as a Mentor for Livy!
>
> Abstract
>
> Livy is a web service that exposes a REST interface for managing long
> running Apache Spark contexts in your cluster. With Livy, new applications
> can be built on top of Apache Spark that require fine grained interaction
> with many Spark contexts [1].
>
> While this project has been well regarded and used in many contexts as the
> defacto standard API to Spark environments, it has been incubating for over
> 5 years without graduation to a TLP and it has become difficult to
> impossible for fixes and improvements to be contributed as the current
> community seems to have moved on.
>
> There has been discussion regarding retirement of this podling where there
> seems to be some increasing interest in joining and reviving the community
> [2].
>
> The intent of this proposal is to avoid retiring a well regarded, actively
> used and rather mature project by reviving the PPMC and community with new
> folks that have a vested interest in the project and health of the
> community.
> Proposal
>
> We propose to revive the PPMC with a set of contributors and maintainers
> as mentors, PPMC members and committers.
>
> The retirement DISCUSS thread [2] has shown a growing interest in
> providing new committers and bringing improvements and fixes from
> organization’s internally maintained forks back to a revived community.
>
> General Approach to Revival:
>
>-
>
>Add new Mentors
>-
>
>   Larry McCay, lmc...@apache.org , Cloudera
>   -
>
>   Sunil Govindan, sun...@apache.org, Cloudera
>   -
>
>   Jean-Baptiste Onofré, jbono...@apache.org, Talend
>   -
>
>   Madhawa Gunasekara, madhaw...@gmail.com, Independent
>
>
>
>-
>
>Add new Committers/PPMC
>-
>
>   Larry McCay, lmc...@apache.org, Cloudera
>   -
>
>   Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>   -
>
>   Imran Rashid - iras...@apache.org, Cloudera
>   -
>
>   Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>   -
>
>   Wing Yew Poon, wyp...@cloudera.com, Cloudera
>   -
>
>   Xilang Yan, xilang@gmail.com, Shopee
>   -
>
>   Jianzhen Wu, myjianz...@gmail.com, Shopee
>   -
>
>   Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>   -
>
>   Pralab Kumar, pralk...@visa.com, Visa
>   -
>
>   Prasad Shrikant, shrikant@gmail.com, Visa
>   -
>
>   Brahma Reddy Battula, bra...@apache.org, Visa
>
>
>
>-
>
>Invite existing PPMC members to opt-in or otherwise go emeritus
>-
>
>   Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>   Retirement DISCUSS thread [2])
>
>
>
>-
>
>Invite existing Committers to opt-out or otherwise continue
>
>
>
>-
>
>Establish Roadmap via follow up DISCUSS thread
>-
>
>   Known Improvements from Forks which will need proposals and
>   discussion:
>   -
>
>  Adding HA for Livy
>  -
>
>  Updating security capabilities (eg. kerberos for jdbc, fixing
>  bugs in encryption)
>  -
>
>  Expanding the support for kubernetes
>  -
>
>  Responding to CVEs in dependencies (eg. log4j, thrift)
>  -
>
>  Livy rest cluster - IS THIS SAME AS HA for Livy ABOVE?
>  -
>
>  Support multi Spark versions
>  -
>
>  Implemented a metrics system for Livy
>  -
>
>  Support customize batch/interactive session lifecycle event
>  handler, default log event with log4j, very helpful for 
> troubleshooting
>  -
>
>  Optimize log to track which session id the log message came
>  from, also very helpful for troubleshooting
>  -
>
>  Support customize Spark config optimization rules, can be used
>  to optimize config for users’ job
>  -
>
>  A set of command line tool which can be used to replace Spark’s
>  spark-submit, pyspark, spark-sql but actually submit application in 
> Livy
>  -
>
>  We are planning to implement a JDBC state store, and allow multi
>  Livy Thrift sessions to share one backend Spark application in the 
> next few
>  months

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Gentle reminder that we need to determine next steps here.
We have an updated proposal on this thread.
Do we need a VOTE or can we move forward directly to adjusting the members,
etc?

Thanks!

--larry

On Thu, Oct 20, 2022 at 3:26 PM larry mccay  wrote:

> @Justin Mclean  - any insights on next steps here?
>
>
> On Tue, Oct 18, 2022 at 5:44 PM larry mccay  wrote:
>
>> Very good, here is the latest revision with updated Mentors.
>> Sunil and I have been added to the IPMC as well.
>> Welcome Madhawa and thanks for stepping up as a Mentor for Livy!
>>
>> Abstract
>>
>> Livy is a web service that exposes a REST interface for managing long
>> running Apache Spark contexts in your cluster. With Livy, new applications
>> can be built on top of Apache Spark that require fine grained interaction
>> with many Spark contexts [1].
>>
>> While this project has been well regarded and used in many contexts as
>> the defacto standard API to Spark environments, it has been incubating for
>> over 5 years without graduation to a TLP and it has become difficult to
>> impossible for fixes and improvements to be contributed as the current
>> community seems to have moved on.
>>
>> There has been discussion regarding retirement of this podling where
>> there seems to be some increasing interest in joining and reviving the
>> community [2].
>>
>> The intent of this proposal is to avoid retiring a well regarded,
>> actively used and rather mature project by reviving the PPMC and community
>> with new folks that have a vested interest in the project and health of the
>> community.
>> Proposal
>>
>> We propose to revive the PPMC with a set of contributors and maintainers
>> as mentors, PPMC members and committers.
>>
>> The retirement DISCUSS thread [2] has shown a growing interest in
>> providing new committers and bringing improvements and fixes from
>> organization’s internally maintained forks back to a revived community.
>>
>> General Approach to Revival:
>>
>>-
>>
>>Add new Mentors
>>-
>>
>>   Larry McCay, lmc...@apache.org , Cloudera
>>   -
>>
>>   Sunil Govindan, sun...@apache.org, Cloudera
>>   -
>>
>>   Jean-Baptiste Onofré, jbono...@apache.org, Talend
>>   -
>>
>>   Madhawa Gunasekara, madhaw...@gmail.com, Independent
>>
>>
>>
>>-
>>
>>Add new Committers/PPMC
>>-
>>
>>   Larry McCay, lmc...@apache.org, Cloudera
>>   -
>>
>>   Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>>   -
>>
>>   Imran Rashid - iras...@apache.org, Cloudera
>>   -
>>
>>   Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>>   -
>>
>>   Wing Yew Poon, wyp...@cloudera.com, Cloudera
>>   -
>>
>>   Xilang Yan, xilang@gmail.com, Shopee
>>   -
>>
>>   Jianzhen Wu, myjianz...@gmail.com, Shopee
>>   -
>>
>>   Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>>   -
>>
>>   Pralab Kumar, pralk...@visa.com, Visa
>>   -
>>
>>   Prasad Shrikant, shrikant@gmail.com, Visa
>>   -
>>
>>   Brahma Reddy Battula, bra...@apache.org, Visa
>>
>>
>>
>>-
>>
>>Invite existing PPMC members to opt-in or otherwise go emeritus
>>-
>>
>>   Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>>   Retirement DISCUSS thread [2])
>>
>>
>>
>>-
>>
>>Invite existing Committers to opt-out or otherwise continue
>>
>>
>>
>>-
>>
>>Establish Roadmap via follow up DISCUSS thread
>>-
>>
>>   Known Improvements from Forks which will need proposals and
>>   discussion:
>>   -
>>
>>  Adding HA for Livy
>>  -
>>
>>  Updating security capabilities (eg. kerberos for jdbc, fixing
>>  bugs in encryption)
>>  -
>>
>>  Expanding the support for kubernetes
>>  -
>>
>>  Responding to CVEs in dependencies (eg. log4j, thrift)
>>  -
>>
>>  Livy rest cluster - IS THIS SAME AS HA for Livy ABOVE?
>>  -
>>
>>  Support multi Spark versions
>>  -
>>
>>  Implemented a metrics system for Livy
>>  -
>>
>>  Support customize batch/in

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Oh, very good, Alex!
Be sure to let us know if you want to remain on the project in any capacity.


On Mon, Oct 24, 2022 at 3:18 PM Alex Bozarth  wrote:

> As the only Livy PPMC still responding to the Mentors on the private list,
> I have updated the Livy Podling report for November with the status of the
> project and a request to the IPMC to review this proposal since there are
> not enough active Livy PPMC members to reach a quorum to pass the proposal.
>
> As a current Livy PPMC I strongly support this proposal for revitalization
> as I do not have enough bandwidth to dedicate to Livy.
>
>
> Alex Bozarth
> Jupyter Architect, IBM CODAIT
> GitHub: ajbozarth
>
> On 10/24/22, 1:41 PM, "larry mccay"  wrote:
>
> Gentle reminder that we need to determine next steps here.
> We have an updated proposal on this thread.
> Do we need a VOTE or can we move forward directly to adjusting the
> members,
> etc?
>
> Thanks!
>
> --larry
>
> On Thu, Oct 20, 2022 at 3:26 PM larry mccay  wrote:
>
> > @Justin Mclean  - any insights on next steps
> here?
> >
> >
> > On Tue, Oct 18, 2022 at 5:44 PM larry mccay 
> wrote:
> >
> >> Very good, here is the latest revision with updated Mentors.
> >> Sunil and I have been added to the IPMC as well.
> >> Welcome Madhawa and thanks for stepping up as a Mentor for Livy!
> >>
> >> Abstract
> >>
> >> Livy is a web service that exposes a REST interface for managing
> long
> >> running Apache Spark contexts in your cluster. With Livy, new
> applications
> >> can be built on top of Apache Spark that require fine grained
> interaction
> >> with many Spark contexts [1].
> >>
> >> While this project has been well regarded and used in many contexts
> as
> >> the defacto standard API to Spark environments, it has been
> incubating for
> >> over 5 years without graduation to a TLP and it has become
> difficult to
> >> impossible for fixes and improvements to be contributed as the
> current
> >> community seems to have moved on.
> >>
> >> There has been discussion regarding retirement of this podling where
> >> there seems to be some increasing interest in joining and reviving
> the
> >> community [2].
> >>
> >> The intent of this proposal is to avoid retiring a well regarded,
> >> actively used and rather mature project by reviving the PPMC and
> community
> >> with new folks that have a vested interest in the project and
> health of the
> >> community.
> >> Proposal
> >>
> >> We propose to revive the PPMC with a set of contributors and
> maintainers
> >> as mentors, PPMC members and committers.
> >>
> >> The retirement DISCUSS thread [2] has shown a growing interest in
> >> providing new committers and bringing improvements and fixes from
> >> organization’s internally maintained forks back to a revived
> community.
> >>
> >> General Approach to Revival:
> >>
> >>-
> >>
> >>Add new Mentors
> >>-
> >>
> >>   Larry McCay, lmc...@apache.org , Cloudera
> >>   -
> >>
> >>   Sunil Govindan, sun...@apache.org, Cloudera
> >>   -
> >>
> >>   Jean-Baptiste Onofré, jbono...@apache.org, Talend
> >>   -
> >>
> >>   Madhawa Gunasekara, madhaw...@gmail.com, Independent
> >>
> >>
> >>
> >>-
> >>
> >>Add new Committers/PPMC
> >>-
> >>
> >>   Larry McCay, lmc...@apache.org, Cloudera
> >>   -
> >>
> >>   Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
> >>   -
> >>
> >>   Imran Rashid - iras...@apache.org, Cloudera
> >>   -
> >>
> >>   Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
> >>   -
> >>
> >>   Wing Yew Poon, wyp...@cloudera.com, Cloudera
> >>   -
> >>
> >>   Xilang Yan, xilang@gmail.com, Shopee
> >>   -
> >>
> >>   Jianzhen Wu, myjianz...@gmail.com, Shopee
> >>   -
&g

Re: Proposal to Revive Apache Livy Community

[larry mccay]

Great, I'll move that forward.
That sounds like a NOTICE thread?


On Mon, Oct 24, 2022 at 4:16 PM Justin Mclean 
wrote:

> Hi,
>
> Usually, the PPMC would need to vote on adding new PPMC members, but it
> seems Livy no longer has 3 active PPMC members. The chair of the project
> can add PMC members. But PPMC members only have standing in the Incubator,
> so I would guess (as it isn’t documented) that any IPMC could add those new
> PPMC members.
>
> A VOTE is probably not required but is helpful to confirm consensus. I
> would write an email to the general list containing who will be added to
> the Livy PPMC. iI there are no objections by any IPMC members after 72
> hours add them.
>
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [EXTERNAL] Re: Proposal to Revive Apache Livy Community

[larry mccay]

Hi Renat -

More active contributors/committers would be great!
Let's get the names before I craft the NOTICE to add new members email
later today.

If that isn't realistic then we can always add more after the fact as well.
That's what is great about re/building the community in the incubator!

thanks!

--larry

On Mon, Oct 24, 2022 at 10:30 PM Renat Bekbolatov
 wrote:

> I welcome this development - honestly, possibly long overdue.
> Would it be possible to propose additional committers for a wider
> representation?
>
>
> Thank you,
> Renat
>
> -Original Message-
> From: larry mccay 
> Sent: Monday, October 24, 2022 4:41 PM
> To: d...@livy.apache.org
> Subject: [EXTERNAL] Re: Proposal to Revive Apache Livy Community
>
> Again, I have no objections to this and will be happy to include you.
> Thanks for calling out!
>
> On Mon, Oct 24, 2022 at 5:38 PM Marco Gaido  wrote:
>
> > Hi all,
> >
> > I am also busy with different projects at the moment, as such I am
> > more than happy if ai can help somehow, e.g. reviewing code in parts
> > that I know, but I cannot allocate much bandwidth to it.
> >
> > Thanks,
> > Marco
> >
> > Il lun 24 ott 2022, 22:07 larry mccay  ha scritto:
> >
> > > Personally, I would welcome it.
> > > Any notes of guidance and support as we ramp up the team and make
> > > the
> > first
> > > few releases would be invaluable.
> > >
> > >
> > > On Mon, Oct 24, 2022 at 3:49 PM Alex Bozarth 
> > wrote:
> > >
> > > > I would love to stay on as a PPMC, but if my lack of availability
> > > concerns
> > > > the new PPMC then I'm willing to be emeritus.
> > > >
> > > >
> > > > Alex Bozarth
> > > > Jupyter Architect, IBM CODAIT
> > > > GitHub: ajbozarth
> > > >
> > > > On 10/24/22, 2:46 PM, "larry mccay"  wrote:
> > > >
> > > > Oh, very good, Alex!
> > > > Be sure to let us know if you want to remain on the project in
> > > > any capacity.
> > > >
> > > >
> > > > On Mon, Oct 24, 2022 at 3:18 PM Alex Bozarth
> > > > 
> > > > wrote:
> > > >
> > > > > As the only Livy PPMC still responding to the Mentors on the
> > > private
> > > > list,
> > > > > I have updated the Livy Podling report for November with the
> > status
> > > > of the
> > > > > project and a request to the IPMC to review this proposal
> > > > since there are
> > > > > not enough active Livy PPMC members to reach a quorum to
> > > > pass the proposal.
> > > > >
> > > > > As a current Livy PPMC I strongly support this proposal for
> > > > revitalization
> > > > > as I do not have enough bandwidth to dedicate to Livy.
> > > > >
> > > > >
> > > > > Alex Bozarth
> > > > > Jupyter Architect, IBM CODAIT
> > > > > GitHub: ajbozarth
> > > > >
> > > >     > On 10/24/22, 1:41 PM, "larry mccay"  wrote:
> > > > >
> > > > > Gentle reminder that we need to determine next steps here.
> > > > > We have an updated proposal on this thread.
> > > > > Do we need a VOTE or can we move forward directly to
> > adjusting
> > > > the
> > > > > members,
> > > > > etc?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --larry
> > > > >
> > > > > On Thu, Oct 20, 2022 at 3:26 PM larry mccay <
> > lmc...@apache.org
> > > >
> > > > wrote:
> > > > >
> > > > > > @Justin Mclean  - any insights on
> > next
> > > > steps
> > > > > here?
> > > > > >
> > > > > >
> > > > > > On Tue, Oct 18, 2022 at 5:44 PM larry mccay <
> > > lmc...@apache.org
> > > > >
> > > > > wrote:
> > > > > >
> > > > > >> Very good, here is the latest revision with updated
> > Mentors.
> > > > > >> Sunil and I have been added to the IPMC as well.
> > > > > >&g

[NOTICE] Adding new PPMC and Committers to Apache Livy

[larry mccay]

Hi Incubator -

In an effort to revive the Livy podling [1], it is being proposed to adjust
the existing Livy PPMC by adding new members that plan to move the project
forward, remove members that have not opted back in and add a number of new
Mentors to the project.


The following lists of new contributors and roles represent those that have
explicitly expressed interest in doing so either by the original revival
Proposal [3] or the resulting email thread. It was suggested on the revival
proposal thread [3] that we provide the proposed list of changes to the
community here as notice and that if after 72 hrs there are no objections
an IPMC member would be able to make these changes.

Mentors

   -

   Larry McCay, lmc...@apache.org , Cloudera
   -

   Sunil Govindan, sun...@apache.org, Cloudera
   -

   Jean-Baptiste Onofré, jbono...@apache.org, Talend
   -

   Madhawa Gunasekara, madhaw...@gmail.com, Independent


PPMC

The following are new PPMC members and Committers to be added:

   -

   Larry McCay, lmc...@apache.org, Cloudera
   -

   Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
   -

   Imran Rashid - iras...@apache.org, Cloudera
   -

   Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
   -

   Wing Yew Poon, wyp...@cloudera.com, Cloudera
   -

   Xilang Yan, xilang@gmail.com, Shopee
   -

   Jianzhen Wu, myjianz...@gmail.com, Shopee
   -

   Nagella Jagadeewara Rao, jnage...@visa.com, Visa
   -

   Pralab Kumar, pralk...@visa.com, Visa
   -

   Prasad Shrikant, shrikant@gmail.com, Visa
   -

   Brahma Reddy Battula, bra...@apache.org, Visa


The following are existing PPMC members that have expressed interest in
remaining:

   -

   Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
   Retirement DISCUSS thread [2])
   -

   Alex Bozart, ajboz...@us.ibm.com, IBM


Committers

   -

   Others have expressed interest in joining but did not get names prior to
   this notice. Will follow up after this initial set of changes.




   1.

   Original Apache Livy Proposal
   https://cwiki.apache.org/confluence/display/incubator/LivyProposal
   2.

   Retirement DISCUSS thread
   https://lists.apache.org/thread/gcstsrhbp91c5mm55htqn1l3djv8m7o0
   3.

   Revival Proposal on general@incubator
   https://lists.apache.org/thread/hfldoydc5f2hw62n64k2j9kdbl2hn5dd


thanks,

--larry

Re: [NOTICE] Adding new PPMC and Committers to Apache Livy

[larry mccay]

All -

In preparing to add the members listed in this NOTICE, I came to realize
that we have a number of new contributors that are not existing committers
on other projects or that I can't find their account given their listed
name.

I intend to add all existing Apache committers from this list in this
thread within the next hour or so but will also follow up with the
individuals to formally invite them to the podling and start the process
for adding new accounts upon completion of the required ICLAs.

@Justin Mclean  - if you or anyone else has any
guidance on how to deal with this case please instruct me otherwise.

Those listed on the To: line, you will need to be added as committers
through the New Committer Process unless you are already one and I have
missed it.

Note that I will also be removing PPMC members that have not explicitly
opted back in. I will leave them as committers however.

thanks,

--larry

On Wed, Oct 26, 2022 at 2:30 PM larry mccay  wrote:

> Hi Incubator -
>
> In an effort to revive the Livy podling [1], it is being proposed to
> adjust the existing Livy PPMC by adding new members that plan to move the
> project forward, remove members that have not opted back in and add a
> number of new Mentors to the project.
>
>
> The following lists of new contributors and roles represent those that
> have explicitly expressed interest in doing so either by the original
> revival Proposal [3] or the resulting email thread. It was suggested on the
> revival proposal thread [3] that we provide the proposed list of changes to
> the community here as notice and that if after 72 hrs there are no
> objections an IPMC member would be able to make these changes.
>
> Mentors
>
>-
>
>Larry McCay, lmc...@apache.org , Cloudera
>-
>
>Sunil Govindan, sun...@apache.org, Cloudera
>-
>
>Jean-Baptiste Onofré, jbono...@apache.org, Talend
>-
>
>Madhawa Gunasekara, madhaw...@gmail.com, Independent
>
>
> PPMC
>
> The following are new PPMC members and Committers to be added:
>
>-
>
>Larry McCay, lmc...@apache.org, Cloudera
>-
>
>Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>-
>
>Imran Rashid - iras...@apache.org, Cloudera
>-
>
>Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>-
>
>Wing Yew Poon, wyp...@cloudera.com, Cloudera
>-
>
>Xilang Yan, xilang@gmail.com, Shopee
>-
>
>Jianzhen Wu, myjianz...@gmail.com, Shopee
>-
>
>Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>-
>
>Pralab Kumar, pralk...@visa.com, Visa
>-
>
>Prasad Shrikant, shrikant@gmail.com, Visa
>-
>
>Brahma Reddy Battula, bra...@apache.org, Visa
>
>
> The following are existing PPMC members that have expressed interest in
> remaining:
>
>-
>
>Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>Retirement DISCUSS thread [2])
>-
>
>Alex Bozart, ajboz...@us.ibm.com, IBM
>
>
> Committers
>
>-
>
>Others have expressed interest in joining but did not get names prior
>to this notice. Will follow up after this initial set of changes.
>
>
>
>
>1.
>
>Original Apache Livy Proposal
>https://cwiki.apache.org/confluence/display/incubator/LivyProposal
>2.
>
>Retirement DISCUSS thread
>https://lists.apache.org/thread/gcstsrhbp91c5mm55htqn1l3djv8m7o0
>3.
>
>Revival Proposal on general@incubator
>https://lists.apache.org/thread/hfldoydc5f2hw62n64k2j9kdbl2hn5dd
>
>
> thanks,
>
> --larry
>

Re: [NOTICE] Adding new PPMC and Committers to Apache Livy

[larry mccay]

Thanks, Justin.

I'll get that part moving tomorrow sometime.

On Sat, Oct 29, 2022, 4:37 PM Justin Mclean 
wrote:

> Hi,
>
> I intend to add all existing Apache committers from this list in this
> thread within the next hour or so but will also follow up with the
> individuals to formally invite them to the podling and start the process
> for adding new accounts upon completion of the required ICLAs.
>
> @Justin Mclean  - if you or anyone else has any
> guidance on how to deal with this case please instruct me otherwise.
>
>
> Just have them sign ICLAs, in some cases their employer may require a
> CCLA. [1] Details on how to add committers are here [2]
>
> Kind Regards,
> Justin
>
> 1. https://www.apache.org/licenses/contributor-agreements.html#clas
> 2. https://www.apache.org/dev/pmc.html#newcommitter
>

Re: [NOTICE] Adding new PPMC and Committers to Apache Livy

[larry mccay]

All -

I have sent a single invitation to all those on the to-list here to become
committers.
Follow the instructions for acceptance and filing your ICLA and userid
selection.

Please feel free to reply only to the priv...@livy.incubator.apache.org
list instead of reply-all with any questions.

Since we have already sent the notice, we will add you to the Livy podling
roster upon receipt of your ICLAs.

thanks,

--larry

On Sat, Oct 29, 2022 at 2:09 PM larry mccay  wrote:

> All -
>
> In preparing to add the members listed in this NOTICE, I came to realize
> that we have a number of new contributors that are not existing committers
> on other projects or that I can't find their account given their listed
> name.
>
> I intend to add all existing Apache committers from this list in this
> thread within the next hour or so but will also follow up with the
> individuals to formally invite them to the podling and start the process
> for adding new accounts upon completion of the required ICLAs.
>
> @Justin Mclean  - if you or anyone else has any
> guidance on how to deal with this case please instruct me otherwise.
>
> Those listed on the To: line, you will need to be added as committers
> through the New Committer Process unless you are already one and I have
> missed it.
>
> Note that I will also be removing PPMC members that have not explicitly
> opted back in. I will leave them as committers however.
>
> thanks,
>
> --larry
>
> On Wed, Oct 26, 2022 at 2:30 PM larry mccay  wrote:
>
>> Hi Incubator -
>>
>> In an effort to revive the Livy podling [1], it is being proposed to
>> adjust the existing Livy PPMC by adding new members that plan to move the
>> project forward, remove members that have not opted back in and add a
>> number of new Mentors to the project.
>>
>>
>> The following lists of new contributors and roles represent those that
>> have explicitly expressed interest in doing so either by the original
>> revival Proposal [3] or the resulting email thread. It was suggested on the
>> revival proposal thread [3] that we provide the proposed list of changes to
>> the community here as notice and that if after 72 hrs there are no
>> objections an IPMC member would be able to make these changes.
>>
>> Mentors
>>
>>-
>>
>>Larry McCay, lmc...@apache.org , Cloudera
>>-
>>
>>Sunil Govindan, sun...@apache.org, Cloudera
>>-
>>
>>Jean-Baptiste Onofré, jbono...@apache.org, Talend
>>-
>>
>>Madhawa Gunasekara, madhaw...@gmail.com, Independent
>>
>>
>> PPMC
>>
>> The following are new PPMC members and Committers to be added:
>>
>>-
>>
>>Larry McCay, lmc...@apache.org, Cloudera
>>-
>>
>>Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>>-
>>
>>Imran Rashid - iras...@apache.org, Cloudera
>>-
>>
>>Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>>-
>>
>>Wing Yew Poon, wyp...@cloudera.com, Cloudera
>>-
>>
>>Xilang Yan, xilang@gmail.com, Shopee
>>-
>>
>>Jianzhen Wu, myjianz...@gmail.com, Shopee
>>-
>>
>>Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>>-
>>
>>Pralab Kumar, pralk...@visa.com, Visa
>>-
>>
>>Prasad Shrikant, shrikant@gmail.com, Visa
>>-
>>
>>Brahma Reddy Battula, bra...@apache.org, Visa
>>
>>
>> The following are existing PPMC members that have expressed interest in
>> remaining:
>>
>>-
>>
>>Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>>Retirement DISCUSS thread [2])
>>-
>>
>>Alex Bozart, ajboz...@us.ibm.com, IBM
>>
>>
>> Committers
>>
>>-
>>
>>Others have expressed interest in joining but did not get names prior
>>to this notice. Will follow up after this initial set of changes.
>>
>>
>>
>>
>>1.
>>
>>Original Apache Livy Proposal
>>https://cwiki.apache.org/confluence/display/incubator/LivyProposal
>>2.
>>
>>Retirement DISCUSS thread
>>https://lists.apache.org/thread/gcstsrhbp91c5mm55htqn1l3djv8m7o0
>>3.
>>
>>Revival Proposal on general@incubator
>>https://lists.apache.org/thread/hfldoydc5f2hw62n64k2j9kdbl2hn5dd
>>
>>
>> thanks,
>>
>> --larry
>>
>

Re: [NOTICE] Adding new PPMC and Committers to Apache Livy

[larry mccay]

Hi Marco -

Sorry if it wasn't clear, anyone that was already a committer on any
project that expressed interest has already been added.
The invitations are only for the brand new committers.

You are already on the PPMC list.

Thank you for following up those, just in case!

thanks,

--larry

On Mon, Oct 31, 2022 at 4:49 AM Marco Gaido  wrote:

> Hi Larry,
>
> I also expressed my interest in still being part of the community. At
> least for the thriftserver part, which I contributed and maintained.
>
> Thanks,
> Marco
>
> Il giorno lun 31 ott 2022 alle ore 02:08 larry mccay 
> ha scritto:
>
>> All -
>>
>> I have sent a single invitation to all those on the to-list here to
>> become committers.
>> Follow the instructions for acceptance and filing your ICLA and userid
>> selection.
>>
>> Please feel free to reply only to the priv...@livy.incubator.apache.org
>> list instead of reply-all with any questions.
>>
>> Since we have already sent the notice, we will add you to the Livy
>> podling roster upon receipt of your ICLAs.
>>
>> thanks,
>>
>> --larry
>>
>> On Sat, Oct 29, 2022 at 2:09 PM larry mccay  wrote:
>>
>>> All -
>>>
>>> In preparing to add the members listed in this NOTICE, I came to realize
>>> that we have a number of new contributors that are not existing committers
>>> on other projects or that I can't find their account given their listed
>>> name.
>>>
>>> I intend to add all existing Apache committers from this list in this
>>> thread within the next hour or so but will also follow up with the
>>> individuals to formally invite them to the podling and start the process
>>> for adding new accounts upon completion of the required ICLAs.
>>>
>>> @Justin Mclean  - if you or anyone else has any
>>> guidance on how to deal with this case please instruct me otherwise.
>>>
>>> Those listed on the To: line, you will need to be added as committers
>>> through the New Committer Process unless you are already one and I have
>>> missed it.
>>>
>>> Note that I will also be removing PPMC members that have not explicitly
>>> opted back in. I will leave them as committers however.
>>>
>>> thanks,
>>>
>>> --larry
>>>
>>> On Wed, Oct 26, 2022 at 2:30 PM larry mccay  wrote:
>>>
>>>> Hi Incubator -
>>>>
>>>> In an effort to revive the Livy podling [1], it is being proposed to
>>>> adjust the existing Livy PPMC by adding new members that plan to move the
>>>> project forward, remove members that have not opted back in and add a
>>>> number of new Mentors to the project.
>>>>
>>>>
>>>> The following lists of new contributors and roles represent those that
>>>> have explicitly expressed interest in doing so either by the original
>>>> revival Proposal [3] or the resulting email thread. It was suggested on the
>>>> revival proposal thread [3] that we provide the proposed list of changes to
>>>> the community here as notice and that if after 72 hrs there are no
>>>> objections an IPMC member would be able to make these changes.
>>>>
>>>> Mentors
>>>>
>>>>-
>>>>
>>>>Larry McCay, lmc...@apache.org , Cloudera
>>>>-
>>>>
>>>>Sunil Govindan, sun...@apache.org, Cloudera
>>>>-
>>>>
>>>>Jean-Baptiste Onofré, jbono...@apache.org, Talend
>>>>-
>>>>
>>>>Madhawa Gunasekara, madhaw...@gmail.com, Independent
>>>>
>>>>
>>>> PPMC
>>>>
>>>> The following are new PPMC members and Committers to be added:
>>>>
>>>>-
>>>>
>>>>Larry McCay, lmc...@apache.org, Cloudera
>>>>-
>>>>
>>>>Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>>>>-
>>>>
>>>>Imran Rashid - iras...@apache.org, Cloudera
>>>>-
>>>>
>>>>Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>>>>-
>>>>
>>>>Wing Yew Poon, wyp...@cloudera.com, Cloudera
>>>>-
>>>>
>>>>Xilang Yan, xilang@gmail.com, Shopee
>>>>-
>>>>
>>>>Jianzhen Wu, myjianz...@gmail.com, Shopee
>>>>-
>>>>
>>>> 

Re: [NOTICE] Adding new PPMC and Committers to Apache Livy

[larry mccay]

Please subscribe to the Livy lists as I plan to start DISCUSS threads on a
couple topics to help bootstrap.
We don't need to wait for everyone to be added to start the community
conversations.

On Sun, Oct 30, 2022 at 9:08 PM larry mccay  wrote:

> All -
>
> I have sent a single invitation to all those on the to-list here to become
> committers.
> Follow the instructions for acceptance and filing your ICLA and userid
> selection.
>
> Please feel free to reply only to the priv...@livy.incubator.apache.org
> list instead of reply-all with any questions.
>
> Since we have already sent the notice, we will add you to the Livy podling
> roster upon receipt of your ICLAs.
>
> thanks,
>
> --larry
>
> On Sat, Oct 29, 2022 at 2:09 PM larry mccay  wrote:
>
>> All -
>>
>> In preparing to add the members listed in this NOTICE, I came to realize
>> that we have a number of new contributors that are not existing committers
>> on other projects or that I can't find their account given their listed
>> name.
>>
>> I intend to add all existing Apache committers from this list in this
>> thread within the next hour or so but will also follow up with the
>> individuals to formally invite them to the podling and start the process
>> for adding new accounts upon completion of the required ICLAs.
>>
>> @Justin Mclean  - if you or anyone else has any
>> guidance on how to deal with this case please instruct me otherwise.
>>
>> Those listed on the To: line, you will need to be added as committers
>> through the New Committer Process unless you are already one and I have
>> missed it.
>>
>> Note that I will also be removing PPMC members that have not explicitly
>> opted back in. I will leave them as committers however.
>>
>> thanks,
>>
>> --larry
>>
>> On Wed, Oct 26, 2022 at 2:30 PM larry mccay  wrote:
>>
>>> Hi Incubator -
>>>
>>> In an effort to revive the Livy podling [1], it is being proposed to
>>> adjust the existing Livy PPMC by adding new members that plan to move the
>>> project forward, remove members that have not opted back in and add a
>>> number of new Mentors to the project.
>>>
>>>
>>> The following lists of new contributors and roles represent those that
>>> have explicitly expressed interest in doing so either by the original
>>> revival Proposal [3] or the resulting email thread. It was suggested on the
>>> revival proposal thread [3] that we provide the proposed list of changes to
>>> the community here as notice and that if after 72 hrs there are no
>>> objections an IPMC member would be able to make these changes.
>>>
>>> Mentors
>>>
>>>-
>>>
>>>Larry McCay, lmc...@apache.org , Cloudera
>>>-
>>>
>>>Sunil Govindan, sun...@apache.org, Cloudera
>>>-
>>>
>>>Jean-Baptiste Onofré, jbono...@apache.org, Talend
>>>-
>>>
>>>Madhawa Gunasekara, madhaw...@gmail.com, Independent
>>>
>>>
>>> PPMC
>>>
>>> The following are new PPMC members and Committers to be added:
>>>
>>>-
>>>
>>>Larry McCay, lmc...@apache.org, Cloudera
>>>-
>>>
>>>Vinod Kumar Vavilapalli, vino...@cloudera.com, Cloudera
>>>-
>>>
>>>Imran Rashid - iras...@apache.org, Cloudera
>>>-
>>>
>>>Gyorgy Gal, ggal ,gal.gyo...@gmail.com, Cloudera
>>>-
>>>
>>>Wing Yew Poon, wyp...@cloudera.com, Cloudera
>>>-
>>>
>>>Xilang Yan, xilang@gmail.com, Shopee
>>>-
>>>
>>>Jianzhen Wu, myjianz...@gmail.com, Shopee
>>>-
>>>
>>>Nagella Jagadeewara Rao, jnage...@visa.com, Visa
>>>-
>>>
>>>Pralab Kumar, pralk...@visa.com, Visa
>>>-
>>>
>>>Prasad Shrikant, shrikant@gmail.com, Visa
>>>-
>>>
>>>Brahma Reddy Battula, bra...@apache.org, Visa
>>>
>>>
>>> The following are existing PPMC members that have expressed interest in
>>> remaining:
>>>
>>>-
>>>
>>>Jean-Baptiste Onofré, jbono...@apache.org, Talend (opted-in via
>>>Retirement DISCUSS thread [2])
>>>-
>>>
>>>Alex Bozart, ajboz...@us.ibm.com, IBM
>>>
>>>
>>> Committers
>>>
>>>-
>>>
>>>Others have expressed interest in joining but did not get names
>>>prior to this notice. Will follow up after this initial set of changes.
>>>
>>>
>>>
>>>
>>>1.
>>>
>>>Original Apache Livy Proposal
>>>https://cwiki.apache.org/confluence/display/incubator/LivyProposal
>>>2.
>>>
>>>Retirement DISCUSS thread
>>>https://lists.apache.org/thread/gcstsrhbp91c5mm55htqn1l3djv8m7o0
>>>3.
>>>
>>>Revival Proposal on general@incubator
>>>https://lists.apache.org/thread/hfldoydc5f2hw62n64k2j9kdbl2hn5dd
>>>
>>>
>>> thanks,
>>>
>>> --larry
>>>
>>

[NOTICE] Adding Shaofeng Li to PPMC for Apache Livy Podling

[larry mccay]

Hi IPMC -

Shaofeng Li has expressed interest in joining the revived PPMC for the Livy
Podling.
I will be adding them as requested and this service as notice of our doing
so.

thanks!

--larry

[NOTICE] Adding Damon Cortesi as Apache Livy PPMC

[larry mccay]

Hi IPMC -

Damon Cortesi has expressed interest in joining the revived PPMC for the
Livy Podling.
I will be adding them as requested and this serves as notice of our doing
so.

thanks!

--larry

Re: [VOTE] Apache Tuweni 2.3.1-incubating

[larry mccay]

Built from source, checked NOTICE and LICENSE files

+1

On Mon, Nov 28, 2022 at 7:10 PM Antoine Toulme  wrote:

> We are short at least one vote - would anyone please be able to test out
> this release and vote?
>
> Cheers,
>
> Antoine
>
> > On Nov 24, 2022, at 12:25 PM, Furkan KAMACI 
> wrote:
> >
> > +1 (binding, carrying over my vote)
> >
> > On Thu, Nov 24, 2022 at 7:47 PM Antoine Toulme 
> wrote:
> >
> >> Here is my +1.
> >>
> >>> On Nov 24, 2022, at 8:46 AM, Antoine Toulme 
> wrote:
> >>>
> >>> Hello all,
> >>> This is a call for a vote to release Apache Tuweni (incubating) version
> >> 2.3.1. Apache Tuweni is a set of libraries and other tools to aid
> >> development of blockchain and other decentralized software in Java and
> >> other JVM languages. It includes a low-level bytes library,
> serialization
> >> and deserialization codecs (e.g. RLP), various cryptography functions
> and
> >> primitives, and lots of other helpful utilities.
> >>>
> >>> The Apache Tuweni community has voted on and approved a proposal to
> >> release Apache Tuweni (Incubating) version 2.3.1. We would like to
> request
> >> the Incubator PMC members review and vote on this incubator release.
> >>>
> >>> Release information:
> >>> Vote result thread:
> >>> https://lists.apache.org/thread/rk1m74zqfxx3wr0ftobwr4omw5t9n8mw
> >>>
> >>>
> >>> We're voting on the source distributions available here:
> >>>
> https://dist.apache.org/repos/dist/dev/incubator/tuweni/2.3.1-incubating
> >> <
> https://dist.apache.org/repos/dist/dev/incubator/tuweni/2.3.1-incubating>
> >>> The release tag is present here:
> >>>
> >>
> https://github.com/apache/incubator-tuweni/releases/tag/v2.3.1-incubating-rc
> >> <
> >>
> https://github.com/apache/incubator-tuweni/releases/tag/v2.3.1-incubating-rc
> >>>
> >>>
> >>> Please review and vote as appropriate.
> >>>
> >>> The following changes were made since 2.3.0:
> >>> #447 (https://github.com/apache/incubator-tuweni/pull/447): Fixes a
> >> corner case of bytes comparisons if both objects are only representing
> zero
> >> bytes, but they have different sizes.
> >>> #445 (https://github.com/apache/incubator-tuweni/issues/445): slice
> >> method on ConstantBytes32Value ignores second parameter
> >>>
> >>> This is a small bugfix release to address #445.
> >>>
> >>> The vote is open until Monday November 28th, 9am PST.
> >>> Cheers,
> >>>
> >>> Antoine
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Tuweni graduation

[larry mccay]

I'm not so sure that I see this as a blocker for graduation.
There was enough consensus and testing to spin and publish 14 releases.
There has been healthy conversation about this very topic among the mentors
and contributors on the private list.

The nature of this project is that the consumption of these libraries are
going to get less traction while in incubation and a community may grow
larger as a TLP as confidence is instilled by that status.

The Tuweni community has demonstrated the ability to publish releases
within that Apache Way and guidelines, has welcomed new contributors, etc.
The long term success will require a larger active community but I don't
think that needs to block graduation as the incubation goals have been met.

My 2 cents.

On Mon, Dec 5, 2022 at 7:41 PM Willem Jiang  wrote:

> I agree with Gang Li. The Bus factor[1] of this project is relatively high.
>
> [1]https://en.wikipedia.org/wiki/Bus_factor
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Dec 5, 2022 at 11:06 PM li gang  wrote:
> >
> > I checked the contributions of the Tuweni project[1],the traffic of the
> > mail list d...@tuweni.apache.org[2] and the KEYS[3].
> >
> > It looks like the project is mainly maintained by Antoine Toulme self,
> > I have a concern this is not comply with the diversity.
> >
> > [1]https://github.com/apache/incubator-tuweni/graphs/contributors
> > [2]https://lists.apache.org/list?d...@tuweni.apache.org
> > [3]https://downloads.apache.org/incubator/tuweni/KEYS
> >
> > Antoine Toulme  于2022年12月5日周一 15:14写道：
> >
> > > Dear Apache Incubator Community and IPMC members,
> > >
> > > We discussed the graduation for Tuweni in the Apache Incubator
> > > Community [4], where no issues were raised and positive replies were
> > > received.
> > > After having the graduation discussion in the Tuweni community [1], we
> > > have passed the vote within Tuweni community [2] and the vote result
> > > was published [3].
> > >
> > > I would like to start this voting thread to request graduating Apache
> > > Tuweni(incubating) from Apache Incubator as a Top Level Project.
> > >
> > > Please provide your vote accordingly:
> > > [ ] +1 Yes, I support Tuweni project to graduate from the Apache
> Incubator.
> > > [ ] +0 No opinion.
> > > [ ] -1 No, the Tuweni project is not ready to graduate, because...
> > >
> > > Thank you for participating in the vote. This vote will stay open for
> at
> > > least 72 hours.
> > >
> > > Here is an overview of the Apache Tuweni(incubating) to help with the
> > > vote.
> > >
> > > *Community*
> > >
> > > ● The PPMC is active, with PMC members voting for graduation along with
> > > mentors.
> > > ● 6 new committers were added, bringing the total number of committers
> to
> > > 14 from 12 different
> > > organizations.
> > > ● The number of contributors is now 25 and growing.
> > > ● The dev@Tuweni mailing list currently has 33 subscribers [4].
> > >
> > > *Project*
> > >
> > > ● Apache Tuweni (incubating) is a set of libraries and other tools to
> aid
> > > development of blockchain and other  decentralized software in Java and
> > > other JVM languages. It includes a low-level bytes library,
> serialization
> > > and deserialization codecs (e.g. RLP), various cryptography functions
> and
> > > primitives, and lots of other helpful utilities. Tuweni is developed
> for
> > > JDK 11 or higher.
> > > ● Project maturity model and incubation status is detailed in [5]
> > > ● Tuweni has been incubating [5] since 2019-02-25 for over 45
> > > months.
> > > ● Tuweni community released a total of 14 Apache releases [6].
> > > ● 331 pull requests created closed [7].
> > > ● 76 issues created, and 46 issues closed [8].
> > > ● The release cadence is about 3 months.
> > >
> > > *Brand, License, and Copyright*
> > >
> > > ● We submitted an application for the brand [9] and it has been
> > > reviewed and approved.
> > > ● Tuweni community maintains project code on GitHub and all modules
> > > code is under Apache 2.0 license. We have reviewed all the
> > > dependencies and ensured they do not bring any license issues [10].
> > > All the status files, license headers, and copyright are up to date.
> > > ● Tuweni official website [11] is compliant with Apache Foundation
> > > requirements [12].
> > >
> > > [1] https://lists.apache.org/thread/z3flpmqcss21xc8vmtwqqfs961p4g9t5
> > > [2] https://lists.apache.org/thread/c04cmvfwh1wt2mxmc9zo89o6bnhm2xqk
> > > [3] https://lists.apache.org/thread/8m4lq3k1v93m1k482syj7kn1ldb62665
> > > [4] https://lists.apache.org/list.html?d...@tuweni.apache.org
> > > [5] https://incubator.apache.org/projects/tuweni.html
> > > [6] https://github.com/apache/incubator-tuweni/releases
> > > [7] https://github.com/apache/incubator-tuweni/pulls
> > > [8] https://github.com/apache/incubator-tuweni/issues
> > > [9] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-167
> > > [10] https://github.com/apache/incubator-tuweni/blob/main/LICENSE
> > > [11] https

Re: [VOTE] Apache Tuweni graduation

[larry mccay]

We have also recently seen long term incubating projects with considerable
adoption falter.
I consider the fact that they did not graduate early enough a contributing
factor here.

Nothing wrong with incubation but staying in the incubator and encountering
attrition is different from TLP
with some churn with new folks coming into an official TLP project while
others can fall off in a healthy way.

Again, having the community test and release 14 separate releases
demonstrates contributors in the community
even if they aren't all materially contributing code.



On Wed, Dec 7, 2022 at 3:45 AM Christofer Dutz 
wrote:

> Hi all,
>
> And in the last few months the ASF has sadly seen enough cases, in which
> even big projects suffered from the lack of diversity.
> So, I would also consider this to be a blocker.
>
> Community building isn’t something that happens or comes for free.
> It’s actually hard work, but it needs to be done.
>
> Just my opinion on this topic.
>
> Chris
>
> From: Willem Jiang 
> Date: Wednesday, 7. December 2022 at 02:59
> To: general@incubator.apache.org 
> Subject: Re: [VOTE] Apache Tuweni graduation
> It looks like we need a dedicated community leader[1] to build a
> diverse community (just borrow a pattern from InnerSource Common[2]).
>
> " Communication takes up a significant percentage of a community
> leader's daily work. At the same time, he or she will likely also have
> to spearhead the initial development, too. In the face of limited
> capacity, inexperienced leaders will tend to focus on development and
> neglect communication. The barrier for potential contributors to make
> their first contribution and to commit to the community will be much
> higher if the community leader is hard to reach or is slow to respond
> to feedback and questions for lack of time."
>
> [1]
> https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/dedicated-community-leader.md#forces
> [2]https://innersourcecommons.org/
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Dec 6, 2022 at 9:51 AM larry mccay  wrote:
> >
> > I'm not so sure that I see this as a blocker for graduation.
> > There was enough consensus and testing to spin and publish 14 releases.
> > There has been healthy conversation about this very topic among the
> mentors
> > and contributors on the private list.
> >
> > The nature of this project is that the consumption of these libraries are
> > going to get less traction while in incubation and a community may grow
> > larger as a TLP as confidence is instilled by that status.
> >
> > The Tuweni community has demonstrated the ability to publish releases
> > within that Apache Way and guidelines, has welcomed new contributors,
> etc.
> > The long term success will require a larger active community but I don't
> > think that needs to block graduation as the incubation goals have been
> met.
> >
> > My 2 cents.
> >
> > On Mon, Dec 5, 2022 at 7:41 PM Willem Jiang 
> wrote:
> >
> > > I agree with Gang Li. The Bus factor[1] of this project is relatively
> high.
> > >
> > > [1]https://en.wikipedia.org/wiki/Bus_factor
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Mon, Dec 5, 2022 at 11:06 PM li gang  wrote:
> > > >
> > > > I checked the contributions of the Tuweni project[1],the traffic of
> the
> > > > mail list d...@tuweni.apache.org[2] and the KEYS[3].
> > > >
> > > > It looks like the project is mainly maintained by Antoine Toulme
> self,
> > > > I have a concern this is not comply with the diversity.
> > > >
> > > > [1]https://github.com/apache/incubator-tuweni/graphs/contributors
> > > > [2]https://lists.apache.org/list?d...@tuweni.apache.org
> > > > [3]https://downloads.apache.org/incubator/tuweni/KEYS
> > > >
> > > > Antoine Toulme  于2022年12月5日周一 15:14写道：
> > > >
> > > > > Dear Apache Incubator Community and IPMC members,
> > > > >
> > > > > We discussed the graduation for Tuweni in the Apache Incubator
> > > > > Community [4], where no issues were raised and positive replies
> were
> > > > > received.
> > > > > After having the graduation discussion in the Tuweni community
> [1], we
> > > > > have passed the vote within Tuweni community [2] and the vote
> result
> > > > > was published [3].
> > > > >
> &

Re: [VOTE] Apache Tuweni graduation

[larry mccay]

+1 to graduate Tuweni to TLP.


On Sat, Dec 10, 2022 at 8:24 PM Antoine Toulme  wrote:

> Hello folks,
>
> Apache Tuweni had a much smaller community when it started its incubation
> at Apache. The path of this project has been impacted by the domain it
> applies to and the pandemic certainly hasn't helped. Still it has managed
> to create enough momentum to make regular releases and check off all
> incubation checks.
> Community building is definitely still on the menu - right now and later
> as well. We will continue building and including folks. We have onboarded
> successfully multiple committers and have received contributions. I expect
> this trend to continue and mature.
>
> The question is whether the best place for us to continue growing is the
> incubator. The incubator adds additional checks on our releases and slows
> down our cycles, which has historically driven folks to fork and move away
> from the project.
>
> The incubator doesn't offer opportunities for community building, from
> what I know. We will need to continue to build our image and presence to
> attract contributors on our own.
>
> The project mentors have been nothing short of fantastic. They have been
> helpful in maturing the project. In my opinion, we are using their precious
> time when they should be engaged in helping other projects of the incubator.
>
> With this, I want to thank the incubator. We had a great experience
> building with you all. I personally believe we should free the incubator's
> time and attention to concentrate on other projects. I also believe the
> project is mature enough to function outside of the incubator.
>
> I vote +1 to graduate Tuweni from the incubator.
>
> Thanks,
>
> Antoine
>
> > On Dec 7, 2022, at 3:37 PM, larry mccay  wrote:
> >
> > We have also recently seen long term incubating projects with
> considerable
> > adoption falter.
> > I consider the fact that they did not graduate early enough a
> contributing
> > factor here.
> >
> > Nothing wrong with incubation but staying in the incubator and
> encountering
> > attrition is different from TLP
> > with some churn with new folks coming into an official TLP project while
> > others can fall off in a healthy way.
> >
> > Again, having the community test and release 14 separate releases
> > demonstrates contributors in the community
> > even if they aren't all materially contributing code.
> >
> >
> >
> > On Wed, Dec 7, 2022 at 3:45 AM Christofer Dutz <
> christofer.d...@c-ware.de>
> > wrote:
> >
> >> Hi all,
> >>
> >> And in the last few months the ASF has sadly seen enough cases, in which
> >> even big projects suffered from the lack of diversity.
> >> So, I would also consider this to be a blocker.
> >>
> >> Community building isn’t something that happens or comes for free.
> >> It’s actually hard work, but it needs to be done.
> >>
> >> Just my opinion on this topic.
> >>
> >> Chris
> >>
> >> From: Willem Jiang 
> >> Date: Wednesday, 7. December 2022 at 02:59
> >> To: general@incubator.apache.org 
> >> Subject: Re: [VOTE] Apache Tuweni graduation
> >> It looks like we need a dedicated community leader[1] to build a
> >> diverse community (just borrow a pattern from InnerSource Common[2]).
> >>
> >> " Communication takes up a significant percentage of a community
> >> leader's daily work. At the same time, he or she will likely also have
> >> to spearhead the initial development, too. In the face of limited
> >> capacity, inexperienced leaders will tend to focus on development and
> >> neglect communication. The barrier for potential contributors to make
> >> their first contribution and to commit to the community will be much
> >> higher if the community leader is hard to reach or is slow to respond
> >> to feedback and questions for lack of time."
> >>
> >> [1]
> >>
> https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/dedicated-community-leader.md#forces
> >> [2]https://innersourcecommons.org/
> >>
> >> Willem Jiang
> >>
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >> On Tue, Dec 6, 2022 at 9:51 AM larry mccay  wrote:
> >>>
> >>> I'm not so sure that I see this as a blocker for graduation.
> >>> There was enough consensus and testing to spin and publish 14 releases.
> >>> There has been healt

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[larry mccay]

I wanted to lend a hand with the sdap 1.0.0 release review and wanted to
let you know that it seems a bit cumbersome to review.
Perhaps my experience with other projects is limited to similar
conventions, though.

The fact that the src artifacts aren't under a project specific root ended
up polluting my releases directory (where I review releases). This was my
fault for not noticing the missing root but clearly outside my
expectations.

I also notice that each of what I would expect to just be separate modules
have their own tar balls and even github mirrors which is also awkward for
how I expect to review things - though not technically related to typical
review requirements.

These may be seen as less relevant to the specific release at hand and more
for the overall project structure and conventions but they would certainly
help in reviewing.

I note that there are numerous files [1][2][3] and many more that may
require Apache License headers.

You can use something like the following in python files:
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

The NOTICE file has a copyright of 2017-2022 still and unless this goes out
in the next couple days that will be out of date.
Duplicate and separate files like NOTICE, LICENSE, DISCLAIMER access
ingester, nexus and nexusproto as well as CONTRIBUTING.md which is in 2 but
not the other point to some organization issues. There should be some
effort put in to possibly make these modules under a common project rather
than what seem like separate projects.

Some of the above make it pretty cumbersome to review even if not
technically blockers.
Addressing these sorts of things early will help contributors feel more
easily able to help out and can help build your community.
It will also help you get releases out easier.

Hope the above is useful for you.
Happy to see a release coming together for the SDAP community and
congratulate you on tackling this milestone!

It isn't clear to me that these should block your initial release - my vote
would be as follows:
-0 for my vote at this time.

1.
https://github.com/apache/incubator-sdap-ingester/blob/dev/collection_manager/requirements.txt
2.
https://github.com/apache/incubator-sdap-ingester/blob/dev/collection_manager/setup.py
3.
https://github.com/apache/incubator-sdap-ingester/blob/dev/collection_manager/collection_manager/main.py


On Fri, Dec 30, 2022 at 4:30 PM Julian Hyde  wrote:

> Good catch. But could you (and others) continue the process of
> reviewing and voting on the release.
>
> It is established that an official ASF release must not contain
> gradle-wrapper.jar [1], but in my opinion this is a problem that could
> be solved in the next incubating release. If a few IPMC members
> surface several issues this time around, the second release should be
> much cleaner.
>
> Julian
>
> [1] https://issues.apache.org/jira/browse/LEGAL-570
>
> On Thu, Dec 29, 2022 at 5:44 PM Calvin Kirs  wrote:
> >
> > Hi,
> >
> > There has a compiled code (gradle-wrapper jar) in the source release.
> >
> > [1]
> https://dist.apache.org/repos/dist/dev/incubator/sdap/apache-sdap-1.0.0-rc2/apache-sdap-nexusproto-1.0.0-src.tar.gz
> >
> > On Sat, Dec 24, 2022 at 5:46 AM Riley Kuttruff  wrote:
> > >
> > > Hello,
> > >
> > > In consideration of the upcoming holiday weekend, let's extend this
> vote to last to a week from now.
> > >
> > > Thank you,
> > > Riley
> > >
> > > On 2022/12/23 03:19:10 Riley Kuttruff wrote:
> > > > Hello everyone,
> > > >
> > > > This is a call for a vote to release Apache SDAP (incubating)
> version 1.0.0-rc2.
> > > >
> > > > The Apache SDAP community has voted to approve release of Apache
> SDAP (incubating) version 1.0.0-rc2.
> > > >
> > > > We now request the Incubator PMC review and vote on this release.
> > > >
> > > > SDAP community vote thread:
> > > > https://lists.apache.org/thread/6nmknw8n1flwsqp4n3cromnrck21xmh9
> > > >
> > > > Instructions for building docker images from source can be found
> here:
> > > > https://incubator-sdap-nexus.readthedocs.io/en/latest/build.html
> > > > Instructions for deploying locally to test can be found here:
> > > >
> https://incubator-sdap-nexus.readthedocs.io/en/latest/quickstart.html
> > > >
> > > > The tags to be voted on are 1.0.0-rc2:
> > > >

Re: [VOTE] Release Apache SDAP (incubating) 1.0.0-rc2

[larry mccay]

"I would like to point out in regards to the missing ASF headers that the
links you provide are on a different branch than the one we built the
release from."

Apologies, I was jumping around between github repos and got confused.

That said, it seems to me that your release branch having the headers and
dev and/or master branches not having them may point to a dev/release flow
that may result in regressions. Perhaps you have a different Trunk or
whatever your main branch is though. In general, I would expect your main
branch to have a superset of the changes in your release branch.

Just to be sure, you don't intend to only license the release
branch's source as ASL, right?

On Mon, Jan 2, 2023 at 9:28 PM Riley Kuttruff  wrote:

> Thank you for the notes.
>
> I would like to point out in regards to the missing ASF headers that the
> links you provide are on a different branch than the one we built the
> release from. The release artifacts were built from the 'release/1.0.0'
> branch in their respective repositories. That said, the 'requirements.txt'
> file you linked present in the release does not contain such a header.
>
> Furthermore, with the new year, the copyright statements in the NOTICE
> files are now out of date as you observed. I'm assuming this will require a
> new release candidate?
>
> Thanks,
> Riley
>
> On 2022/12/30 23:39:13 larry mccay wrote:
> > I wanted to lend a hand with the sdap 1.0.0 release review and wanted to
> > let you know that it seems a bit cumbersome to review.
> > Perhaps my experience with other projects is limited to similar
> > conventions, though.
> >
> > The fact that the src artifacts aren't under a project specific root
> ended
> > up polluting my releases directory (where I review releases). This was my
> > fault for not noticing the missing root but clearly outside my
> > expectations.
> >
> > I also notice that each of what I would expect to just be separate
> modules
> > have their own tar balls and even github mirrors which is also awkward
> for
> > how I expect to review things - though not technically related to typical
> > review requirements.
> >
> > These may be seen as less relevant to the specific release at hand and
> more
> > for the overall project structure and conventions but they would
> certainly
> > help in reviewing.
> >
> > I note that there are numerous files [1][2][3] and many more that may
> > require Apache License headers.
> >
> > You can use something like the following in python files:
> > #
> > # Licensed to the Apache Software Foundation (ASF) under one or more
> > # contributor license agreements.  See the NOTICE file distributed with
> > # this work for additional information regarding copyright ownership.
> > # The ASF licenses this file to You under the Apache License, Version 2.0
> > # (the "License"); you may not use this file except in compliance with
> > # the License.  You may obtain a copy of the License at
> > #
> > #http://www.apache.org/licenses/LICENSE-2.0
> > #
> > # Unless required by applicable law or agreed to in writing, software
> > # distributed under the License is distributed on an "AS IS" BASIS,
> > # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > # See the License for the specific language governing permissions and
> > # limitations under the License.
> > #
> >
> > The NOTICE file has a copyright of 2017-2022 still and unless this goes
> out
> > in the next couple days that will be out of date.
> > Duplicate and separate files like NOTICE, LICENSE, DISCLAIMER access
> > ingester, nexus and nexusproto as well as CONTRIBUTING.md which is in 2
> but
> > not the other point to some organization issues. There should be some
> > effort put in to possibly make these modules under a common project
> rather
> > than what seem like separate projects.
> >
> > Some of the above make it pretty cumbersome to review even if not
> > technically blockers.
> > Addressing these sorts of things early will help contributors feel more
> > easily able to help out and can help build your community.
> > It will also help you get releases out easier.
> >
> > Hope the above is useful for you.
> > Happy to see a release coming together for the SDAP community and
> > congratulate you on tackling this milestone!
> >
> > It isn't clear to me that these should block your initial release - my
> vote
> > would be as follows:
> > -0 for my vote at this time.
> >
> > 1.
> >
> htt

Re: [VOTE] Release Apache Livy 0.8.0-incubating (RC1)

[larry mccay]

Carrying my vote forward from community vote.

+1

On Mon, Jul 31, 2023 at 8:29 PM Justin Mclean 
wrote:

> HI,
>
>  There are GPL and LGPL licensed jars in the zip. I'm not sure but I
>  thought we couldn't include jars with category X licenses in our
>  binary distributions.
>  It could be that Category X licenses are only a problem with Source
> Releases.
>
>
> They are an issue with binary releases as well - any release cannot
> include category X licensed content.
>
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Livy 0.8.0-incubating (RC1)

[larry mccay]

Hi Justin -

Thanks for the review!

Given that this is the first release since the reboot of the community, I
am wondering whether these really have to be blockers.
We can file JIRAs for each of those issues and address them in the next
release.
These aren't regressions after all and there have been 7 or 8 releases
prior.

Thanks again!

--larry

On Fri, Aug 4, 2023 at 10:43 PM Justin Mclean 
wrote:

> Hi,
>
> -1 (binding) as well as the Category X license issues with the binaries,
> LICENSE is missing a 3rd party licenses which may not be compatible with
> the ALv2.
>
> Note that the font and NOTICE file issue have been brought up before.
>
> I checked:
> - incubating in name
> - signatures and hashes are correct
> - LICENSE is missing LICENSE for [1][2] however the standard license is
> not compatible with the ALv2 one [3]. How is this licensed?
> - NOTICE is OK, but please do not use "Copyright 2018 and onwards”.
> - you may wan to update your copyright in [4]
> - all files have ASF headers
> - no unexpected binary file
> - can compile from source
>
> Kind Regards,
> Justin
>
> 1.
> ./server/src/main/resources/org/apache/livy/server/ui/static/fonts/glyphicons-halflings-regular.*
> 2.
> ./docs/assets/themes/apache/bootstrap/fonts/glyphicons-halflings-regular.*
> 3. https://www.glyphicons.com/license/
> 4. ./docs/_includes/themes/apache/footer.html
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Livy 0.8.0-incubating (RC1)

[larry mccay]

@justin  - I've filed the following two JIRA to
address your reported issues for release 0.8.1, if you approve.
Waiting on the status of the category X binary license issues - I know
@dac...@apache.org  was tracking that down.

https://issues.apache.org/jira/browse/LIVY-983
https://issues.apache.org/jira/browse/LIVY-984

On Sat, Aug 5, 2023 at 9:45 AM larry mccay  wrote:

> Hi Justin -
>
> Thanks for the review!
>
> Given that this is the first release since the reboot of the community, I
> am wondering whether these really have to be blockers.
> We can file JIRAs for each of those issues and address them in the next
> release.
> These aren't regressions after all and there have been 7 or 8 releases
> prior.
>
> Thanks again!
>
> --larry
>
> On Fri, Aug 4, 2023 at 10:43 PM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> -1 (binding) as well as the Category X license issues with the binaries,
>> LICENSE is missing a 3rd party licenses which may not be compatible with
>> the ALv2.
>>
>> Note that the font and NOTICE file issue have been brought up before.
>>
>> I checked:
>> - incubating in name
>> - signatures and hashes are correct
>> - LICENSE is missing LICENSE for [1][2] however the standard license is
>> not compatible with the ALv2 one [3]. How is this licensed?
>> - NOTICE is OK, but please do not use "Copyright 2018 and onwards”.
>> - you may wan to update your copyright in [4]
>> - all files have ASF headers
>> - no unexpected binary file
>> - can compile from source
>>
>> Kind Regards,
>> Justin
>>
>> 1.
>> ./server/src/main/resources/org/apache/livy/server/ui/static/fonts/glyphicons-halflings-regular.*
>> 2.
>> ./docs/assets/themes/apache/bootstrap/fonts/glyphicons-halflings-regular.*
>> 3. https://www.glyphicons.com/license/
>> 4. ./docs/_includes/themes/apache/footer.html
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: [VOTE] Release Apache Livy 0.8.0-incubating (RC1)

[larry mccay]

@Justin Mclean  - thoughts?

On Sat, Aug 5, 2023 at 11:51 AM larry mccay  wrote:

> @justin  - I've filed the following two JIRA to
> address your reported issues for release 0.8.1, if you approve.
> Waiting on the status of the category X binary license issues - I know
> @dac...@apache.org  was tracking that down.
>
> https://issues.apache.org/jira/browse/LIVY-983
> https://issues.apache.org/jira/browse/LIVY-984
>
> On Sat, Aug 5, 2023 at 9:45 AM larry mccay  wrote:
>
>> Hi Justin -
>>
>> Thanks for the review!
>>
>> Given that this is the first release since the reboot of the community, I
>> am wondering whether these really have to be blockers.
>> We can file JIRAs for each of those issues and address them in the next
>> release.
>> These aren't regressions after all and there have been 7 or 8 releases
>> prior.
>>
>> Thanks again!
>>
>> --larry
>>
>> On Fri, Aug 4, 2023 at 10:43 PM Justin Mclean 
>> wrote:
>>
>>> Hi,
>>>
>>> -1 (binding) as well as the Category X license issues with the binaries,
>>> LICENSE is missing a 3rd party licenses which may not be compatible with
>>> the ALv2.
>>>
>>> Note that the font and NOTICE file issue have been brought up before.
>>>
>>> I checked:
>>> - incubating in name
>>> - signatures and hashes are correct
>>> - LICENSE is missing LICENSE for [1][2] however the standard license is
>>> not compatible with the ALv2 one [3]. How is this licensed?
>>> - NOTICE is OK, but please do not use "Copyright 2018 and onwards”.
>>> - you may wan to update your copyright in [4]
>>> - all files have ASF headers
>>> - no unexpected binary file
>>> - can compile from source
>>>
>>> Kind Regards,
>>> Justin
>>>
>>> 1.
>>> ./server/src/main/resources/org/apache/livy/server/ui/static/fonts/glyphicons-halflings-regular.*
>>> 2.
>>> ./docs/assets/themes/apache/bootstrap/fonts/glyphicons-halflings-regular.*
>>> 3. https://www.glyphicons.com/license/
>>> 4. ./docs/_includes/themes/apache/footer.html
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>>

Re: [VOTE] Release Apache Livy 0.8.0-incubating (RC1)

[larry mccay]

Okay. Last release was a different group of people. Doesn't seem terribly
reasonable but, @dac...@apache.org  - it seems that we
need to pull those JIRA into 0.8.0 and spin a new RC.

On Tue, Aug 8, 2023, 11:19 PM  wrote:

> Hi,
>
> These issues were mentioned in the last release; generally, things like
> that should be fixed by the next release. The license and Category X
> dependencies are serious issues and do need to be looked into.
>
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Livy 0.8.0-incubating (RC2)

[larry mccay]

Carrying over my vote: +1 (binding)


On Thu, Oct 5, 2023 at 1:23 PM PJ Fanning  wrote:

> +1 (binding)
>
> I checked
> * checksums and signatures
> * DISCLAIMER, LICENSE, NOTICE, THIRD-PARTY files exist
> * ASF headers in source files
> * source builds
>
> I still think improvements can be made to the THIRD-PARTY file to
> remove refs to jars that do not appear in the binary zips.
>
> On Thu, 5 Oct 2023 at 12:17, Jean-Baptiste Onofré  wrote:
> >
> > +1 (binding)
> >
> > Casting my vote here.
> >
> > Regards
> > JB
> >
> > Le mer. 4 oct. 2023 à 19:25, Damon Cortesi  a écrit :
> >
> > > Hello Incubator Community,
> > >
> > > The Apache Livy has recently been working on reviving the Livy project
> and
> > > would like to call for a vote to release Apache Livy(Incubating)
> version
> > > 0.8.0-incubating-rc2.
> > >
> > > Notable changes from RC1 include removing Category X licenses where
> > > possible and opting for the more permissive license for dual-licensed
> > > dependencies.
> > >
> > > We now kindly request the Incubator PMC members review and vote on this
> > > incubator release.
> > >
> > > Community vote thread:
> > > • https://lists.apache.org/thread/hzvbwtx4khdyll21owsnwr45v5l4d6wj
> > >
> > > Vote result thread:
> > > • https://lists.apache.org/thread/20ghfpgdvos6mvrzrkk287pp4gb1zzdf
> > >
> > > The release candidate:
> > > •
> > >
> https://dist.apache.org/repos/dist/dev/incubator/livy/0.8.0-incubating-rc2
> > >
> > > Git tag for the release:
> > > •
> > >
> https://github.com/apache/incubator-livy/releases/tag/v0.8.0-incubating-rc2
> > >
> > >
> > > Public keys file:
> > > • https://dist.apache.org/repos/dist/dev/incubator/livy/KEYS
> > >
> > > The change log is available in:
> > > •
> > >
> > >
> https://github.com/apache/incubator-livy/compare/v0.7.1-incubating-rc1...v0.8.0-incubating-rc2
> > >
> > > Dev instructions:
> > > • https://github.com/apache/incubator-livy/tree/master/dev/docker
> > >
> > > The vote will be open for at least 72 hours or until the necessary
> number
> > > of votes are reached.
> > >
> > > Please vote accordingly:
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Thanks,
> > > Damon Cortesi
> > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [ANNOUNCE] Apache Livy (incubating) 0.8.0 released

[larry mccay]

+annou...@apache.org  +annou...@hadoop.apache.org
 +general@incubator.apache.org


On Tue, Oct 10, 2023 at 2:34 PM Damon Cortesi  wrote:

> Hi folks,
>
> After a long hiatus, The Apache Livy team is proud to announce the release
> of Apache Livy
> 0.8.0-incubating.
>
> Livy is a web service that exposes a REST interface for managing long
> running Apache Spark contexts in your cluster. Livy enables
> programmatic, fault-tolerant, multi-tenant submission of Spark jobs.
> So, multiple users can interact with your Spark cluster concurrently and
> reliably.
>
> Download links: https://livy.apache.org/download/
>
> Release Notes: http://livy.apache.org/history/
>
> Website: http://livy.apache.org/
>
> Issues: https://issues.apache.org/jira/projects/LIVY/issues
>
> Mailing list: d...@livy.apache.org
>
> Jars are published to Maven Central using the groupId: org.apache.livy
>
> Thanks to everyone who participated in the development and release!
>
> Apache Livy (Incubating) Team
>
> =
> *Disclaimer*
>
> Apache Livy (incubating) is an effort undergoing incubation at The
> Apache Software Foundation (ASF), sponsored by the name of Apache
> Incubator PMC. Incubation is required of all newly accepted projects
> until a further review indicates that the infrastructure,
> communications, and decision making process have
> stabilized in a manner consistent with other successful ASF projects.
> While incubation status is not necessarily a reflection of the
> completeness or stability of the code, it does indicate that the
> project has yet to be fully endorsed by the ASF.
>

Re: [DISCUSS] OneTable proposal

[larry mccay]

Interesting.
I am available as a mentor if you are interested.


On Thu, Dec 7, 2023 at 5:30 PM PJ Fanning  wrote:

> Hi Ismaël,
> Could you make a request to join the Incubator PMC? ASF members will
> be accepted into the PMC. It's just that podling mentors need to be
> part of the PMC.
> Requests are made to the priv...@incubator.apache.org list.
>
> Regards,
> PJ
>
> On Thu, 7 Dec 2023 at 23:20, Ismaël Mejía  wrote:
> >
> > Hello Jesus,
> >
> > I am interested on both contributing to this project as a committer, and
> as
> > an ASF member I want to volunteer to mentor the project during
> incubation.
> > I am a committer and part of the PMC of both Apache Beam and Apache Avro
> so
> > I am close to this space so glad to help where I can.
> >
> > Regards,
> > Ismaël
> >
> >
> > On Mon, Dec 4, 2023 at 10:24 PM Jesus Camacho Rodriguez <
> jcama...@apache.org>
> > wrote:
> >
> > > Hi All,
> > >
> > > I would like to propose a new project to the ASF incubator - OneTable.
> > >
> > > OneTable[1] is an omni-directional converter for table formats that
> > > facilitates interoperability across data processing systems and query
> > > engines. Currently, OneTable supports widely adopted open-source table
> > > formats such as Apache Hudi, Apache Iceberg, and Delta Lake.
> > >
> > > Here is the proposal -
> > >
> https://cwiki.apache.org/confluence/display/INCUBATOR/OneTable+Proposal
> > >
> > > I would be the Champion of the project. I will mentor and help the
> project
> > > through the incubator with Hitesh Shah [hit...@apache.org], Stamatis
> > > Zampetakis [zabe...@apache.org], and Jean-Baptiste Onofré [
> > > jbono...@apache.org].
> > >
> > > We are looking forward to your feedback!
> > >
> > > Thanks,
> > > Jesús
> > >
> > > [1] https://github.com/onetable-io/onetable
> > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept XTable into the ASF Incubator

[larry mccay]

+1 (binding)


On Sun, Dec 17, 2023 at 11:32 PM Rakesh Radhakrishnan 
wrote:

> +1 (non-binding)
>
> I'm contributing to the Apache Hadoop project and mentoring Hive
> contributors in my company. It's a great initiative. The project looks
> interesting to me and can be really useful to the ecosystem.
>
> Thanks,
> Rakesh
>
> On Sat, Dec 16, 2023 at 9:48 AM Jesus Camacho Rodriguez <
> jcama...@apache.org>
> wrote:
>
> > Hi All,
> >
> > Following the discussion in the incubator mailing list [1], I am starting
> > this official vote for the XTable project.
> >
> > Here is the proposal -
> > https://cwiki.apache.org/confluence/display/INCUBATOR/XTable+Proposal
> >
> > Please cast your vote:
> >
> > [ ] +1, bring XTable into the Incubator
> > [ ] +0, I don't care either way
> > [ ] -1, do not bring XTable into the Incubator, because...
> >
> > This majority vote is open for at least 96 hours (due to the weekend).
> >
> > Only votes from Incubator PMC members are binding, but other votes are
> > welcome!
> >
> > Thanks,
> > Jesús
> >
> > [1] https://lists.apache.org/thread/rx9z8ffrf37qjhpkf1vp5rqg5lhht7jm
> >
>

Re: [VOTE] Drop the incubator- prefix for podling's GitHub repo name

[larry mccay]

+1 binding

Can't we move the indicator to the About section where it says Mirror of
(project name).
Extend that to include Under Incubation as well.

On Wed, May 8, 2024 at 10:53 AM Daniel Gruno  wrote:

> On 5/8/24 09:45, sebb wrote:
> > On Wed, 8 May 2024 at 15:15, Daniel Gruno  wrote:
> >>
> >> On 5/8/24 03:20, Sheng Wu wrote:
> >>> sebb  于2024年5月8日周三 16:12写道：
> 
>  Remember that the purpose of the incubator prefix is to clearly signal
>  that the code is under Incubation.
> 
>  It is essential that this change does not result in losing this
> indication.
> 
>  AFAICT, for most podlings, dropping the incubator prefix will require
>  additional work to ensure that the Incubation status is clear to
>  users,
>  and will require additional work by the IPMC to ensure that podlings
>  adequately display the Incubation status for each repository.
> >>>
> >>> Can't agree more on this.
> >>> In this vote proposal, we implicitly add many more checks for IPMC,
> >>> and lead more potential arguments about whether the incubating status
> >>> indicator is clear enough.
> >>> We are making IPMC pay the price in the future by removing a simple
> >>> GitHub supported operation.
> >>>
> >>> On second thought, I am changing my vote to -1 binding.
> >>
> >> This seems to point at more systemic failings of the IPMC if we are
> >> relying on the incubator- repository prefix for denoting podlings. I'll
> >> note that, as far as I can tell, the original reason for the incubator
> >> prefix was that of a technical limitation with the incubator, and
> >> shouldn't (imho) be used as a crutch for failings elsewhere in the
> >> branding of podlings.
> >
> > It's not a crutch if the naming convention satisfies the requirement;
> > it's just another way of doing it.
> >
> >> I am +1 (binding) on dropping the prefix myself. Incubation notices
> >> should be handled during releases, and on the official podling website.
> >
> > IMO Incubation status needs to be made clear from the very start.
> > It is not something that can be left until later.
>
> *We* know what incubation means, and *we* know what the incubator-
> prefix denotes. Does the general public have any clue? Does the prefix
> matter to the end user?
>
> I know the prefix requires additional work from the projects and infra
> upon graduation, which is a tangible downside. Is there a tangible
> upside to the prefix, empirically speaking?
>
> >
> >>>
> 
> 
>  On Wed, 8 May 2024 at 08:30, alin.jerpe...@sony.com
>   wrote:
> >
> > +1 (non binding)
> >
> > from my experience will make the documentation and releases easy to
> migrate after graduation
> >
> > Best regards
> > Alin
> > 
> > Från: hulk 
> > Skickat: den 8 maj 2024 09:06
> > Till: general@incubator.apache.org 
> > Ämne: Re: [VOTE] Drop the incubator- prefix for podling's GitHub
> repo name
> >
> > -0 (binding) On Wed, 8 May 2024 at 13: 58, Richard Zowalla  zowalla. com> wrote: > -0 (binding) > > (I like the prefix) > > Am 8. Mai
> 2024 07: 41: 16 MESZ schrieb Sheng Wu : >
> >-0
> > ZjQcmQRYFpfptBannerStart
> > Caution : This email originated from outside of Sony.
> > Do not click links or open any attachments unless you recognize the
> sender and know the content is safe. Please report phishing if unsure.
> >
> > ZjQcmQRYFpfptBannerEnd
> >
> > -0 (binding)
> >
> > On Wed, 8 May 2024 at 13:58, Richard Zowalla 
> wrote:
> >
> >> -0 (binding)
> >>
> >> (I like the prefix)
> >>
> >> Am 8. Mai 2024 07:41:16 MESZ schrieb Sheng Wu <
> wu.sheng.841...@gmail.com>:
> >>> -0 binding
> >>>
> >>> Sheng Wu 吴晟
> >>> Twitter, wusheng1108
> >>>
> >>> Dave Fisher  于2024年5月8日周三 12:16写道：
> 
>  +0 (binding) wave
> 
> > On May 7, 2024, at 5:34 PM, Francis Chuang <
> francischu...@apache.org>
> >> wrote:
> >
> > +1 (binding)
> >
> > I think this is a pragmatic and well-thought out approach.
> >
> > Francis
> >
> > On 8/05/2024 10:31 am, tison wrote:
> >> Hi,
> >> Following the discussion thread [1], I'd start a vote on the
> >> following
> >> proposals:
> >> 1. Establish a consensus to allow and finally converge podling's
> >> GitHub repo to
> >> have a name without the incubator- prefix.
> >> 2. Allow existing ongoing podlings to ask the INFRA to drop
> their
> >> incubator- prefix by now, not MUST during the graduation.
> >> 3. Update the docs on incubator.apache.org everywhere if the
> >> description
> >> can conflict with this consensus.
> >> 4. Update the docs on incubator.apache.org to guide how to
> describe
> >> podling's incubating status on the GitHub repo (namely,
> including
> >> "incubating" i

Re: [DISCUSS] GravitinoProposal to the incubator

[larry mccay]

Looks interesting to me.
I would be willing to be an additional mentor or join the initial set of
team members if there is interest.

+1

On Thu, May 23, 2024 at 11:21 AM Charles Zhang 
wrote:

> +1
> It looks like a good project with many application scenarios.
>
> Best wishes,
> Charles Zhang
> from Apache InLong
>
>
> tison  于2024年5月23日周四 23:08写道：
>
> > +1 looks promising and I believe this initial group and the mentors :D
> >
> > Best,
> > tison.
> >
> >
> > 俊平堵  于2024年5月23日周四 22:53写道：
> >
> > > +1. Thanks JB for the proposal.
> > > Unified Data Catalog is more and more important in the data and AI
> > domain.
> > > Project gravitino should be the first one in ASF to address this area.
> > > The project is very active and has outstanding contributors from
> > different
> > > organizations and companies.
> > > Glad to see it joins the ASF family and grows the community by
> following
> > > the Apache way. :)
> > >
> > > Thanks,
> > >
> > > JP
> > >
> > > Jean-Baptiste Onofré  于2024年5月23日周四 13:08写道：
> > >
> > > > Hi folks,
> > > >
> > > > We would like to propose a new project to the ASF incubator:
> Gravitino.
> > > >
> > > > Gravitino is a high-performance, geo-distributed, and federated
> > > > metadata lake designed to manage metadata seamlessly across diverse
> > > > data sources, vendors, and regions. Its primary goal is to provide
> > > > users with unified metadata access for both data and AI assets.
> > > >
> > > > Here is the proposal:
> > > >
> > https://cwiki.apache.org/confluence/display/INCUBATOR/GravitinoProposal
> > > >
> > > > Comments and feedback are welcome.
> > > >
> > > > Thanks !
> > > > Regards
> > > > JB
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Accept Gravitino into the ASF Incubator

[larry mccay]

+1 (binding)

On Wed, May 29, 2024 at 1:33 PM Weiwei Yang  wrote:

> +1
>
> On Wed, May 29, 2024 at 8:59 AM Jean-Baptiste Onofré 
> wrote:
>
> > Sorry, the links have not been pasted correctly:
> >
> > Here's the discussion:
> > https://lists.apache.org/thread/5bp5t0hgq2c419m62m2zt71jkv8bhhho
> >
> > And the proposal:
> > https://cwiki.apache.org/confluence/display/INCUBATOR/GravitinoProposal
> >
> > Regards
> > JB
> >
> > On Wed, May 29, 2024 at 5:31 PM Jean-Baptiste Onofré 
> > wrote:
> > >
> > > Hi folks,
> > >
> > > Following the discussion about Gravitino [1], I would like to start
> > > the formal vote to accept Gravitino into the ASF Incubator.
> > >
> > >  As reminder, this is the Gravitino Proposal:
> > >
> > > Please cast your vote:
> > >
> > > [ ] +1, accept Gravitino into the ASF Incubator
> > > [ ] 0, I don't care either way
> > > [ ] -1, do not accept Gravitino into the ASF Incubator, because ...
> > >
> > > The vote will run for one week starting from today.
> > >
> > > Thanks !
> > >
> > > Regards
> > > JB
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [PROPOSAL] New blockchain project: Cava

[larry mccay]

+1

I would also be interested in being involved as an initial committer for
this.

thanks,

--larry
Apache Knox, PMC Chair

On Tue, Feb 5, 2019 at 5:47 PM Selvamohan Neethiraj 
wrote:

> +1
>
> Love to be part of this incubation project …..
>
> Thanks,
> Selva-
> Apache Ranger, PMC Chair
>
> > On Feb 5, 2019, at 5:42 PM, Antoine Toulme  wrote:
> >
> > Hi all,
> >
> > We’d like to start a conversation around a new proposal for a set of
> Java-based blockchain project.
> >
> > I have written a proposal available here, and reproduced below:
> https://wiki.apache.org/incubator/CavaProposal <
> https://wiki.apache.org/incubator/CavaProposal>
> >
> > At this time, we have a champion, Jim Jagielski (thanks Jim), and would
> like to recruit additional developers and mentors.
> >
> > We have deliberately left room on the project charter to engage openly
> with the community. That said, we would start the project with code coming
> from ConsenSys, and we will recruit developers from there and elsewhere
> actively.
> >
> > The goal of this thread is engage with the community and gather interest
> for participation in the project. Please let us know what you think!
> >
> > Cheers,
> >
> > Antoine Toulme
> >
> > == Abstract ==
> > Cava is a set of libraries and other tools to aid development of
> blockchain and other decentralized software in Java and other JVM languages.
> >
> > Please note: Cava is a contraction of "ConsenSys Java". The community
> should consider an alternate name.
> >
> > = Proposal =
> >
> > Cava is a set of libraries and other tools to aid development of
> blockchain and other decentralized software in Java and other JVM languages.
> > It includes a low-level bytes library, serialization and deserialization
> codecs (e.g. RLP), various cryptography functions and primatives, and lots
> of other helpful utilities.
> > Cava is developed for JDK 1.8 or higher, and depends on various other
> FOSS libraries.
> >
> > === Background ===
> >
> > Cava was built as an open source project from the grounds up to
> accelerate the maturation of the blockchain ecosystem, particularly in
> relation with enterprise products predominantly built in Java.
> > Cava is used by several products today: Orion, Pantheon, and Artemis
> from Pegasys.
> >
> > Cava libraries are also used in various experiments regarding
> scalability, such as Canto.
> >
> > Several other community members would want to leverage Cava and would
> benefit from working directly on the project outside of the influence of
> the original corporate sponsor, ConsenSys.
> >
> > === Rationale ===
> >
> > Cava is organized as set of libraries that form the basis of most
> blockchain, distributed ledgers or cryptography work.
> >
> > Most of the work built for Cava was meant for Ethereum, but can be
> reused across other blockchain technologies.
> >
> > There is a need for blockchain implementors to use well trusted,
> production-ready software to bootstrap their efforts.
> >
> > === Initial Goals ===
> >
> > The goal is to form a community of developers and adopters who will be
> able to collaborate openly around blockchain technologies and mature
> frameworks
> > to reduce risk when implementing blockain-related projects.
> >
> > === Current Status ===
> >
> > The project is well established and counts 2 active committers. Some
> contributions were made from the community.
> >
> > The project has made several releases, distributed through Maven
> Central, with GPG signatures and proper Maven metadata published.
> >
> > '''Meritocracy:'''
> >
> > Active discussions on github issues and PRs has helped identify new
> possible commiters.
> >
> > Our main goal, moving to Apache is to promote our project as a
> meritocracy under the guideline of the Apache Way to help foster a
> community around our efforts.
> >
> > * '''Community:'''
> >
> > Blockchain protocol developers organize well in communities, and some
> lively discussions take place over Twitter, Gitter, Telegram.
> >
> > We would like to create a community for dedicated Java developers to
> contribute to the blockchain space.
> >
> > We currently have a little activity through the channels mentioned
> above, but no channel dedicated specifically to Cava is seeing a lot of
> traction.
> >
> > * '''Core Developers:'''
> >
> > Cava was built by two developers with a long experience in open source
> work. Both lead separate open source projects.
> > One of the developers is the PMC Chair for Apache Buildr and a committer
> for Apache ODE.
> >
> > * '''Alignment:'''
> >
> > We believe there isn't a blockchain TLP for Java at Apache at this time
> and would like to participate in establishing a presence in that domain of
> expertise.
> >
> > We would rely and integrate closely with a number of projects hosted by
> the ASF such as Apache Camel.
> >
> > '''Known Risks'''
> >
> > * '''Orphaned products''':
> >
> > The contributors are committed to the development of the blockchain
> space and are employed 

Re: [VOTE] Accept Cava into the Apache Incubator

[larry mccay]

+1

On Wed, Feb 20, 2019 at 8:33 PM Byung-Gon Chun  wrote:

> +1 (binding)
>
> On Thu, Feb 21, 2019 at 5:20 AM Dave Fisher  wrote:
>
> > +1 (binding)
> >
> > Looking forward to this podling!
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Feb 20, 2019, at 11:50 AM, Antoine Toulme 
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > we've discussed the proposal for the Cava project in [1] and [2]. The
> > > proposal itself can be found on the wiki[3].
> > >
> > > We discussed how to go about finding a suitable name for the project in
> > [2].
> > > I will kick off a vote to pick a name based on the proposals made
> there.
> > >
> > > According to the Incubator rules[4] I'd like to call a vote to accept
> the
> > > new "Cava" project as a podling in the Apache Incubator.
> > >
> > > A vote for accepting a new Apache Incubator podling is a majority vote.
> > > Everyone is welcome to vote, only Incubator PMC member votes are
> binding.
> > > It would be helpful (but not required) if you could add a comment
> stating
> > > whether your vote is binding or non-binding.
> > >
> > > This vote will run for at least 72 hours (but I expect to keep it open
> > for
> > > longer). Please VOTE as follows:
> > >
> > > [ ] +1 Accept Cava into the Apache Incubator
> > > [ ] +0 Abstain
> > > [ ] -1 Do not accept Cava into the Apache Incubator because ...
> > >
> > > Thank you for everyone who decided to join in in the past discussions!
> > > Antoine
> > >
> > > [1]:
> >
> https://lists.apache.org/thread.html/5a7f6a218b11a1cac61fbd53f4c995fd7716f8ad3751cf9f171ebd57@%3Cgeneral.incubator.apache.org%3E
> > > [2]:
> >
> https://lists.apache.org/thread.html/8d8014f53f140a3ccdd517c3c303de1d45cc04afdaee5961ac43e7fc@%3Cgeneral.incubator.apache.org%3E
> > > [3]:
> https://wiki.apache.org/incubator/CavaProposal?action=recall&rev=14
> > > [4]: https://incubator.apache.org/guides/proposal.html#the_vote
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> --
> Byung-Gon Chun
>

Re: [Cava] Suitable name search - choosing a name

[larry mccay]

Apache Avac ???


On Wed, Mar 20, 2019 at 7:57 PM Antoine Toulme  wrote:

> There exists an outis open source project.
>
> Maybe we can riff on this name though.
>
> > On Mar 20, 2019, at 11:39, Kenneth Knowles  wrote:
> >
> > Indeed, http://nemo.apache.org/
> >
> > So I looked for similar ideas and came to Outis [2] via [1].
> >
> > Kenn
> >
> > [1] https://en.wikipedia.org/wiki/Captain_Nemo#Etymology
> > [2] https://en.wikipedia.org/wiki/Outis
> >
> > On Wed, Mar 20, 2019 at 11:27 AM Anu Engineer  >
> > wrote:
> >
> >> At this point you should call it “Apache Nemo” or literally Apache No
> One
> >> (, to indicate we have no affiliations or does not violate any
> trademarks
> >> or claims.
> >> --Anu
> >>
> >> Just kidding, eventually I am sure you will find a good name, -- that no
> >> one else has thought off.
> >>
> >>
> >> On 3/20/19, 10:51 AM, "Antoine Toulme"  wrote:
> >>
> >>Deep sigh.
> >>
> >>OK.
> >>
> >>> On Mar 20, 2019, at 9:15 AM, Michael Wall  wrote:
> >>>
> >>> I did find this, https://github.com/RainBlock.  Looks like code
> >> around
> >>> ethereum.  Maybe too close?
> >>>
> >>> On Wed, Mar 20, 2019 at 11:59 AM Antoine Toulme 
> >> wrote:
> >>>
>  Yes, you’ve been very flexible, thank you.
> 
>  Anybody with strong opinions, please chime in.
> 
>  I’ll start looking for marks around rainblock.
> 
> > On Mar 20, 2019, at 5:15 AM, Jim Jagielski 
> >> wrote:
> >
> > Personally, I'm fine w/ anything...
> >
> >> On Mar 19, 2019, at 6:53 PM, Antoine Toulme 
>  wrote:
> >>
> >> I think we will need a made up name, and we likely need a name
> >> that is
>  rather unambiguous across languages.
> >>
> >> Based on our previous proposals, would you be ok with “RainBlock”?
> >>
> >>
> >>> On Mar 19, 2019, at 11:40 AM, Jim Jagielski 
> >> wrote:
> >>>
> >>> Apache PawPaw
> >>>
>  On Mar 19, 2019, at 9:58 AM, Michael Wall 
> >> wrote:
> 
>  Since Cava is the Guava for blockchains, what about sticking
> >> with the
>  fruit/veggie theme?
> 
>  Jackfruit
>  Jambolan
>  Jocote
>  Kumquat
>  KangKong
>  Kabosu
> 
>  I also saw the word postcava which is the "the inferior vena
> >> cava of
>  vertebrates higher than fishes" according to
>  https://www.merriam-webster.com/dictionary/postcava.  But is
> >> seemed
>  like a
>  name you could use after Cava.
> 
>  Just brainstorming.
> 
>  Mike
> 
> 
> 
>  On Tue, Mar 19, 2019 at 8:19 AM Jim Jagielski 
>  wrote:
> 
> > What is somewhat funny is that the "SkyWalking" podling is on
> >> the
>  cusp of
> > graduation. :)
> >
> >> On Mar 19, 2019, at 1:42 AM, Antoine Toulme <
> >> anto...@toulme.name>
>  wrote:
> >>
> >> All, the results are in, from VP Legal:
> >>> I am happy to approve the name in isolation. Specifically,
> >> the
> > community must refrain from linking the project to any Star
> >> Wars
> > references. The view of the community is that the community is
>  likely to
> > find that difficult. It was therefore agreed to look for a
> >> different
>  name.
> >>
> >> We need to pick another name.
> >>
> >>> On Mar 4, 2019, at 2:32 PM, Dave Fisher <
> >> dave2w...@comcast.net>
>  wrote:
> >>>
> >>> Hi -
> >>>
>  On Mar 4, 2019, at 2:10 PM, Antoine Toulme <
> >> anto...@toulme.name>
> > wrote:
> 
> 
> 
> > On Mar 4, 2019, at 2:00 PM, Dave Fisher <
> >> dave2w...@comcast.net>
> > wrote:
> >
> > Hi -
> >
> > I went to look at the Trademark name search and something
> >> is
>  either
> > messed up or autocorrected.
> >
> > PODLINGNAMESEARCH-165 <
> > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-165
> > Establish
> > whether "Apache Obiwarn" is a Suitable Name
> >
> > Isn’t the name supposed to be Obiwan and not Obiwarn?
>  No, the name is Obiwarn. With a r.
> >>>
> >>> Well, my bad eye sight had my brain auto-correcting to what I
>  expected
> > to see. Then Daniel wrote what he did.
> >>>
> >>> OK. Let’s look into Obiwarn and deal with Apple
> >> autocorrecting it
>  to
> > Obiwan … more Jedi mind tricks.
> >>>
> >>> Regards,
> >>> Dave
> >>>
> >
> > Please look into it. Sorry, color me confused.
> >
> > Regards,
> > Dave
> >
> >> On Mar 4, 2019, at 12:20 PM, Jim Jagielski
> >> 
>  wrote:
> >>
>