Shepherding: celix, stratosphere
Celix looks pretty normal; report in getting prepeared, traffic on mailing list is ok. I don't see any particular cause for concern. Celix might need to update the project site to reflect recent additions of the committers. Stratosphere dev list look pretty good, traffic is high and mentors participation is there. signature.asc Description: Digital signature
Re: [RESULT][VOTE] Accept Slider into the incubator
On Tue, Apr 29, 2014 at 10:50AM, Steve Loughran wrote: > On 28 April 2014 19:19, Roman Shaposhnik wrote: > > > On Mon, Apr 28, 2014 at 11:18 AM, Henry Saputra > > wrote: > > > Congrats and welcome to ASF incubator guys! > > > > Indeed! Best of luck growing your community and project! > > > > Thanks, > > Roman. > > > > > thx, I'll hope to submit stuff into bigtop when possible. The first one That be a great starting contribution to the Bigtop project! We are looking forward to it! Cos > there is some convenience & diagnostics stuff in our command shell code > that should be pushed up into its superclass to help others: > > https://github.com/hortonworks/slider/blob/develop/slider-funtest/src/main/groovy/org/apache/hoya/funtest/framework/SliderShell.groovy > > > > > > - > > 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. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Board Report Reminder
Interesting, looks like I got to shepherd a graduated project ;) Henry, let me know if you need any help with clearing out the situation. Regards, Cos On Sat, Jun 07, 2014 at 10:36AM, Henry Saputra wrote: > Hi John, > > Tajo already graduated to TLP. > > Does the project miss some post graduation task to be removed from > reporting schedule? > > Thanks, > > Henry > > On Saturday, June 7, 2014, John D. Ament wrote: > > > Hi all > > > > Don't forget, board reports were due on June 04. Shepherd reports are > > due tomorrow. > > > > The following podlings are considered to not have reported this month, > > thus far: > > > > Brooklyn > > DeviceMap > > Drill > > Kalumet > > MRQL > > S4 > > Sentry > > Tajo > > > > John > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > signature.asc Description: Digital signature
Re: Board Report Reminder
I am going to post my Drill Shepherd review to the June2014 page in a moment, but I wanted to reflect here that Drill project didn't reported after I have nudged them on the dev@ list and Ted Dunning forwarded the reminder from the board. Cos On Sat, Jun 07, 2014 at 10:50AM, John D. Ament wrote: > Hi all > > Don't forget, board reports were due on June 04. Shepherd reports are > due tomorrow. > > The following podlings are considered to not have reported this month, thus > far: > > Brooklyn > DeviceMap > Drill > Kalumet > MRQL > S4 > Sentry > Tajo > > John > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: Board Report Reminder
Thanks Henry! In the meanwhile I have removed the project from june2014 wiki report page. On Sun, Jun 08, 2014 at 02:56PM, Henry Saputra wrote: > Cos, I will follow up with the post graduation steps that Tajo missed > > On Sunday, June 8, 2014, Konstantin Boudnik wrote: > > > Interesting, looks like I got to shepherd a graduated project ;) Henry, > > let me > > know if you need any help with clearing out the situation. > > > > Regards, > > Cos > > > > On Sat, Jun 07, 2014 at 10:36AM, Henry Saputra wrote: > > > Hi John, > > > > > > Tajo already graduated to TLP. > > > > > > Does the project miss some post graduation task to be removed from > > > reporting schedule? > > > > > > Thanks, > > > > > > Henry > > > > > > On Saturday, June 7, 2014, John D. Ament > > wrote: > > > > > > > Hi all > > > > > > > > Don't forget, board reports were due on June 04. Shepherd reports are > > > > due tomorrow. > > > > > > > > The following podlings are considered to not have reported this month, > > > > thus far: > > > > > > > > Brooklyn > > > > DeviceMap > > > > Drill > > > > Kalumet > > > > MRQL > > > > S4 > > > > Sentry > > > > Tajo > > > > > > > > John > > > > > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > > > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > signature.asc Description: Digital signature
Re: [PROPOSAL] fleece as an incubator project
A small clarification point: is the intention of the project to essentially implement the functionality of Groovy's JsonSlurper? http://groovy.codehaus.org/gapi/groovy/json/JsonSlurper.html for the reference Thanks, Cos On Tue, Jun 03, 2014 at 08:40PM, Romain Manni-Bucau wrote: > Hi guys, > > To follow the incubator process and after the previous discuss thread here > is the formal proposal mail. > > Feel free to comment it! > > > > Apache Fleece Proposal > > Abstract > > Apache Fleece is an implementation of JSR-353 (JavaTM API for JSON > Processing). > > Proposal > > Apache Fleece will consist of a number of modules. Mainly an implementation > of JSR-353 but also a set of usefule modules to help with the usage of > JSR-353 (surely a mapping module and a jaxrs provider module). > > Background > > JSon being more and more important JavaEE 7 specified an API to read and > create JSon objects/arrays. > > Apache Fleece builds on this specification a potential base to do Json at > Apache (hopefully it will be integrated with CXF for instance). > > Rationale > > There is not yet a Json related project at Apache but a lot of projects > rely on some specific implementions (jettison, jackson, others...). > Proposing a default would be great. The other point is a set of Apache > projects related to JavaEE (CXF, TomEE, Geronimo, Axis2...) will need an > implementation. Having one built at Apache is a really nice to have. > > Initial Goals > > The initial goal of the Apache Fleece project is to get a JSR-353 compliant > implementation > > Current Status > > Initial codebase was developped on github but designed to be integrated in > Apache. > > Meritocracy > > Initial community will be mainly composed of already Apache committers so > meritocracy is already something well known. > > Community > > Initial community will be composed of TomEE community for sure, hopefully > CXF and potentially all JSon users of Apache. > > Initial committers > >- Romain Manni-Bucau (individual, ASF) >- Jean-Louis Monteiro (individual, ASF) >- Mark Struberg (individual, ASF member) >- Gerhard Petracek (individual, ASF member) >- David Blevins (individual, ASF member) >- Sagara Gunathunga (ASF) > > Alignment > > Several Apache project will need a JSR-353 implementation. Having a project > which can be shared is better than having a sub project of a particular > project. Moreover this project makes sense "alone" since users can > integrate it without any other dependencies and use it to read/generate > Json in their project so it makes sense to create a dedicated project. > > Known Risks > > Main risk is to get a not so active project since the specification is not > that big. > > Documentation > > There is no documentation to import today but it will be created using > standard ASF tools (ASF CMS mainly). > > Initial Source > > Initial sources are on this git repository: > https://github.com/rmannibucau/json-impl.git > > Source and IP Submission Plan > > Initial sources are under Apache license v2. > > Side note: it was really developed to be integrated in this project > (without waiting it to be created). > > Required Resources > > Mailing Lists > >- > >fleece-us...@incubator.apache.org >- > >fleece-...@incubator.apache.org >- > >fleece-comm...@incubator.apache.org >- > >fleece-priv...@incubator.apache.org > > Version Control > > It is proposed that the source code for the Apache Fleece project be hosted > in the Apache Git repository, under the following directory: > >- incubator/fleece/ > > Issue Tracking > > The following JIRA project would be required to track issues for the Apache > Fleece project: > >- FLEECE > > Initial Committers > >- Romain Manni-Bucau >- Jean-Louis Monteiro >- Mark Struberg >- Gerhard Petracek >- David Blevins > > Sponsors > > Champion > >- Mark Struberg > > Nominated Mentors > >- Justin Mclean >- Christian Grobmeier >- Daniel Kulp > > Project Name > > Seems *Fleece* is the name which satisfies most of people but we can still > ask for a new name if we feel it needed before being graduated. > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherding Summary - June 2014
On Sun, Jun 08, 2014 at 08:43PM, John D. Ament wrote: > Hi all > > See below for the shepherd reports. I've put some additional comments in. > > Drill/Konstantin Boudnik > > Shepherd/Mentor notes: > > In the month of June the project's dev@ list was light on the traffc > - 86 msgs vs 1183 in May. Traffic consists mostly from the JIRA > notifications and review requests. I am not entirely sure what is the > cause of the lowest activity since the end of 2012. > > June report to the board hasn't been sent on time either. > > > Flink/Konstantin Boudnik > > Shepherd/Mentor notes: > > Mailing list in June is very light on the traffic and only covering > the topic of the project's name change. Some of the mentors are active > on the list and helping community. No visible issues. > > > Cos, > > > Thanks for both of these reports! Just to point out, the June report > covers 1/May - 31/May. We’re only 8 days into June… 86 msgs isn’t bad > for 8 days in :-) I'm not sure if you want to rephrase based on this, > I made the same mistake last month w/ the board report. You are right John - thanks for catching my mistake. I will amend my notes in a minute. > Kalumet/Justin Mclean > > > Shepherd/Mentor notes: > > Podling may be in a little trouble. Failed to report this month, mailing > > list traffic and commits at a very low level. A mentor is still active > > but looks likes like the last release candidate (October 2013) wasn't > > voted on by the IPMC and a new release candidate hasn't been created. > > Last report talked about graduation so perhaps they just need some help > > in getting past the final hurdle? > > > Justin, > > > Thanks for bringing this up. Since they’re moving to monthly, we’ll > monitor and see if things improve in the next couple of months. > > > Storm/John D. Ament > > Storm is showing a lot of progress and growth. They have a lot of > activity on JIRA and mailing lists, and are generally in good shape. > > > > Please be advised that the following podlings have not reported yet, > and will be moved to monthly: > > Brooklyn > > DeviceMap > > Drill > > Kalumet > > S4 > > - > 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] Graduate Apache Celix as TLP
I had an honor to shepherd Celix ones and I like the dynamics of it. I am sure the community will grow as the time goes. In my opinion, it worth moving it into TLP. I will be happy to help the project moving forward if my help is required. Cos On Tue, Jun 10, 2014 at 07:06AM, Alexander Broekhuis wrote: > Hi All, > > Since entering Incubation in November 2010, the Celix podling been working > towards graduation. The community has grown, releases have been made and > new committers have been added. > Over the last couple of months all items on the checklist for graduation > have been ticked of [1]. > This resulted in a, positive, vote on te dev list of Celix itself [2]. Also > the namesearch has been performed [3]. > As far as we can tell the project status is up to date [4], and Celix is > ready for graduation. > > This thread is to start the IPMC discussion for the graduation of Apache > Celix. The proposed resolution can be found at the bottom of this email. > > Any feedback is appreciated, and where needed we will any remaining issues > as soon as possible. > > Thanks in advance > > Alexander Broekhuis > (PPMC member of Apache Celix) > > [1]: http://incubator.apache.org/guides/graduation.html#checklist > [2]: http://markmail.org/thread/7y3a2l6qqm56cvud > [3]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-50 > [4]: http://incubator.apache.org/projects/celix.html > > > === Board Resolution == > > X. Establish the Apache Celix 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 native implementation of the OSGi >specification. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management >Committee (PMC), to be known as the "Apache Celix Project", >be and hereby is established pursuant to Bylaws of the >Foundation; and be it further > >RESOLVED, that the Apache Celix Project be and hereby is >responsible for the creation and maintenance of software >related to a native implementation of the OSGi >specification; >and be it further > >RESOLVED, that the office of "Vice President, Apache Celix" 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 Celix Project, and to have primary responsibility >for management of the projects within the scope of >responsibility of the Apache Celix 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 Celix Project: > > * Alexander Broekhuis > * Pepijn Noltes > * Bjoern Petri > * Erik Jansman > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alexander Broekhuis >be appointed to the office of Vice President, Apache Celix, 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 Celix 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 Celix Project; and be it further > >RESOLVED, that the Apache Celix Project be and hereby >is tasked with the migration and rationalization of the Apache >Incubator Celix podling; and be it further > >RESOLVED, that all responsibilities pertaining to the Apache >Incubator Celix podling encumbered upon the Apache Incubator >Project are hereafter discharged. > > -- > Met vriendelijke groet, > > Alexander Broekhuis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire the S4 podling
+1 (non-binding) On Fri, Jun 13, 2014 at 04:23PM, John D. Ament wrote: > +1 Please go ahead and retire from the incubator. (binding) > > On Fri, Jun 13, 2014 at 2:36 PM, Joe Brockmeier wrote: > > Hi all, > > > > Per recent discussions on general@[1] and s4-dev@ [2], I went ahead and > > called for a VOTE on the S4 dev@ mailing list [3] about retiring the > > podling. That VOTE has passed with no -1s and 4 (binding) +1s from the > > podling PMC/committers. (S4 only has committers, and doesn't distinguish > > between PPMC/committer.) > > > > We didn't get a weigh-in from all mentors/PPMC on the retirement VOTE, > > so I'm going ahead and asking for a vote here. > > > > This VOTE will be open for at least 72 hours. Please indicate (binding) > > or (non-binding) when casting your VOTE. > > > > +1 [ ] Yes, I am in favor of retiring S4 from the Apache Incubator. > > +0 [ ] > > -1 [ ] No, I am not in favor of retiring S4 because... > > > > Note that we have one IPMC vote from Patrick already. > > > > [1] http://s.apache.org/7Gz > > [2] http://s.apache.org/ig > > [3] http://s.apache.org/OAU > > -- > > Joe Brockmeier > > j...@zonker.net > > Twitter: @jzb > > http://www.dissociatedpress.net/ > > > > - > > 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: Request for mentor assessment
I share the sentiment with NPanday - doesn't seem like anything is happening there really. If it of an interest to the incubator, I will volunteer to help mentoring Tez. Cos On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote: > I think Tez needs some more help mentoring. I myself haven't had > as much time as possible so the more folks over there that can > help mentor the better. > > Good job starting this thread, Roman. > > > > > > > -Original Message- > From: Roman Shaposhnik > Reply-To: "general@incubator.apache.org" > Date: Thursday, June 12, 2014 5:44 PM > To: "general@incubator.apache.org" > Subject: Re: Request for mentor assessment > > >On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra > >wrote: > >> Seems like NPanday should go to attic. One mentor I asked did not even > >> monitor it anymore > > > >I've had exactly the same experience. My plan here is to wait for folks > >to chime in on this thread and for those mentors who are MiA start > >different threads asking for additional (replacement) mentors. > > > >I really would like for things like retirement proposals to come from > >somebody who's spent time getting to know the community in greater > >details. > > > >Thanks, > >Roman. > > > >- > >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: Request for mentor assessment
On Thu, Jun 12, 2014 at 11:31PM, Joe Brockmeier wrote: > On 06/12/2014 07:56 PM, Roman Shaposhnik wrote: > > This is one of the questions, I'd like to explore in greater details: are > > we comfortable with having "professional student" projects in the > > incubator? > > In response to the general question, it seems that "professional > student" podlings are inconsistent with the idea that the Incubator is a > process that should result in graduation or termination. > > > In the case of Wave, it really strikes me as odd that the community is not > > capable of even a single release in more than 3.5 years: > >http://incubator.apache.org/wave/downloads.html > > > > This suggests that ASF is being used as a GitHub of sorts. Are we > > comfortable > > with this? > > Speaking for myself, no. I'd be uncomfortable having a specific deadline > for graduation, but a podling that's not making progress towards > graduation (in general, not pointing a finger specifically at Wave here) > should be terminated. For what it worth, I think you're right: a permanent incubator project doesn't make sense. For once, there's a lot of people mechanics involved into podlings' mentoring, reporting, etc. And it doesn't feel exactly right to forever handhold something that doesn't have an intention to evolve. Cos - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
I want to concur on that. Say, in Bigtop that has Gradle build system, we aren't checking in the wrappers. Instead they are created in the build time, and consequently might be added into a binary assembly. Cos On Tue, Jun 10, 2014 at 07:23PM, Jake Farrell wrote: > Hey Jakob > We did run into this while packaging our first rc in Aurora. There was some > discussion around this on our dev list and we ended up removed the > gradle.jar and gradlew from the source dist and added the wrapper task to > build.gradle so it will always generate the same gradlew that we have > committed in our repo for dev use. We will be creating a binary dist to > accompany our source dist which will include the gradle.jar. This is > similar to how Ant and Maven generate packages for their releases. > > -Jake > > > > > On Tue, Jun 10, 2014 at 4:18 PM, Jakob Homan wrote: > > > We're currently working on the first release for Samza and have run into a > > problem involving the source release and our build system, Gradle. Both > > DataFu and Aurora use Gradle and will run into this issue as well when they > > do a source release. > > > > Gradle provides a wrapper script, gradlew that allows the end user to run > > all the usual build tools without having gradle itself installed on the > > system. This script and its required resources are intended to be checked > > [1] to the source control this. This is contrast to Ant or Maven, which > > require those tools to be pre-installed on the system before executing a > > build against a build.xml or pom.xml, respectively. However, for the > > gradlew script to work, it downloads the a version of the gradle jar and > > requires that jar to be checked in as well. Counterintuitively, a project > > using gradlew must be bootstrapped by an install with gradle installed, or > > have the result of that bootstrapping checked into the repo. > > > > The problem lies with the Release Check List [2], which prohibits the > > inclusion of jars in a source release. Under this rule we effectively > > can't use gradlew as our build system in that we can't distribute it > > (absent some hacky solution like us trying to download the script and jar > > ourselves. We'd obviously prefer to avoid this.) > > > > I'm thinking we should make an exception to this no-jar rule for the > > gradlew jar. The Gradle project is open source [3], Apache 2 licensed [4] > > and intends for this jar to be included as part of the source of projects > > [1]. Finally, the jar itself contains only Gradle-generated classes with > > no other code fat-jarred [5]. The gradlew wrapper actually makes it easier > > for users to get and play with our code as it removes the need for any > > particular version of Gradle to be availabe beforehand (it also hides much > > of the complexity of the rapidly evolving gradle spec). > > > > Thoughts? > > -Jakob > > > > > > [1] "The wrapper is something you should check into version control." > > http://www.gradle.org/docs/current/userguide/gradle_wrapper.html > > [2] "This package may not contain compiled components (such as "jar" files) > > because compiled components are not open source, even if they were built > > from open source." > > http://incubator.apache.org/guides/releasemanagement.html#check-list > > [3] https://github.com/gradle/gradle > > [4] http://www.gradle.org/license > > [5] https://gist.github.com/jghoman/42f683bd92c3599cdf26 > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request for mentor assessment
Sure Chris. I'll send an email to dev@ list offering help. Cos On Mon, Jun 16, 2014 at 06:54PM, Chris Douglas wrote: > Tez is ready to graduate. Cos, if you can help us manage that process, > it'd certainly be appreciated. -C > > On Mon, Jun 16, 2014 at 12:53 PM, Konstantin Boudnik wrote: > > I share the sentiment with NPanday - doesn't seem like anything is happening > > there really. > > > > If it of an interest to the incubator, I will volunteer to help mentoring > > Tez. > > > > Cos > > > > > > On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote: > >> I think Tez needs some more help mentoring. I myself haven't had > >> as much time as possible so the more folks over there that can > >> help mentor the better. > >> > >> Good job starting this thread, Roman. > >> > >> > >> > >> > >> > >> > >> -Original Message- > >> From: Roman Shaposhnik > >> Reply-To: "general@incubator.apache.org" > >> Date: Thursday, June 12, 2014 5:44 PM > >> To: "general@incubator.apache.org" > >> Subject: Re: Request for mentor assessment > >> > >> >On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra > >> >wrote: > >> >> Seems like NPanday should go to attic. One mentor I asked did not even > >> >> monitor it anymore > >> > > >> >I've had exactly the same experience. My plan here is to wait for folks > >> >to chime in on this thread and for those mentors who are MiA start > >> >different threads asking for additional (replacement) mentors. > >> > > >> >I really would like for things like retirement proposals to come from > >> >somebody who's spent time getting to know the community in greater > >> >details. > >> > > >> >Thanks, > >> >Roman. > >> > > >> >- > >> >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 > > > > - > 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] Graduate Apache Celix as TLP
Sure, the more the merrier or so I've been told ;) Looking forward to help getting good project to the next phase! Cos On Tue, Jun 17, 2014 at 08:35AM, Alexander Broekhuis wrote: > 2014-06-16 21:43 GMT+02:00 Konstantin Boudnik : > > > I had an honor to shepherd Celix ones and I like the dynamics of it. I am > > sure > > the community will grow as the time goes. In my opinion, it worth moving it > > into TLP. I will be happy to help the project moving forward if my help is > > required. > > > > Cos > > > Thanks for offering the help! > With Marcel and Roman we do have enough members, but if you want to join, > I'll gladly add you. Do you want to be added? > > > > -- > Met vriendelijke groet, > > Alexander Broekhuis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Celix as Top Level Project
+1 Dao speed! :) Cos On Thu, Jun 19, 2014 at 04:26PM, Alexander Broekhuis wrote: > Hi All, > > Since entering Incubation in November 2010, the Celix podling been working > towards graduation. The community has grown, releases have been made and > new committers have been added. > Over the last couple of months all items on the checklist for graduation > have been ticked of [1]. > This resulted in a, positive, vote on te dev list of Celix itself [2]. Also > the namesearch has been performed [3]. > As far as we can tell the project status is up to date [4], and Celix is > ready for graduation. > > After the discussion in the [DISCUSS] thread on [5], some changes were made > to the PMC list to have enough members for binding votes etc. > > Now I'd like to ask the IPMC to vote for the graduation of Celix. > > Please cast your vote: > > [ ] +1 Graduate the Apache Celix podling from Apache Incubator as a TLP > [ ] +0 Indifferent to the graduation status of Apache Celix podling > [ ] -1 Reject graduation of Apache Celix podling from Apache Incubator > because ... > > The vote will be open for 72 hours, after which I will tally and post the > results. > > Thanks in advance, > > Alexander Broekhuis > (PPMC member of Apache Celix) > > [1]: http://incubator.apache.org/guides/graduation.html#checklist > [2]: http://markmail.org/thread/7y3a2l6qqm56cvud > [3]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-50 > [4]: http://incubator.apache.org/projects/celix.html > [5]: http://markmail.org/thread/7udzxyd7ey2nyqsr > > > X. Establish the Apache Celix 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 native implementation of the OSGi >specification. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management >Committee (PMC), to be known as the "Apache Celix Project", >be and hereby is established pursuant to Bylaws of the >Foundation; and be it further > >RESOLVED, that the Apache Celix Project be and hereby is >responsible for the creation and maintenance of software >related to a native implementation of the OSGi >specification; >and be it further > >RESOLVED, that the office of "Vice President, Apache Celix" 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 Celix Project, and to have primary responsibility >for management of the projects within the scope of >responsibility of the Apache Celix 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 Celix Project: > > * Alexander Broekhuis > * Pepijn Noltes > * Bjoern Petri > * Erik Jansman > * Marcel Offermans > * Roman Shaposhnik > * Konstantin Boudnik > > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alexander Broekhuis >be appointed to the office of Vice President, Apache Celix, 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 Celix 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 Celix Project; and be it further > >RESOLVED, that the Apache Celix Project be and hereby >is tasked with the migration and rationalization of the Apache >Incubator Celix podling; and be it further > >RESOLVED, that all responsibilities pertaining to the Apache >Incubator Celix podling encumbered upon the Apache Incubator >Project are hereafter discharged. > > -- > Met vriendelijke groet, > > Alexander Broekhuis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Spam
Evidently +1 to ban the account On Fri, Jun 20, 2014 at 04:37PM, Julian Hyde wrote: > The dozen or so messages from abiola balogun on this list > in the past month have been monosyllabic non sequiturs [1]. I think he/she/it > is a spam bot and propose that he/she/it be removed from the list. > > Julian > > [1] https://www.mail-archive.com/general@incubator.apache.org/maillist.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Tez graduation [Was: Request for mentor assessment]
Ok, I've reached out to the Tez project and it seems that they are wokring w/ Chris Mattmann's on the graduation process (per an email exchange http://s.apache.org/K7g). What has caught my attention is the PPMC composition which is pretty much uniformly represented by a group with the same affiliation. Given that this page https://tez.incubator.apache.org/team-list.html is up to date. If I am reading https://incubator.apache.org/guides/graduation.html#community right, the PPMC and committers composition should be diversified. Is it a concern for graduation from the IPMC standpoint of view? Regards, Cos On Mon, Jun 16, 2014 at 06:54PM, Chris Douglas wrote: > Tez is ready to graduate. Cos, if you can help us manage that process, > it'd certainly be appreciated. -C > > On Mon, Jun 16, 2014 at 12:53 PM, Konstantin Boudnik wrote: > > I share the sentiment with NPanday - doesn't seem like anything is happening > > there really. > > > > If it of an interest to the incubator, I will volunteer to help mentoring > > Tez. > > > > Cos > > > > > > On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote: > >> I think Tez needs some more help mentoring. I myself haven't had > >> as much time as possible so the more folks over there that can > >> help mentor the better. > >> > >> Good job starting this thread, Roman. > >> > >> > >> > >> > >> > >> > >> -Original Message- > >> From: Roman Shaposhnik > >> Reply-To: "general@incubator.apache.org" > >> Date: Thursday, June 12, 2014 5:44 PM > >> To: "general@incubator.apache.org" > >> Subject: Re: Request for mentor assessment > >> > >> >On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra > >> >wrote: > >> >> Seems like NPanday should go to attic. One mentor I asked did not even > >> >> monitor it anymore > >> > > >> >I've had exactly the same experience. My plan here is to wait for folks > >> >to chime in on this thread and for those mentors who are MiA start > >> >different threads asking for additional (replacement) mentors. > >> > > >> >I really would like for things like retirement proposals to come from > >> >somebody who's spent time getting to know the community in greater > >> >details. > >> > > >> >Thanks, > >> >Roman. > >> > > >> >- > >> >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 > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [DISCUSS] Incubator exit criteria
On Thu, Jun 19, 2014 at 05:54AM, Marvin Humphrey wrote: > On Wed, Jun 18, 2014 at 11:14 PM, Roman Shaposhnik wrote: > > > To this end, I'd like to prose a very simplistic criteria > > for a potential retirement from the incubator: unless both > > of of the following applies project get put to a retirement > > IPMC vote: > >* there has been a release in the past 12 months > >* there has been a bona-fine change to a community > > structure in the past 12 months > > +1 > > I think this is highly constructive, and I think the simplified criteria are a > strong improvement. For those who are raising objections, consider that the > retirement vote **may not pass**. > > Deadlines are great motivators. Just knowing that a retirement vote is looming > should get those releases in the pipeline and those PPMC members proposed. > > Having to make the case that the podling should continue is also an excellent > exercise which should serve to focus the podling on the goals of the Incubator > and help to educate as to what it means to be an Apache project. That is > worthwhile even for podlings who may be extremely active like Drill, or those > who take a while to ramp up like Celix. Email activity and commits are not > enough on their own -- they may well get you the votes to get you through the > vote, but only a release or a community change should buy an automatic > extension. > > One suggestion: Make the "community" criteria an addition to the PPMC. Adding > a Mentor would count. I think community part aspect is very important, and addition to PPMC and/or mentors is a good way to demonstrate the process. Cos > Marvin Humphrey > > - > 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: Tez graduation [Was: Request for mentor assessment]
If I am not mistaken, no one really doubt the possible value of Tez (incubating) for other open- and close-source projects. I don't think it is an intention of the IPMC or a wider incubator community to pass the judgement on the technical viability of a project. What is discussed, on the other hand, is how successful said PPMC in achieving the goal of community building and diversification. The link to the project XML was very helpful in understanding the amount of the people involved into the day-to-day activities. And it's great! However, the question that remains unanswered so far - unless I've missed the answer - about the spread of the PPMC and committers? What is the chances of the project staying alive and vibrant if a commercial entity will decide to cease its participation in the project? Regards, Cos On Mon, Jun 23, 2014 at 10:51PM, Rohini Palaniswamy wrote: > I will add my two cents in here on the diversity front as a member of the > Pig team which has been working closely with Tez team for the past 3 > quarters. > > There has been a whole lot of features and design changes done in Tez > driven by requirements from Pig and it has been a pleasure working with the > Tez community. We have had a really good collaboration and development has > happened at a really really fast pace both in Pig and Tez, with Pig team > picking features from Tez snapshot builds as and when they are fixed. We > just merged Pig on Tez branch into Pig trunk last month. Most of the > collaboration has been through jiras and you can see a lot of linked Pig > jiras. Pig on Tez is especially a cross-company team effort in Apache - > Yahoo!, Hortonworks, Netflix and LinkedIn and many of the requirements and > fixes on Tez has been driven by the security, performance and large scale > needs of these companies. http://tinyurl.com/m5tbzxt is the list of Tez > jiras created just by the Pig team (48 jiras). There were at least quite a > few more created by others when we reported issues in mails. > > Hive of course is the other big project and Cascading is also into the mix > now. With all the widely adopted analytics tools on top of Hadoop adding > support for it and many companies adopting it there is very good future for > Tez and I think it is just prejudice to call it as a commercial development > masquerading as an Apache community. We really see it as a replacement for > mapreduce in the near term and pleased with the current results and the > future potential as a user and have been investing in the development of > Tez as well with dedicated resources. We opened Pig and Hive on Tez for > testing for users in Yahoo! in Apr and Cheolsoo opened up Pig on Tez for > users in Netflix this month and both Netflix and Y! have plans to get it > into production by end of the year and Linkedin also hopes to do the same. > With this early adoption from some of the biggest users of hadoop, I am > sure Tez will only become more stable and mature in the coming year and > gain more traction and wider adoption with other users as well as more > companies migrate to Hadoop 2. > > Regards, > Rohini > > > On Mon, Jun 23, 2014 at 9:48 PM, Roman Shaposhnik wrote: > > > On Mon, Jun 23, 2014 at 9:44 PM, Vinod Kumar Vavilapalli > > wrote: > > > I see two threads here > > > - Concerns about graduation of Apache Tez project w.r.t diversity based > > on the PPMC html page > > > - Community related threads about things like whether diversity is a > > hard requirement or how > > > to grow communities. > > > > > > AFAICT, Hitesh's latest information on the state of the members of the > > team > > > (and the updated page) should allay any concerns on diversity. > > > > > > If people disagree, we can continue this thread along that discussion. > > If not, we can close this topic as the graduation discussion/vote proceeds > > here and elsewhere. > > > > > > The other threads may be valuable but OT IMHO and so are better forked > > into their own threads. > > > > I personally think both are very closely related. Like I said, to > > me the diversity thread is really in support of the thesis that > > the project is capable of growing a community outside of > > a forcing function of a single employer. > > > > That said, I haven't done the due diligence to form my personal > > opinion one way or another. I am going to do it this week. > > > > Thanks, > > Roman. > > signature.asc Description: Digital signature
Re: [REQUEST] Seeking volunteer replacement mentors for NPanday
Hey Roman. I can find a few cycles to help with that, if no one else with more experience wants to step in. Regards, Cos On Tue, Jun 24, 2014 at 06:04PM, Roman Shaposhnik wrote: > Hi! > > given the current situation with NPanday's mentors, > I'd like to request additional help from IPMC. If you > could consider spending your cycles helping > NPanday community figure out the roadmap ahead, > please reply to this thread. > > My goal is to find at least one active replacement > mentor by the end of this week. > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [REQUEST] Seeking volunteer replacement mentors for NPanday
Done. The email has been sent to the npanday-...@incubator.apache.org list. Cos On Sun, Jun 29, 2014 at 07:07PM, Roman Shaposhnik wrote: > Hi! > > Since in 5 days nobody else volunteered, I'd like > to propose that we finalize Cos's offer of his > cycles and replace the current AWOL mentors > with him. > > I'll make sure this gets recorded in the podling > XML description. > > Cos, can you please follow up with the NPanday > community and work out a transition plan with > them? I guess the first order of business would > be to help them with the monthly report (they > are on schedule for this one). If you could > do that before Wed -- that would be very much > appreciated. > > Thanks, > Roman. > > On Tue, Jun 24, 2014 at 10:15 PM, Konstantin Boudnik wrote: > > Hey Roman. > > > > I can find a few cycles to help with that, if no one else with more > > experience > > wants to step in. > > > > Regards, > > Cos > > > > On Tue, Jun 24, 2014 at 06:04PM, Roman Shaposhnik wrote: > >> Hi! > >> > >> given the current situation with NPanday's mentors, > >> I'd like to request additional help from IPMC. If you > >> could consider spending your cycles helping > >> NPanday community figure out the roadmap ahead, > >> please reply to this thread. > >> > >> My goal is to find at least one active replacement > >> mentor by the end of this week. > >> > >> Thanks, > >> Roman. > >> > >> - > >> 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: A mentor's call in
Hi Brett, thanks for the detailed update and the refs to the earlier discussion - it helps! I understand that the project has reached a certain point where most of the functionality is in place and current users are pretty happy with it. Except for the cases where they step on some issues. In which case, as you pointerd out, they are usually capable to submit a patch for it. I see a couple of potentially helpful steps forward. On Fri, Jul 04, 2014 at 09:45AM, Brett Porter wrote: > Thanks Konstantin. > > Lars gave a bit of an update here: > http://mail-archives.apache.org/mod_mbox/incubator-npanday-dev/201406.mbox/%3C000101cf87b4%2404611cd0%240d235670%24%40lcorneliussen.de%3E > > We do have stuff to release, which has been stuck for some time. However, > all of the blockers to a release have been removed recently. I started the > process of getting through the JIRA tickets (see previous mail to the list) > - once that can get cleared up, I think it's ready to start. > > A few other status updates... > > I've also just got the site publishing under svnpubsub, and will document > how to do that so that folks can start making changes again. Users have > drawn attention to the fact that the home page doesn't list any recent > activity. Some effort needs to go into making it clearer of the current > status and how to contribute. I'll start another discussion around that. > > We're a bit stuck with the builds not working on Jenkins again - but I've > reached out to Infrastructure to try and get that resolved. > > The other day I also went through the podling status page and updated it > with current information. I'll look at the status report before the end of > the week. > > I'm happy to give this push to get the next release out and make it easy to > repeat so that some momentum can be rebuilt, and contributions can be put > into a release. > > As Lars pointed out, we have a few users who are interested in seeing a > release, and some that are interested in contributing fixes from time to > time - we really need to get more of those semi-regular contributors on as > committers. > > Cheers, > Brett > > On 2 Jul 2014, at 3:34 pm, Konstantin Boudnik wrote: > > > Guys, > > > > per this thread on the general@ list > > http://mail-archives.apache.org/mod_mbox/incubator-general/201406.mbox/%3CCA%2BULb%2BvGa9bnrR7KOmRMRZXoXqnkY9rVxxWS_SB%2B0a5P_be7wg%40mail.gmail.com%3E > > > > I'd like to introduce myself and kick-off the discussion about future > > project > > road map. Clearly, I would love to find out how I help you guys in moving > > project forward, building active and thriving community, and achieving all > > the > > goals of what constitutes a successful Apache incubation. > > > > I am looking into the project web page and see that it has been a while > > since > > the last release. What do you think is the reason for it? The project has > > matured? Is it pretty stable hence doesn't require much of the bugfixes? > > Anything else? > > > > If you interested, you can quicky lookup into who I am at > > https://people.apache.org/committer-index.html#cos > > > > Looking forward for your input and ideas on how we can move forward! > > -- > > With regards, > > Cos > > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: A mentor's call in
entum can be rebuilt, and contributions can be put > into a release. > > As Lars pointed out, we have a few users who are interested in seeing a > release, and some that are interested in contributing fixes from time to > time - we really need to get more of those semi-regular contributors on as > committers. > > Cheers, > Brett > > On 2 Jul 2014, at 3:34 pm, Konstantin Boudnik wrote: > > > Guys, > > > > per this thread on the general@ list > > http://mail-archives.apache.org/mod_mbox/incubator-general/201406.mbox/%3CCA%2BULb%2BvGa9bnrR7KOmRMRZXoXqnkY9rVxxWS_SB%2B0a5P_be7wg%40mail.gmail.com%3E > > > > I'd like to introduce myself and kick-off the discussion about future > > project > > road map. Clearly, I would love to find out how I help you guys in moving > > project forward, building active and thriving community, and achieving all > > the > > goals of what constitutes a successful Apache incubation. > > > > I am looking into the project web page and see that it has been a while > > since > > the last release. What do you think is the reason for it? The project has > > matured? Is it pretty stable hence doesn't require much of the bugfixes? > > Anything else? > > > > If you interested, you can quicky lookup into who I am at > > https://people.apache.org/committer-index.html#cos > > > > Looking forward for your input and ideas on how we can move forward! > > -- > > With regards, > > Cos > > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Draft Report July 2014 - please review
I will pick up Flink - I shepherd them before, will do again. Updating the wiki right now Cos On Wed, Jul 09, 2014 at 05:23PM, Robert Metzger wrote: > Hi, > > it seems that Flink does not have a Shepherd assigned. It is also missing a > review by them. But it looks like half of the projects are missing > shepherd/mentor notes. > > -- Robert > > > On Wed, Jul 9, 2014 at 5:19 PM, Joe Brockmeier wrote: > > > Hi Roman, > > > > On Tue, Jul 8, 2014, at 11:56 PM, Roman Shaposhnik wrote: > > > The rest looks good to me. I'll do one final pass tomorrow before > > > submitting to the board! > > > > I went ahead and made the changes on the wiki. Let me know if you need > > anything else or if anyone has spotted any other omissions/errors. > > Thanks! > > > > Best, > > > > jzb > > -- > > Joe Brockmeier > > j...@zonker.net > > Twitter: @jzb > > http://www.dissociatedpress.net/ > > > > - > > 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: Draft Report July 2014 - please review
For the Flink: Shepherd/Mentor notes: Mentors look active; dev maillist is active. No obvious issues. Cos On Wed, Jul 09, 2014 at 08:05PM, Konstantin Boudnik wrote: > I will pick up Flink - I shepherd them before, will do again. > Updating the wiki right now > > Cos > > On Wed, Jul 09, 2014 at 05:23PM, Robert Metzger wrote: > > Hi, > > > > it seems that Flink does not have a Shepherd assigned. It is also missing a > > review by them. But it looks like half of the projects are missing > > shepherd/mentor notes. > > > > -- Robert > > > > > > On Wed, Jul 9, 2014 at 5:19 PM, Joe Brockmeier wrote: > > > > > Hi Roman, > > > > > > On Tue, Jul 8, 2014, at 11:56 PM, Roman Shaposhnik wrote: > > > > The rest looks good to me. I'll do one final pass tomorrow before > > > > submitting to the board! > > > > > > I went ahead and made the changes on the wiki. Let me know if you need > > > anything else or if anyone has spotted any other omissions/errors. > > > Thanks! > > > > > > Best, > > > > > > jzb > > > -- > > > Joe Brockmeier > > > j...@zonker.net > > > Twitter: @jzb > > > http://www.dissociatedpress.net/ > > > > > > - > > > 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: [ANNOUNCE] Konstantin Boudnik joins the IPMC
Roman, thanks for officially welcoming me to the Incubator! It's good to be a part of the distinguished group of people, who are responsible for the nursing of the new communities all the way to top-level projects! A few words about myself. I am with Apache since 2009: first joining the Hadoop, and a number of other projects later on. My most favorite is Bigtop, which is no coincidence, because I've helped to create it ;) Right now I serve as Bigtop PMC Chair. In my pre-Apache life: for the long 15 years I was a part of lost tribe of Sun Microsystems (yo! to all ex-Suns here!). I was a Solaris sysadmin, worked in the compiler groups, and finally joined the Java (JVM) crowd, developing cluster and grid systems. Right now I am the VP of Open Source Development at WANdisco. As I am learning all new ropes - again - please let me know what I can help with. In the meanwhile, I am trying to assist NPandey community to get our of the winter hibernation ;) With best regards, Cos 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 Cos' pubkey: http://people.apache.org/~cos/cos.asc On Fri, Jul 11, 2014 at 11:11PM, Roman Shaposhnik wrote: > Hi! > > The Apache Incubator PMC has VOTEd to add > Konstantin Boudnik AKA Cos to our ranks. > > Welcome, Cos! Great to have you on board! > > Please let us know a surprising thing or two > about yourself. > > Thanks, > Roman. signature.asc Description: Digital signature
Re: [PROPOSAL] Apache Argus Proposal
If an objective of a podding is to build a diversified community then perhaps it should be an explicitly defined graduation criteria? In fact, earlier I have raised exactly the same question about Tez but I don't think it ever been satisfactory answered. As for chances of a project to stick with github if it was started their - I respectfully disagree. I think only projects which feel comfortable within the github will stay there. Others will move on: Apache Spark is a great example of late. After 2 years of organic growth @github they came to the Incubator and graduated very fast with flying colors. Without stacking the PPMC IIRC. So, I am fond of Henry's hope that the project will solicit a more diversified set of mentors and initial committers. -- Cos On Tue, Jul 15, 2014 at 02:38PM, Henry Saputra wrote: > Hi Andrew, thanks for chiming in =) > > I like your and Owen's opinion about initial members of an incubator project. > And also agree it is responsibility of the polling to achieve better > diversity during its time under Apache incubator. > > For this particular proposal, however, the mentors mostly coming from > same organization. > Hopefully with this proposal announcement, the project could "solicit" > mentors from different organizations to help add check and balance. > > - Henry > > On Tue, Jul 15, 2014 at 2:22 PM, Andrew Purtell wrote: > > I had started typing up a response to Henry's mail but will discard the > > beginning of it to say I agree with Owen. A new project coming into the > > incubator quite naturally could have the initial set of committers entirely > > from one organization. An organization donating an existing code base, for > > example. > > > > However, there has been recent discussion elsewhere that the Incubator > > should more closely consider if an incubating project has succeeded to grow > > a community beyond the initially limited group before declaring a project > > ready for graduation. (Refer to the discussion on the graduation of Apache > > Tez.) This position seems reasonable, and should naturally apply here. If a > > project exits graduation with the same lack of PMC/committer diversity with > > which it entered, this is in effect Apache-washing, in my opinion. A > > stacked PMC is no more open a community then one controlled by a BDFL and > > hosted on GitHub. > > > > > > > > On Tue, Jul 15, 2014 at 2:14 PM, Owen O'Malley wrote: > > > >> On Tue, Jul 15, 2014 at 1:59 PM, Henry Saputra > >> wrote: > >> > >> > Maybe we should start asking incubator project to try to build some > >> > kind of momentum or community before going to ASF incubator. > >> > > >> > >> Apache incubator is a great place for new projects to grow their community > >> and diversity. Once a project is established it is much harder to change > >> the infrastructure and there projects started on github are more likely to > >> stay on github. I think there is significant value in these projects being > >> done in the Apache Way. > >> > >> > >> > > >> > All but one PPMC members for this proposal would be from Hortonworks. > >> > > >> > >> Would you like to volunteer to help mentor? > >> > >> > >> > Just from high level it seems like it has similar goal as Apache Knox > >> > [1], what is the differences between the 2? > >> > > >> > >> I think Knox and Argus complement each other. Knox provides perimeter > >> security via proxy/gateway services, while Argus is providing fine grain > >> integrated authorization and auditing. > >> > >> .. Owen > >> > > > > > > > > -- > > Best regards, > > > >- Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > - > 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] Apache Argus Proposal
On Thu, Jul 17, 2014 at 11:41AM, Andrew Purtell wrote: > Thank you for writing back with a detailed clarification. > > Regarding encryption at rest, HDFS is adding it as HDFS-6134, so likely > there will be a new core feature option for the ecosystem to consider > shortly. > > I don’t feel one technology or one company or one small group or one > approach can solve this problem. This has to be addressed by the community > working together. This would also require a lot of support from each > dependent projects and lot of co-ordination. And there would be multiple > security solutions available for the end users to pick from. > > Completely agreed. However, the desired community cooperation has both > technical and political components. I think there are some concerns about > how successful an outcome Argus may produce, informed by experience. > Perhaps it would be worthwhile to address those concerns. Argus proposes to > develop a common security infrastructure for the Hadoop ecosystem. In my > opinion (and informed by personal experience) we have new incubating Hadoop > ecosystem security projects like Sentry and Knox and proposals such as > Argus because Hadoop core is locked down. Argus et. al. are like the > proverbial blocked river (user demand for features) seeking a new route > around a landslide (obvious poisonous contention and litigation-via-JIRA on > every significant topic). I would be curious your thoughts on how to avoid > the same end state in the Argus project. In my opinion, it would be a > tragedy if a potential solution ends up perpetuating the dysfunction it > seeks to bypass to a greater proportion of Foundation projects instead. A > Hadoop ecosystem project attempting to remain independent from the > dysfunction of Hadoop core would be well advised to stay away from adoption > of Argus components (security is so critical) if the governance of Argus > perpetuates that dysfunction. By the way, it is also not too late for Knox > and Sentry. Big +1 on this point, Andrew! Thanks for expressing it so eloquently. Building on your argument, I'd like to add the main reason for the ill-advised contentions in the Hadoop core is the vested interested that's shared between (mostly) two major groups of the contributors. They are mostly interested in the status quo rather than in adopting changes that can help new users to come on board and become contributors. Similar situation in a security project - arguably the most sensitive part of any software stack - that'd be a disaster. Cos > On Wed, Jul 16, 2014 at 11:34 PM, Don Bosco Durai > wrote: > > > > How do you define the 'Hadoop complex eco-system'? If that definition > > Agreed, complex is a relative term. I used the term complex, because now > > more than 20 products use Hadoop and list is growing. There are 10 products > > listed on http://hadoop.apache.org/. Then there are others projects like > > Accumulo, Impala, Storm, Kafka, Falcon, Pig, Flume, Sqoop, Oozie, etc. > > which uses HDFS or support/enable other products within Hadoop ecosystem. > > If we dig deeper, each component might have multiple processes (Name Node, > > Data Node, Job Tracker, Storm Nimbus Server, HBase Master Servers, HBase > > Regions Servers, HA, etc). With YARN, now user can run their applications > > in the cluster, which is a great feature, but it is very scary from > > security point of view, because now users can write their custom > > application and run it within a secure data center. > > > > I don’t feel one technology or one company or one small group or one > > approach can solve this problem. This has to be addressed by the community > > working together. This would also require a lot of support from each > > dependent projects and lot of co-ordination. And there would be multiple > > security solutions available for the end users to pick from. > > > > > includes projects such as HBase, we have significant security controls, > > so > > The mature projects have started beefing up their security features. In > > recent releases, HBase added cell based access control and encryption, HDFS > > added advanced ACLs and now working on file level encryptions, Hive added > > ATZ-NG, no encryption yet. The newer ones like Solr, Storm, Falcon have > > very basic security control. On the good news side, most components have > > started supporting Kerberos and SSL. But encryption at rest is still a > > challenge. In most cases it is all or none, except probably HBase and > > Accumulo. Access control and auditing is also not that mature among the > > newer projects. The goal is here is not to reinvent or impose on each > > project, but to reuse the existing security technologies consistently > > across projects and at the same extend it where applicable. > > > > > or the combination of Hive+Sentry would agree with that statement either. > > Personally, Hive is my ideal role model for all hadoop projects to follow. > > Out of the box, it has inbuilt access control
Re: August 2014 Incubator Report Timeline
I have just noticed that Celix is still on the roster for https://wiki.apache.org/incubator/August2014 The project has graduated to TLP last month and will be on the board report. Hence it needs to be removed from the IPMC report. Cos On Tue, Jul 29, 2014 at 12:36PM, Joe Brockmeier wrote: > http://wiki.apache.org/incubator/August2014 > > Wed August 06 -- Podling reports due by end of day > Sun August 10 -- Shepherd reviews due by end of day > Sun August 10 -- Summary due by end of day > Tue August 12 -- Mentor signoff due by end of day > Wed August 13 -- Report submitted to Board > Wed August 20 -- Board meeting > > Best, > > jzb > -- > Joe Brockmeier > j...@zonker.net > Twitter: @jzb > http://www.dissociatedpress.net/ > > - > 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 REEF into the Apache Incubator
+1 On Sat, Aug 09, 2014 at 02:40PM, Byung-Gon Chun wrote: > Hi, > > Thanks for participating in the proposal discussion on REEF. The discussion > has calmed. I would like to call a vote for acceptance of REEF into the > Apache Incubator. > > The proposal is attached below, and it is also available at > https://wiki.apache.org/incubator/ReefProposal > > Let's keep this vote open for three business days, closing the voting on > August 11, 11:59PM (PDT). > > [] +1 Accept REEF into the Incubator > [] 0 Don't care > [] -1 Don't accept REEF because... > > Thanks! > -Gon > > -- > Byung-Gon Chun > > > # REEFProposal - Incubator > > > # Abstract > > REEF (Retainable Evaluator Execution Framework) is a scale-out > computing fabric that eases the development of Big Data applications > on top of resource managers such as Apache YARN and Mesos. > > > # Proposal > > REEF is a Big Data system that makes it easy to implement scalable, > fault-tolerant runtime environments for a range of data processing > models (e.g., graph processing and machine learning) on top of > resource managers such as Apache YARN and Mesos. REEF provides > capabilities to run multiple heterogeneous frameworks and workflows of > those efficiently. > > Additionally, REEF contains two libraries that are of independent > value: Wake is an event-based-programming framework inspired by Rx and > SEDA. Tang is a dependency injection framework inspired by Google > Guice, but designed specifically for configuring distributed systems. > > > # Background > > The resource management layer such as Apache YARN and Mesos has > emerged as a critical layer in the new scale-out data processing > stack; resource managers assume the responsibility of multiplexing a > cluster of shared-nothing machines across heterogeneous > applications. They operate behind an interface for leasing containers > - a slice of a machine’s resources - to computations in an elastic > fashion. However, building data processing frameworks directly on this > layer comes at a high cost: each framework must tackle the same > challenges (e.g., fault-tolerance, task scheduling and coordination) > and reimplement common mechanisms (e.g., caching, bulk transfers). > > REEF provides a reusable control-plane for scheduling and coordinating > task-level work on cluster resource managers. The REEF design enables > sophisticated optimizations, such as container re-use and data > caching, and facilitates workflows that span multiple > frameworks. Examples include pipelining data between different > operators in a relational system, retaining state across iterations in > iterative or recursive data flow, and passing the result of a > MapReduce job to a Machine Learning computation. > > > # Rationale > > Since REEF is a library that makes it easy to write distributed > applications on top of Apache YARN or Mesos, the Apache Software Foundation > is the perfect home for hosting REEF. > > > # Current Status > > REEF has been developed mostly by Microsoft, UCLA and the Seoul > National University. The REEF codebase is open-sourced under Apache > License 2.0 and is currently hosted in a public repository at > github.com. > > > # Meritocracy > > We plan to build a strong open community by following the Apache > meritocracy principles. We will work with those who contribute > significantly to the project and invite them to be its committers. > > > # Community > > REEF is currently being used internally at Microsoft. Also, SK > Telecom builds their data analytics infrastructure on top of REEF in > collaboration with Seoul National University. We hope to extend our > contributor base by becoming an Apache incubator project. REEF will > attract developers who are interested in creating common building > blocks for simplifying the development of large-scale big data > applications. > > > # Core Developers > > Core developers are engineers from Microsoft, Purestorage, UCB, UCLA, > UW and Seoul National University. > > > # Alignment > > REEF depends on many Apache projects and dependencies. REEF is built > on resource managers such as Apache YARN and Apache Mesos. REEF also > uses HDFS as a distributed storage layer. > > > # Known Risks > ## Orphaned Products > > The risk of REEF being orphaned is small because Microsoft products > are built on REEF. The core REEF developers continue to work on REEF > at Microsoft, UCLA, and Seoul National University. The REEF project is > gaining interest from other institutions to be used as their > infrastructure. > > ## Inexperience with Open Source > > Several core developers have experience with open source development. > REEF committers will be guided by the mentors with strong Apache open > source project backgrounds. > > ## Homogeneous Developers > > The initial committers include developers from several institutions > including Microsoft, Purestorage, UCB, UCLA, and Seoul National > University. > > ## Reliance on Salaried D
Re: [DISCUSS] Incubator exit criteria
It makes sense. And it also seems to be a decent compilation of the points agreed in the earlier and lengthy discussion on the topic. Cos On Sun, Aug 10, 2014 at 05:22PM, Roman Shaposhnik wrote: > Seems like attachments are eaten away by general@ > Including the patch bellow > > Index: content/guides/retirement.xml > === > --- content/guides/retirement.xml (revision 1617182) > +++ content/guides/retirement.xml (working copy) > @@ -64,6 +64,7 @@ > If the PPMC unanimously recommends retirement, it gets retired. > No need for a VOTE, just notify the IPMC, leave for 72 hours minimum > and retire it. > If the mentors say it should be retired but the PPMC does not > unanimously agree then the podling should seek to recruit new mentors. > No need to VOTE, just get on with it. > If there insufficient mentors willing to continue working with > the project then the IPMC has a problem to address on a case by case > basis. The shepherd role ensures that these cases are spotted during > the reporting process. If necessary a [DISCUSS] thread can be started > and a sensible plan is developed (which may include a VOTE to retire, > at this point there should be no -1's as a -1 needs to be backed by a > willingness to act and thus this should have been surfaced in case 2) > above. > + If the project has not had a release for more than a year this > fact will get flagged by the Incubator report and the PPMC will be > expected to get notified (either by one of the mentors or an IPMC > member). The initial discussion with the community is expected to > uncover and start addressing the underlying issues preventing the > project from producing releases. At this point the project is expected > to be put on a monthly reporting schedule and the next month's report > is expected to articulate the steps and expected time frame to get to > the release. In case of a clear lack of progress for straight three > months the [VOTE] thread on potential retirement is expected to be > started in IPMC. > > > Note, this is exactly what happens with board oversight of TLPs, > Index: content/incubation/Process_Description.xml > === > --- content/incubation/Process_Description.xml (revision 1617182) > +++ content/incubation/Process_Description.xml (working copy) > @@ -34,7 +34,7 @@ > Establishment > Acceptance > Review > -Termination > +Termination > or Retirement > Continuation > Graduation > > @@ -206,9 +206,12 @@ > their consideration. > > > - > -Termination > -If you receive a recommendation for termination then you have a > + > +Termination or Retirement > +There are two ways for a project to cease incubation: Termination > +or Retirement. > + > +If you receive a recommendation for termination then you have a > problem. Chances are that there are either legal or structural > problems with your project that in the opinion of the Incubator PMC > are not resolvable within a reasonable time frame. A termination > @@ -217,6 +220,23 @@ > Directors and/or your Sponsor. You should be aware that several > Members of the Board are also Members of the Incubator PMC and as > such, an appeal is unlikely to be successful. > + > +Retirement is typically an internal decisions by PPMC. A retired project > +is a project which has been closed down by the PPMC or by the IPMC for > +various reasons. It is not longer developed at the Apache Incubator and > +does not have any other duties. > + > +Retirement can also be suggested by IPMC on the grounds of lack > +of releases for more than a year. However, since unlike termination, > +retirement is a voluntary process, the suggestion will have to be > +discussed and voted upon. > + > +It's important to view this process as being the retirement of the podling > +community, not the code. It should not be implied that the code is not for > +use - just that it has no community. The source code of a retired project > +is available in ASF repository, when the copyright requirements are > fullfilled. > +This is indicated through the incubator status page. For more details on > +Retirement please see our href="../guides/retirement.html">Guide to Retirement > > > > > - > 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: August 2014 Incubator Report Timeline
Sorry Jon - I missed the email. And of course you're right about the report. I will look into what needs to be done for the clean-up tonight. Cos On Mon, Aug 04, 2014 at 08:32PM, John D. Ament wrote: > Cos > > Only reason Celix would be on the report still is if they didn't clean up > podlings.xml. Please clean it up on their behalf, as I believe you have > joined their PMC. > > John > > > On Mon, Aug 4, 2014 at 8:29 PM, Konstantin Boudnik wrote: > > > I have just noticed that Celix is still on the roster for > > https://wiki.apache.org/incubator/August2014 > > > > The project has graduated to TLP last month and will be on the board > > report. > > Hence it needs to be removed from the IPMC report. > > > > Cos > > > > On Tue, Jul 29, 2014 at 12:36PM, Joe Brockmeier wrote: > > > http://wiki.apache.org/incubator/August2014 > > > > > > Wed August 06 -- Podling reports due by end of day > > > Sun August 10 -- Shepherd reviews due by end of day > > > Sun August 10 -- Summary due by end of day > > > Tue August 12 -- Mentor signoff due by end of day > > > Wed August 13 -- Report submitted to Board > > > Wed August 20 -- Board meeting > > > > > > Best, > > > > > > jzb > > > -- > > > Joe Brockmeier > > > j...@zonker.net > > > Twitter: @jzb > > > http://www.dissociatedpress.net/ > > > > > > - > > > 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: August 2014 Incubator Report Timeline
s/Jon/John/ (clumsy me) On Mon, Aug 11, 2014 at 02:08PM, Konstantin Boudnik wrote: > Sorry Jon - I missed the email. And of course you're right about the report. > I will look into what needs to be done for the clean-up tonight. > > Cos > > On Mon, Aug 04, 2014 at 08:32PM, John D. Ament wrote: > > Cos > > > > Only reason Celix would be on the report still is if they didn't clean up > > podlings.xml. Please clean it up on their behalf, as I believe you have > > joined their PMC. > > > > John > > > > > > On Mon, Aug 4, 2014 at 8:29 PM, Konstantin Boudnik wrote: > > > > > I have just noticed that Celix is still on the roster for > > > https://wiki.apache.org/incubator/August2014 > > > > > > The project has graduated to TLP last month and will be on the board > > > report. > > > Hence it needs to be removed from the IPMC report. > > > > > > Cos > > > > > > On Tue, Jul 29, 2014 at 12:36PM, Joe Brockmeier wrote: > > > > http://wiki.apache.org/incubator/August2014 > > > > > > > > Wed August 06 -- Podling reports due by end of day > > > > Sun August 10 -- Shepherd reviews due by end of day > > > > Sun August 10 -- Summary due by end of day > > > > Tue August 12 -- Mentor signoff due by end of day > > > > Wed August 13 -- Report submitted to Board > > > > Wed August 20 -- Board meeting > > > > > > > > Best, > > > > > > > > jzb > > > > -- > > > > Joe Brockmeier > > > > j...@zonker.net > > > > Twitter: @jzb > > > > http://www.dissociatedpress.net/ > > > > > > > > - > > > > 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mentors heartbeat
Arguably, the number of mentored project doesn't reflect "the activity" per se. Unless I am missing something. Cos On Mon, Aug 25, 2014 at 04:46AM, Mattmann, Chris A (3980) wrote: > Guys, +1 to eventually doing this with JSON and YAML. The big problem > I see is curation (someone has to maintain it). Right now board reports > and the wiki are what's used to make the report, so feel free to use my > scripts for now until those are changed over. For example, I just ran them > right now (with some major pythonic updates to sniff mentors, and to > map name to committer ID, and updating years and months to current and > here's what I get): > > 29 phunt > 24 tomwhite > 24 rvs > 24 mattmann > 23 cdouglas > 20 hsaputra > 18 bdelacretaz > 18 arvind > 16 adc > 14 smarru > 14 rgardler > 14 olamy > 14 gates > 13 jfarrell > 12 kevan > 11 tdunning > 11 jim > 11 grobmeier > 11 ddas > 10 omalley >9 mfranklin >8 wave >8 lresende >8 jbonofre >8 ate >7 twilliams >7 rfrovarp >7 ke4qqq >7 jukka >6 jzb >6 acmurthy >5 struberg >5 nslater >5 marrs >5 lewismc >5 greddin >5 bodewig >4 thorsten >4 mahadev >4 joes >4 jghoman >4 gsingers >4 fmui >3 upayavira >3 tommaso >3 stevenn >3 ssc >3 snoopdave >3 nick >3 marvin >3 hwright >3 gstein >3 gianugo >3 chipchilders >3 benh >3 apurtell >2 todd >2 larsh >2 jochen >2 jmclean >2 dkulp >2 dennisl >2 dashorst >2 cutting >2 antelder >1 yegor >1 wrowe >1 wavw >1 stack >1 simonetripodi >1 robweir >1 rmannibucau >1 rfeng >1 rbircher >1 nandana >1 mnour >1 jvermillard >1 fchrist >1 enis >1 elecharny >1 cos >1 coheigea >1 brett >1 bmargulies >1 berndf >1 asavory >1 ant >1 akarasulu >1 ahart > > > > > ++ > Chris Mattmann, Ph.D. > Chief Architect > Instrument Software and Science Data Systems Section (398) > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 168-519, Mailstop: 168-527 > Email: chris.a.mattm...@nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++ > Adjunct Associate Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++ > > > > > > > -Original Message- > From: "Alan D. Cabrera" > Reply-To: "general@incubator.apache.org" > Date: Sunday, August 24, 2014 10:54 AM > To: "general@incubator.apache.org" > Subject: Re: Mentors heartbeat > > > > >On Aug 24, 2014, at 10:51 AM, Alan D. Cabrera > >wrote: > > > I am not so sure if its worth while with the board report. > >> > >> What's good for the goose is good for the gander. Having the board > >>report in machine readable formats provides the same advantages as that > >>afforded incubator reports. > > > >If these machine readable reports work out, I see no reason why they > >would not, then I predict an explosion of tool driven processes, e.g. > >release voting, podling acceptance and graduation votes, etc. > > > > > >Regards, > >Alan > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: How many podlings are being incubated?
Celix has been graduated, but still need to clear podling. My fault - I've promissed to fix it up and got distructed. Will finishe it before the end of the week. Cos On Sun, Aug 24, 2014 at 01:45PM, Alan D. Cabrera wrote: > Lookse like we need to update podling.xml. The August report states 31. My > tooling states 33: > > Argus > Aurora > BatchEE > Blur > Brooklyn > Celix > DataFu > DeviceMap > Drill > Droids > Falcon > Fleece > Flink > Hadoop Development Tools > Kalumet > log4cxx2 > MetaModel > MRQL > NPanday > ODF Toolkit > Optiq > Parquet > REEF > Ripple > Samza > Sentry > Sirona > Slider > Storm > Streams > Twill > Usergrid > Wave > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: How many podlings are being incubated?
I have fixed what was hopefully the last item in the graduation list, so Celix shouldn't appear in the IPMC reports anymore. Cos On Wed, Sep 03, 2014 at 10:13PM, Konstantin Boudnik wrote: > Celix has been graduated, but still need to clear podling. My fault - I've > promissed to fix it up and got distructed. Will finishe it before the end of > the week. > > Cos > > On Sun, Aug 24, 2014 at 01:45PM, Alan D. Cabrera wrote: > > Lookse like we need to update podling.xml. The August report states 31. > > My tooling states 33: > > > > Argus > > Aurora > > BatchEE > > Blur > > Brooklyn > > Celix > > DataFu > > DeviceMap > > Drill > > Droids > > Falcon > > Fleece > > Flink > > Hadoop Development Tools > > Kalumet > > log4cxx2 > > MetaModel > > MRQL > > NPanday > > ODF Toolkit > > Optiq > > Parquet > > REEF > > Ripple > > Samza > > Sentry > > Sirona > > Slider > > Storm > > Streams > > Twill > > Usergrid > > Wave > > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > signature.asc Description: Digital signature
[PROPOSAL] Silk as new Incubator project
ividuals when contributing to Apache projects. As a major initial contributor GridGain Systems is prepared to bring additional staff on board to assist with Silk development to ensure its active growth. One of the key motivators in creating the Silk project as part of the Incubator is to leverage the vendor-neutral nature of the ASF. The ASF has a strong and recognized brand as being a leader in open source, and by hosting Silk at the ASF, we hope to attract developers to build a viable community for the project. == Meritocracy == Apache Silk plans to adopt the policy that encourages an environment that supports a meritocracy. We intend to actively ask the community for help, listing/specifying the work that needs to be done, and keeping track of and encouraging members of the community who make any contributions. Community & Core Developers GridGain project has been actively building community of users in the last couple of years with an active StackOverflow group, support groups, and Meetups (http://www.meetup.com/Bay-Area-In-Memory-Computing). This group includes active members of Apache community as well. We strongly believe that this community will grow and develop substantially as part of Apache family and that’s our commitment. == Existing Documentation == Current documentation for GridGain project can be found here: http://www.gridgain.org/documentation/ We intend to migrate it into ASF podling. == Initial Source == Initial Apache 2.0 licensed source code can be found here: http://www.gridgain.org/download/ == External Dependencies == Here’s the list of 3rd party JAR-only dependencies: * Apache Hadoop * Apache Commons * H2 * JTS * Apache Lucene * Spring Here’s the list of the all licenses for 3rd party libraries currently used: * Apache 2.0 == Required Resources == === Mailing lists === * silk-private (with moderated subscriptions) * silk-dev * silk-user === Git & JIRA === * Git: https://git-wip-us.apache.org/repos/asf/incubator-silk.git * JIRA: JIRA Silk (SILK) == Initial Committers & Affiliation == * Dmitriy Setrakyan (GridGain Systems, dsetrakyan at gridgain dot com) * Yakov Zhdanov (GridGain Systems, yzhdanov at gridgain dot com) * Alexey Goncharuk (GridGain Systems, agoncharuk at gridgain dot com) * Sergey Vladykin (GridGain Systems, svladykin at gridgain dot com) * Valentin Kulichenko (GridGain Systems, vkulichenko at gridgain dot com) * Semen Boikov (GridGain Systems, sboikov at gridgain dot com) * Vladimir Ozerov (GridGain Systems, vozerov at gridgain dot com) * Nikita Ivanov (GridGain Systems, nivanov30 at gmail dot com) * Sergey Khisamov (FitechSource, skh at gmail dot com) * Ilya Sterin (ChronoTrack, isterin at gmail dot com) * Ryan Rawson (WANdisco, rawson at apache dot org) * Konstantin Boudnik (cos at apache dot org) * Roman Shaposhnik (rvs at apache dot org) == Sponsors == === Apache Champion === * Konstantin Boudnik (cos at apache dot org) === Nominated Mentors === * Michael Stack (stack at apache dot org) * Roman Shaposhnik (rvs at apache dot org) * Konstantin Boudnik (cos at apache dot org) signature.asc Description: Digital signature
Re: [PROPOSAL] Silk as new Incubator project
On Thu, Sep 18, 2014 at 10:21PM, Henry Saputra wrote: > Hi Cos, > > Looks like a good start of the proposal. > > How would this project relate to compare to existing ones like Apache > Spark, Storm, or Samza? The proposal will be updated shortly with these details. > Would love to have comparisons to existing ASF projects section to the > proposal. > > Also, would you guys mind adding or soliciting more mentors? > Seemed like most of initial committers have not been involved in ASF > yet so may need some help to adjust to Apache way. Good point, Henry! Would you consider investing a few cycles on your own and join the mentors for this proposal? Thanks in advance! Cos > > - Henry > > On Thu, Sep 18, 2014 at 9:40 PM, Konstantin Boudnik wrote: > > I would like to propose Silk as an Apache Incubator project. The new > > proposal is added to https://wiki.apache.org/incubator/SilkProposal and > > is duplicated below. > > > > -- > > Regards, > > Cos > > > > > > = Silk Apache Incubator Proposal = > > > > == Abstract == > > > > Apache Silk will be a unified In-Memory Data Fabric providing > > high-performance, > > distributed in-memory data management software layer between various data > > sources and user applications. > > > > == Proposal == > > > > Apache Silk is written mostly in Java and Scala with small amount of C++ > > code > > and will initially combine the following technologies under one unified > > umbrella: > > * In-Memory Data Grid > > * In-Memory Compute Grid > > * In-Memory Streaming Processing > > This unified in-memory fabric will provide high-performance, distributed > > in-memory software layer that sits in between various data sources and user > > applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. > > Applications > > APIs will be available for Java (and Java-based scripting languages), Scala, > > C++ and .NET (C#). > > > > GridGain Systems, Inc. submits this proposal to donate its Apache > > 2.0-licensed > > open source project generally known as “GridGain In-Memory Computing > > Platform”, > > its source code, documentation, and websites to the Apache Software > > Foundation > > (“ASF”) with the goal of extending the vibrant open source community around > > this technology ultimately governed by “Apache Way”. Proposed Naming > > > > We have been advised by the ASF mentors that the name “Silk” may not be > > ideal > > because the name may be too generic and may not pass ASF legal check. Here > > are > > the alternatives that we have come up with and any of those will be > > acceptable > > for the project pending the ASF legal green light: > > * Apache Silk (preferable name) > > * Apache Sylk > > * Apache Memstor > > * Apache Ignite > > > > == Background & Rationale == > > > > In-Memory Data Fabric is a natural and evolutionary consolidation of various > > “in-memory technologies” from the last decade. From simple local caching > > (JSR-107), to distributed caching, to data grids and databases, to streaming > > and plug-n-play acceleration - the in-memory space has grown quite > > dramatically. > > > > With rapid advances in NVRAM and significant price reduction of traditional > > DRAM on one hand, and growing sophistication and demand for faster data > > processing on another - many users of these silo-ed technologies and > > products > > started to look for a “strategic approach” to in-memory - an in-memory data > > fabric - that would provide suitable APIs for different types of payloads: > > from > > data caching, to data grids, to in-memory SQL data stores, to HPC, to > > streaming > > processing. > > > > With expensive and proprietary in-memory computing products from companies > > like > > Oracle, SAP, Microsoft, and IBM - the developers worldwide need an > > unhindered > > access to advanced open source in-memory software technology, the technology > > they can trust to develop with and deploy for critical applications. > > Current > > Status > > > > Apache Silk will be based on the technology that is currently developed by > > GridGain Systems and available under Apache 2.0 license > > (http://www.gridgain.org). The software has been in development since 2007 > > and > > in production since 2009. It is currently used by over 500 production > > deployments with over 1,000,000 downloads to date, and with over 20,000,000 > > GridGain nodes started in
Re: [PROPOSAL] Silk as new Incubator project
I have addressed sebb's note on the user list and removed it from the resource section. Also, the proposal was renamed to Ignite and new page is available under https://wiki.apache.org/incubator/IgniteProposal Thanks for the input everyone, Cos On Thu, Sep 18, 2014 at 09:40PM, Konstantin Boudnik wrote: > I would like to propose Silk as an Apache Incubator project. The new > proposal is added to https://wiki.apache.org/incubator/SilkProposal and > is duplicated below. > > -- > Regards, > Cos > > > = Silk Apache Incubator Proposal = > > == Abstract == > > Apache Silk will be a unified In-Memory Data Fabric providing > high-performance, > distributed in-memory data management software layer between various data > sources and user applications. > > == Proposal == > > Apache Silk is written mostly in Java and Scala with small amount of C++ code > and will initially combine the following technologies under one unified > umbrella: > * In-Memory Data Grid > * In-Memory Compute Grid > * In-Memory Streaming Processing > This unified in-memory fabric will provide high-performance, distributed > in-memory software layer that sits in between various data sources and user > applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. > Applications > APIs will be available for Java (and Java-based scripting languages), Scala, > C++ and .NET (C#). > > GridGain Systems, Inc. submits this proposal to donate its Apache 2.0-licensed > open source project generally known as “GridGain In-Memory Computing > Platform”, > its source code, documentation, and websites to the Apache Software Foundation > (“ASF”) with the goal of extending the vibrant open source community around > this technology ultimately governed by “Apache Way”. Proposed Naming > > We have been advised by the ASF mentors that the name “Silk” may not be ideal > because the name may be too generic and may not pass ASF legal check. Here are > the alternatives that we have come up with and any of those will be acceptable > for the project pending the ASF legal green light: > * Apache Silk (preferable name) > * Apache Sylk > * Apache Memstor > * Apache Ignite > > == Background & Rationale == > > In-Memory Data Fabric is a natural and evolutionary consolidation of various > “in-memory technologies” from the last decade. From simple local caching > (JSR-107), to distributed caching, to data grids and databases, to streaming > and plug-n-play acceleration - the in-memory space has grown quite > dramatically. > > With rapid advances in NVRAM and significant price reduction of traditional > DRAM on one hand, and growing sophistication and demand for faster data > processing on another - many users of these silo-ed technologies and products > started to look for a “strategic approach” to in-memory - an in-memory data > fabric - that would provide suitable APIs for different types of payloads: > from > data caching, to data grids, to in-memory SQL data stores, to HPC, to > streaming > processing. > > With expensive and proprietary in-memory computing products from companies > like > Oracle, SAP, Microsoft, and IBM - the developers worldwide need an unhindered > access to advanced open source in-memory software technology, the technology > they can trust to develop with and deploy for critical applications. Current > Status > > Apache Silk will be based on the technology that is currently developed by > GridGain Systems and available under Apache 2.0 license > (http://www.gridgain.org). The software has been in development since 2007 and > in production since 2009. It is currently used by over 500 production > deployments with over 1,000,000 downloads to date, and with over 20,000,000 > GridGain nodes started in the last 5 years. > > == Initial Goals == > > The number one goal during ASF incubation will coalesce around building a true > active and vibrant community governed by the “Apache Way”. The initial > development goals for Silk primarily revolve around migrating the existing > code > base, documentation, and refactoring of the existing internal build, test & > release processes. We believe these initial goals are sufficiently difficult > to > be considered early milestones. > > Some of the specific initial goals include: > * Migrate the existing Silk code base to the ASF. > * Refactor development, testing, build and release processes to work in ASF. > * Attract developer and user interest in the new Apache Silk project. > * Road map the integration efforts with “sister” projects in ASF eco-system > like Storm and Spark. > * Incorporate externally developed features into the core Apache Silk > project. &
Re: [PROPOSAL] Silk as new Incubator project
Thanks Henry - great to have you! On Mon, Sep 22, 2014 at 11:15AM, Henry Saputra wrote: > Thanks for the response, Konstantin. > > Definitely glad to help as mentor. > I have added my name as one of the mentors in the list. > > Still love to see the "Relationships to other Apache projects section" > in the proposal. > > - Henry > > > > On Sun, Sep 21, 2014 at 6:59 PM, Konstantin Boudnik wrote: > > On Thu, Sep 18, 2014 at 10:21PM, Henry Saputra wrote: > >> Hi Cos, > >> > >> Looks like a good start of the proposal. > >> > >> How would this project relate to compare to existing ones like Apache > >> Spark, Storm, or Samza? > > > > The proposal will be updated shortly with these details. > > > >> Would love to have comparisons to existing ASF projects section to the > >> proposal. > >> > >> Also, would you guys mind adding or soliciting more mentors? > >> Seemed like most of initial committers have not been involved in ASF > >> yet so may need some help to adjust to Apache way. > > > > Good point, Henry! Would you consider investing a few cycles on your own and > > join the mentors for this proposal? Thanks in advance! > > > > Cos > > > >> > >> - Henry > >> > >> On Thu, Sep 18, 2014 at 9:40 PM, Konstantin Boudnik > >> wrote: > >> > I would like to propose Silk as an Apache Incubator project. The new > >> > proposal is added to https://wiki.apache.org/incubator/SilkProposal and > >> > is duplicated below. > >> > > >> > -- > >> > Regards, > >> > Cos > >> > > >> > > >> > = Silk Apache Incubator Proposal = > >> > > >> > == Abstract == > >> > > >> > Apache Silk will be a unified In-Memory Data Fabric providing > >> > high-performance, > >> > distributed in-memory data management software layer between various data > >> > sources and user applications. > >> > > >> > == Proposal == > >> > > >> > Apache Silk is written mostly in Java and Scala with small amount of C++ > >> > code > >> > and will initially combine the following technologies under one unified > >> > umbrella: > >> > * In-Memory Data Grid > >> > * In-Memory Compute Grid > >> > * In-Memory Streaming Processing > >> > This unified in-memory fabric will provide high-performance, distributed > >> > in-memory software layer that sits in between various data sources and > >> > user > >> > applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. > >> > Applications > >> > APIs will be available for Java (and Java-based scripting languages), > >> > Scala, > >> > C++ and .NET (C#). > >> > > >> > GridGain Systems, Inc. submits this proposal to donate its Apache > >> > 2.0-licensed > >> > open source project generally known as “GridGain In-Memory Computing > >> > Platform”, > >> > its source code, documentation, and websites to the Apache Software > >> > Foundation > >> > (“ASF”) with the goal of extending the vibrant open source community > >> > around > >> > this technology ultimately governed by “Apache Way”. Proposed Naming > >> > > >> > We have been advised by the ASF mentors that the name “Silk” may not be > >> > ideal > >> > because the name may be too generic and may not pass ASF legal check. > >> > Here are > >> > the alternatives that we have come up with and any of those will be > >> > acceptable > >> > for the project pending the ASF legal green light: > >> > * Apache Silk (preferable name) > >> > * Apache Sylk > >> > * Apache Memstor > >> > * Apache Ignite > >> > > >> > == Background & Rationale == > >> > > >> > In-Memory Data Fabric is a natural and evolutionary consolidation of > >> > various > >> > “in-memory technologies” from the last decade. From simple local caching > >> > (JSR-107), to distributed caching, to data grids and databases, to > >> > streaming > >> > and plug-n-play acceleration - the in-memory space has grown quite > >> > dramatically. > >> > > >> > With rapid advances in NVRAM and significant price reduction of
Re: [PROPOSAL] Silk as new Incubator project
Andrew, as far as I know Ignite has a component that works with Hadoop (HDFS) as a storage layer and that's pretty much all I could say about the declared dependency. Ignite doesn't require Hadoop to deliver any functionality, it doesn't provide any additions to Hadoop - HDFS is just yet another file system. Now, because Ignite is an In-Memory Data Fabric I am sure it does decent amount of caching to reduce IO overhead. It seems like an implementation detail to me, but do you think this needs to be added into the proposal? Thanks! Cos On Mon, Sep 22, 2014 at 08:34AM, Andrew Purtell wrote: > On Sun, Sep 21, 2014 at 6:59 PM, Konstantin Boudnik wrote: > > On Thu, Sep 18, 2014 at 10:21PM, Henry Saputra wrote: > >> Hi Cos, > >> > >> Looks like a good start of the proposal. > >> > >> How would this project relate to compare to existing ones like Apache > >> Spark, Storm, or Samza? > > > > The proposal will be updated shortly with these details. > > I browsed GridGain's website briefly, perhaps there could also be a > bit of detail in the proposal how it relates to the Apache Hadoop > project? > > > >> Would love to have comparisons to existing ASF projects section to the > >> proposal. > >> > >> Also, would you guys mind adding or soliciting more mentors? > >> Seemed like most of initial committers have not been involved in ASF > >> yet so may need some help to adjust to Apache way. > > > > Good point, Henry! Would you consider investing a few cycles on your own and > > join the mentors for this proposal? Thanks in advance! > > If you need more mentors, I'd be happy to volunteer. > > > > > > Cos > > > >> > >> - Henry > >> > >> On Thu, Sep 18, 2014 at 9:40 PM, Konstantin Boudnik > >> wrote: > >> > I would like to propose Silk as an Apache Incubator project. The new > >> > proposal is added to https://wiki.apache.org/incubator/SilkProposal and > >> > is duplicated below. > >> > > >> > -- > >> > Regards, > >> > Cos > >> > > >> > > >> > = Silk Apache Incubator Proposal = > >> > > >> > == Abstract == > >> > > >> > Apache Silk will be a unified In-Memory Data Fabric providing > >> > high-performance, > >> > distributed in-memory data management software layer between various data > >> > sources and user applications. > >> > > >> > == Proposal == > >> > > >> > Apache Silk is written mostly in Java and Scala with small amount of C++ > >> > code > >> > and will initially combine the following technologies under one unified > >> > umbrella: > >> > * In-Memory Data Grid > >> > * In-Memory Compute Grid > >> > * In-Memory Streaming Processing > >> > This unified in-memory fabric will provide high-performance, distributed > >> > in-memory software layer that sits in between various data sources and > >> > user > >> > applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. > >> > Applications > >> > APIs will be available for Java (and Java-based scripting languages), > >> > Scala, > >> > C++ and .NET (C#). > >> > > >> > GridGain Systems, Inc. submits this proposal to donate its Apache > >> > 2.0-licensed > >> > open source project generally known as “GridGain In-Memory Computing > >> > Platform”, > >> > its source code, documentation, and websites to the Apache Software > >> > Foundation > >> > (“ASF”) with the goal of extending the vibrant open source community > >> > around > >> > this technology ultimately governed by “Apache Way”. Proposed Naming > >> > > >> > We have been advised by the ASF mentors that the name “Silk” may not be > >> > ideal > >> > because the name may be too generic and may not pass ASF legal check. > >> > Here are > >> > the alternatives that we have come up with and any of those will be > >> > acceptable > >> > for the project pending the ASF legal green light: > >> > * Apache Silk (preferable name) > >> > * Apache Sylk > >> > * Apache Memstor > >> > * Apache Ignite > >> > > >> > == Background & Rationale == > >> > > >> > In-Memory Data Fabric is a natural and ev
Re: [PROPOSAL] Silk as new Incubator project
We have updated the proposal with the section of "Comparative analysis to relevant projects" which addresses the questions expressed below. Regards, Cos On Thu, Sep 18, 2014 at 10:21PM, Henry Saputra wrote: > Hi Cos, > > Looks like a good start of the proposal. > > How would this project relate to compare to existing ones like Apache > Spark, Storm, or Samza? > > Would love to have comparisons to existing ASF projects section to the > proposal. > > Also, would you guys mind adding or soliciting more mentors? > Seemed like most of initial committers have not been involved in ASF > yet so may need some help to adjust to Apache way. > > - Henry > > On Thu, Sep 18, 2014 at 9:40 PM, Konstantin Boudnik wrote: > > I would like to propose Silk as an Apache Incubator project. The new > > proposal is added to https://wiki.apache.org/incubator/SilkProposal and > > is duplicated below. > > > > -- > > Regards, > > Cos > > > > > > = Silk Apache Incubator Proposal = > > > > == Abstract == > > > > Apache Silk will be a unified In-Memory Data Fabric providing > > high-performance, > > distributed in-memory data management software layer between various data > > sources and user applications. > > > > == Proposal == > > > > Apache Silk is written mostly in Java and Scala with small amount of C++ > > code > > and will initially combine the following technologies under one unified > > umbrella: > > * In-Memory Data Grid > > * In-Memory Compute Grid > > * In-Memory Streaming Processing > > This unified in-memory fabric will provide high-performance, distributed > > in-memory software layer that sits in between various data sources and user > > applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. > > Applications > > APIs will be available for Java (and Java-based scripting languages), Scala, > > C++ and .NET (C#). > > > > GridGain Systems, Inc. submits this proposal to donate its Apache > > 2.0-licensed > > open source project generally known as “GridGain In-Memory Computing > > Platform”, > > its source code, documentation, and websites to the Apache Software > > Foundation > > (“ASF”) with the goal of extending the vibrant open source community around > > this technology ultimately governed by “Apache Way”. Proposed Naming > > > > We have been advised by the ASF mentors that the name “Silk” may not be > > ideal > > because the name may be too generic and may not pass ASF legal check. Here > > are > > the alternatives that we have come up with and any of those will be > > acceptable > > for the project pending the ASF legal green light: > > * Apache Silk (preferable name) > > * Apache Sylk > > * Apache Memstor > > * Apache Ignite > > > > == Background & Rationale == > > > > In-Memory Data Fabric is a natural and evolutionary consolidation of various > > “in-memory technologies” from the last decade. From simple local caching > > (JSR-107), to distributed caching, to data grids and databases, to streaming > > and plug-n-play acceleration - the in-memory space has grown quite > > dramatically. > > > > With rapid advances in NVRAM and significant price reduction of traditional > > DRAM on one hand, and growing sophistication and demand for faster data > > processing on another - many users of these silo-ed technologies and > > products > > started to look for a “strategic approach” to in-memory - an in-memory data > > fabric - that would provide suitable APIs for different types of payloads: > > from > > data caching, to data grids, to in-memory SQL data stores, to HPC, to > > streaming > > processing. > > > > With expensive and proprietary in-memory computing products from companies > > like > > Oracle, SAP, Microsoft, and IBM - the developers worldwide need an > > unhindered > > access to advanced open source in-memory software technology, the technology > > they can trust to develop with and deploy for critical applications. > > Current > > Status > > > > Apache Silk will be based on the technology that is currently developed by > > GridGain Systems and available under Apache 2.0 license > > (http://www.gridgain.org). The software has been in development since 2007 > > and > > in production since 2009. It is currently used by over 500 production > > deployments with over 1,000,000 downloads to date, and with over 20,000,000 > > GridGain nodes started in the las
Re: [PROPOSAL] Silk as new Incubator project
Hi David. I believe it will be needing a usual place to publish releases and perhaps some CI time-share on builds.apache.org, but I am sure the latter could be addressed by using different resources if it seems to be an issue. Regards, Cos On Fri, Sep 26, 2014 at 03:50PM, David Nalley wrote: > On Fri, Sep 19, 2014 at 12:40 AM, Konstantin Boudnik wrote: > > I would like to propose Silk as an Apache Incubator project. The new > > proposal is added to https://wiki.apache.org/incubator/SilkProposal and > > is duplicated below. > > > > Hi Cos: > > Are there any other resources that Ignite will likely need past the > wiki/bugtracker/vcs/website? > > --David > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [PROPOSAL] Silk as new Incubator project
I was thinking along the lines of having commits going to the dev@ list and when the traffic becomes heavier to open the commits@, but your approach might be better. I will update the proposal accordingly. Thanks! -- Take care, Konstantin (Cos) Boudnik 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. On Fri, Sep 26, 2014 at 8:53 PM, Henry Saputra wrote: > Cos, > > I believe you may also need commits@ list for all the commits > activities to the source repo. > > - Henry > > On Fri, Sep 26, 2014 at 8:36 PM, Konstantin Boudnik wrote: >> We have updated the proposal with the section of >> "Comparative analysis to relevant projects" >> >> which addresses the questions expressed below. >> >> Regards, >> Cos >> >> On Thu, Sep 18, 2014 at 10:21PM, Henry Saputra wrote: >>> Hi Cos, >>> >>> Looks like a good start of the proposal. >>> >>> How would this project relate to compare to existing ones like Apache >>> Spark, Storm, or Samza? >>> >>> Would love to have comparisons to existing ASF projects section to the >>> proposal. >>> >>> Also, would you guys mind adding or soliciting more mentors? >>> Seemed like most of initial committers have not been involved in ASF >>> yet so may need some help to adjust to Apache way. >>> >>> - Henry >>> >>> On Thu, Sep 18, 2014 at 9:40 PM, Konstantin Boudnik wrote: >>> > I would like to propose Silk as an Apache Incubator project. The new >>> > proposal is added to https://wiki.apache.org/incubator/SilkProposal and >>> > is duplicated below. >>> > >>> > -- >>> > Regards, >>> > Cos >>> > >>> > >>> > = Silk Apache Incubator Proposal = >>> > >>> > == Abstract == >>> > >>> > Apache Silk will be a unified In-Memory Data Fabric providing >>> > high-performance, >>> > distributed in-memory data management software layer between various data >>> > sources and user applications. >>> > >>> > == Proposal == >>> > >>> > Apache Silk is written mostly in Java and Scala with small amount of C++ >>> > code >>> > and will initially combine the following technologies under one unified >>> > umbrella: >>> > * In-Memory Data Grid >>> > * In-Memory Compute Grid >>> > * In-Memory Streaming Processing >>> > This unified in-memory fabric will provide high-performance, distributed >>> > in-memory software layer that sits in between various data sources and >>> > user >>> > applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. >>> > Applications >>> > APIs will be available for Java (and Java-based scripting languages), >>> > Scala, >>> > C++ and .NET (C#). >>> > >>> > GridGain Systems, Inc. submits this proposal to donate its Apache >>> > 2.0-licensed >>> > open source project generally known as “GridGain In-Memory Computing >>> > Platform”, >>> > its source code, documentation, and websites to the Apache Software >>> > Foundation >>> > (“ASF”) with the goal of extending the vibrant open source community >>> > around >>> > this technology ultimately governed by “Apache Way”. Proposed Naming >>> > >>> > We have been advised by the ASF mentors that the name “Silk” may not be >>> > ideal >>> > because the name may be too generic and may not pass ASF legal check. >>> > Here are >>> > the alternatives that we have come up with and any of those will be >>> > acceptable >>> > for the project pending the ASF legal green light: >>> > * Apache Silk (preferable name) >>> > * Apache Sylk >>> > * Apache Memstor >>> > * Apache Ignite >>> > >>> > == Background & Rationale == >>> > >>> > In-Memory Data Fabric is a natural and evolutionary consolidation of >>> > various >>> > “in-memory technologies” from the last decade. From simple local caching >>> > (JSR-107), to distributed caching, to data grids and databases, to >>> > streaming >>> > and plug-n-play acceler
[VOTE] Accept Ignite into the Apache Incubator
functional areas of Ignite. === Ignite vs. Hadoop === Apache Hadoop is a batch oriented data warehouse system. Ignite is a real-time, transactional In-Memory Data Fabric focused on real-time processing of operational data. In most cases, Hadoop acts as one of the “slower” datasources on top of which Ignite is typically deployed. == Initial Goals == The number one goal during ASF incubation will coalesce around building a true active and vibrant community governed by the “Apache Way”. The initial development goals for Ignite primarily revolve around migrating the existing code base, documentation, and refactoring of the existing internal build, test & release processes. We believe these initial goals are sufficiently difficult to be considered early milestones. Some of the specific initial goals include: * Migrate the existing Ignite code base to the ASF. * Refactor development, testing, build and release processes to work in ASF. * Attract developer and user interest in the new Apache Ignite project. * Road map the integration efforts with “sister” projects in ASF eco-system like Storm and Spark. * Incorporate externally developed features into the core Apache Ignite project. == Known Risks == This proposal is not without its risks, some of which are outlined below. The current list of committers are primarily from GridGain Systems. One of the key purposes of proposing Ignite for incubation is to attract new committers and spur the adoption of Ignite. The ASF has a well-deserved reputation of fostering and building open source communities, which makes it the ideal location to attempt this community bootstrap. Most of the initial committers are supported by their employers to work on Ignite, and may be assigned to work on other priorities. However, the employers of these salaried individuals - GridGain Systems or current customers and users - have a vested interest in seeing Ignite thrive as a long-term, growing project. GridGain Systems understands that their employees are acting as individuals when contributing to Apache projects. As a major initial contributor GridGain Systems is prepared to bring additional staff on board to assist with Ignite development to ensure its active growth. One of the key motivators in creating the Ignite project as part of the Incubator is to leverage the vendor-neutral nature of the ASF. The ASF has a strong and recognized brand as being a leader in open source, and by hosting Ignite at the ASF, we hope to attract developers to build a viable community for the project. == Meritocracy == Apache Ignite plans to adopt the policy that encourages an environment that supports a meritocracy. We intend to actively ask the community for help, listing/specifying the work that needs to be done, and keeping track of and encouraging members of the community who make any contributions. Community & Core Developers GridGain project has been actively building community of users in the last couple of years with an active StackOverflow group, support groups, and Meetups (http://www.meetup.com/Bay-Area-In-Memory-Computing). This group includes active members of Apache community as well. We strongly believe that this community will grow and develop substantially as part of Apache family and that’s our commitment. == Existing Documentation == Current documentation for GridGain project can be found here: http://www.gridgain.org/documentation/ We intend to migrate it into ASF podling. == Initial Source == Initial Apache 2.0 licensed source code can be found here: http://www.gridgain.org/download/ == External Dependencies == Here’s the list of 3rd party JAR-only dependencies: * Apache Hadoop * Apache Commons * H2 * JTS * Apache Lucene * Spring Here’s the list of the all licenses for 3rd party libraries currently used: * Apache 2.0 == Required Resources == === Mailing lists === * priv...@ignite.incubator.apache.org (with moderated subscriptions) * d...@ignite.incubator.apache.org * commi...@ignite.incubator.apache.org === Git & JIRA === * Git: https://git-wip-us.apache.org/repos/asf/incubator-ignite.git * JIRA: JIRA Ignite (IGNITE) == Initial Committers & Affiliation == * Dmitriy Setrakyan (GridGain Systems, dsetrakyan at gridgain dot com) * Yakov Zhdanov (GridGain Systems, yzhdanov at gridgain dot com) * Alexey Goncharuk (GridGain Systems, agoncharuk at gridgain dot com) * Sergey Vladykin (GridGain Systems, svladykin at gridgain dot com) * Valentin Kulichenko (GridGain Systems, vkulichenko at gridgain dot com) * Semen Boikov (GridGain Systems, sboikov at gridgain dot com) * Vladimir Ozerov (GridGain Systems, vozerov at gridgain dot com) * Nikita Ivanov (GridGain Systems, nivanov30 at gmail dot com) * Sergey Khisamov (FitechSource, skh at gmail dot com) * Ilya Sterin (ChronoTrack, isterin at gmail dot com) * Ryan Rawson (WANdisco, rawson at apache dot org) * Konstantin Boudnik (WANdisco, cos at apache dot org) * Roman Shaposh
[RESULT] Accept Ignite into the Apache Incubator (Was: VOTE)
The vote has passed with 6 binding +1 votes, 1 non-binding +1, and no +0 or -1 votes. Binding (+1) Branko Čibej Jan Iversen Henry Saputra Roman Shaposhnik Michael Stack Konstantin Boudnik Non-binding (+1) P. Taylor Goetz We will be carrying on to the the next steps under the normal IPMC rules. Thanks everyone who voted! -- with regards, Konstantin (Cos) Boudnik 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. On Tue, Sep 30, 2014 at 11:04 PM, Stack wrote: > +1 from me (mentor, binding). > St.Ack > > On Sat, Sep 27, 2014 at 5:58 PM, Konstantin Boudnik wrote: > >> I would like to call a vote for accepting "Apache Ignite" for Apache >> Incubator. >> The full proposal is available below. We ask the IPMC to sponsor it, with >> cos >> as Champion, and stack, rvs, cos, hsaputra and brane volunteering to be >> Mentors. >> >> Please cast your vote: >> >> [ ] +1, bring Iginite into Incubator >> [ ] +0, I don't care either way, >> [ ] -1, do not bring Iginite into Incubator, because... >> >> This vote will be open for 72 hours and only votes from the Incubator >> PMC are binding. >> >> http://wiki.apache.org/incubator/IgniteProposal >> >> Proposal text from the wiki: >> ## page was renamed from SilkProposal >> = Ignite Apache Incubator Proposal = >> == Abstract == >> Apache Ignite will be a unified In-Memory Data Fabric providing >> high-performance, distributed in-memory data management software layer >> between >> various data sources and user applications. >> >> == Proposal == >> Apache Ignite is written mostly in Java and Scala with small amount of C++ >> code >> and will initially combine the following technologies under one unified >> umbrella: >> >> * In-Memory Data Grid >> * In-Memory Compute Grid >> * In-Memory Streaming Processing >> >> This unified in-memory fabric will provide high-performance, distributed >> in-memory software layer that sits in between various data sources and user >> applica tions. Data sources can include SQL RDBMS, NoSQL, or HDFS. >> Applications >> APIs will be available for Java (and Java-based scripting languages), >> Scala, >> C++ and .NET (C#). >> >> GridGain Systems, Inc. submits this proposal to donate its Apache >> 2.0-licensed >> open source project generally known as “GridGain In-Memory Computing >> Platform”, >> its source code, documentation, and websites to the Apache Software >> Foundation >> (“ASF”) with the goal of extending the vibrant open source community around >> this technology ultimately governed by “Apache Way”. Proposed Naming >> >> We have been advised by the ASF mentors that the name “Ignite” may not be >> ideal >> because the name may be too generic and may not pass ASF legal check. Here >> are >> the alternatives that we have come up with and any of those will be >> acceptable >> for the project pending the ASF legal green light: >> >> * Apache Silk (preferable name) >> * Apache Sylk >> * Apache Memstor >> * Apache Ignite >> >> == Background & Rationale == >> In-Memory Data Fabric is a natural and evolutionary consolidation of >> various >> “in-memory technologies” from the last decade. From simple local caching >> (JSR-107), to distributed caching, to data grids and databases, to >> streaming >> and plug-n-play acceleration - the in-memory space has grown quite >> dramatically. >> >> With rapid advances in NVRAM and significant price reduction of traditional >> DRAM on one hand, and growing sophistication and demand for faster data >> processing on another - many users of these silo-ed technologies and >> products >> started to look for a “strategic approach” to in-memory - an in-memory data >> fabric - that would provide suitable APIs for different types of payloads: >> from >> data caching, to data grids, to in-memory SQL data stores, to HPC, to >> streaming >> processing. >> >> With expensive and proprietary in-memory computing products from companies >> like >> Oracle, SAP, Microsoft, and IBM - the developers worldwide need an >> unhindered >> access to advanced open source in-memory software technology, the >> technology >> they can trust to develop with and deploy for critical applications. >> Current >> Status >> >> Apache I
Re: [PROPOSAL] Apache Spark for the Incubator
Great news!
Definitely +1 (non-binding, I guess) on adding Spark to the family
of ASF project!
I also express the interest to contribute to the project and move it forward
to the graduation! Bigtop has been packaging and providing Spark as a part of
Hadoop 1.x software stacks for some time; and hopefully would be able to offer
it as a part of Hadoop 2.x line in the coming days.
Dr. Konstantin Boudnik
Hadoop committer
BigTop PMC
On Fri, May 31, 2013 at 06:03PM, Mattmann, Chris A (398J) wrote:
> Hi Folks,
>
> I'm pleased to bring you a proposal to the Apache Incubator for the Apache
> Spark project: https://wiki.apache.org/incubator/SparkProposal
>
> The work originates from the Berkeley AMPLab and through a number of
> industry
> participants, and other institutions. Spark is a framework for large-scale
> data
> analysis on clusters, with a particular focus on low latency operations.
> The
> source code is written in Scala, and provides a number of APIs and bindings
> in various programming languages.
>
> The proposal text is copied to the bottom of this email. I'm going to leave
> this thread open for the next week for discussion. Once it's died down,
> I'll
> call an official VOTE.
>
> Suresh, Ross G. -- heads up -- this project may be of interest to you both
> and would welcome you guys as additional mentors. We currently have 3
> mentors
> committed to the project, but would love to have more. People interested in
> contributing should declare their interest here on the general@incubator
> thread
> and those potential contributors will be discussed by the incoming Spark
> community.
>
> Questions -- let's hear em'! :)
>
> Cheers,
> Chris
> ("Champion", incoming Apache Spark)
>
> === Abstract ===
> Spark is an open source system for large-scale data analysis on clusters.
>
> === Proposal ===
> Spark is an open source system for fast and flexible large-scale data
> analysis. Spark provides a general purpose runtime that supports
> low-latency execution in several forms. These include interactive
> exploration of very large datasets, near real-time stream processing, and
> ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
> with HDFS, HBase, Cassandra and several other storage storage layers, and
> exposes APIs in Scala, Java and Python.
> Background
> Spark started as U.C. Berkeley research project, designed to efficiently
> run machine learning algorithms on large datasets. Over time, it has
> evolved into a general computing engine as outlined above. Spark╧s
> developer community has also grown to include additional institutions,
> such as universities, research labs, and corporations. Funding has been
> provided by various institutions including the U.S. National Science
> Foundation, DARPA, and a number of industry sponsors. See:
> https://amplab.cs.berkeley.edu/sponsors/ for full details.
>
> === Rationale ===
> As the number of contributors to Spark has grown, we have sought for a
> long-term home for the project, and we believe the Apache foundation would
> be a great fit. Spark is a natural fit for the Apache foundation: Spark
> already interoperates with several existing Apache projects (HDFS, HBase,
> Hive, Cassandra, Avro and Flume to name a few). The Spark team is familiar
> with the Apache process and and subscribes to the Apache mission - the
> team includes multiple Apache committers already. Finally, joining Apache
> will help coordinate the development effort of the growing number of
> organizations which contribute to Spark.
>
> == Initial Goals ==
> The initial goals will most likely be to move the existing codebase to
> Apache and integrate with the Apache development process. Furthermore, we
> plan for incremental development, and releases along with the Apache
> guidelines.
>
> === Current Status ===
> == Meritocracy ==
> The Spark project already operates on meritocratic principles. Today,
> Spark has several developers and has accepted multiple major patches from
> outside of U.C. Berkeley. While this process has remained mostly informal
> (we do not have an official committer list), an implicit organization
> exists in which individuals who contribute major components act as
> maintainers for those modules. If accepted, the Spark project would
> include several of these participants as committers from the onset. We
> will work to identify all committers and PPMC members for the project and
> to operate under the ASF meritocratic principles.
>
> === Community ===
> Acceptance into the Apache foundation would bolster the already strong
> user and developer community around Spark. That community includes dozens
> of contributors from se
Re: [PROPOSAL] Apache Spark for the Incubator
That makes sense. Thanks for the update - I am still catching up on my emails
backed up because of the Hadoop summit.
Cos
On Tue, Jun 04, 2013 at 01:44AM, Mattmann, Chris A (398J) wrote:
> Dear Konstantin,
>
> Thanks! The incoming Spark project is excited about the relationship
> with Bigtop that could happen here.
>
> As for new committers, after conferring with the Spark project
> members, we would like to adopt a simple policy of having all new
> committers not add themselves to the wiki as of yet, but simply
> join the project mailing lists when they are created, and then from
> there, contribute. I and other mentors, and the Spark community are
> committed to being inclusive, so hopefully won't take too long for
> anybody to become a PPMC member/committer on the project after some
> demonstrated contributions.
>
> Thanks for your interest and again for your kind words.
>
> 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: Konstantin Boudnik
> Reply-To: "general@incubator.apache.org"
> Date: Friday, May 31, 2013 12:29 PM
> To: "general@incubator.apache.org"
> Subject: Re: [PROPOSAL] Apache Spark for the Incubator
>
> >Great news!
> >
> >Definitely +1 (non-binding, I guess) on adding Spark to the family
> >of ASF project!
> >
> >I also express the interest to contribute to the project and move it
> >forward
> >to the graduation! Bigtop has been packaging and providing Spark as a
> >part of
> >Hadoop 1.x software stacks for some time; and hopefully would be able to
> >offer
> >it as a part of Hadoop 2.x line in the coming days.
> >
> >Dr. Konstantin Boudnik
> > Hadoop committer
> > BigTop PMC
> >
> >On Fri, May 31, 2013 at 06:03PM, Mattmann, Chris A (398J) wrote:
> >> Hi Folks,
> >>
> >> I'm pleased to bring you a proposal to the Apache Incubator for the
> >>Apache
> >> Spark project: https://wiki.apache.org/incubator/SparkProposal
> >>
> >> The work originates from the Berkeley AMPLab and through a number of
> >> industry
> >> participants, and other institutions. Spark is a framework for
> >>large-scale
> >> data
> >> analysis on clusters, with a particular focus on low latency operations.
> >> The
> >> source code is written in Scala, and provides a number of APIs and
> >>bindings
> >> in various programming languages.
> >>
> >> The proposal text is copied to the bottom of this email. I'm going to
> >>leave
> >> this thread open for the next week for discussion. Once it's died down,
> >> I'll
> >> call an official VOTE.
> >>
> >> Suresh, Ross G. -- heads up -- this project may be of interest to you
> >>both
> >> and would welcome you guys as additional mentors. We currently have 3
> >> mentors
> >> committed to the project, but would love to have more. People
> >>interested in
> >> contributing should declare their interest here on the general@incubator
> >> thread
> >> and those potential contributors will be discussed by the incoming Spark
> >> community.
> >>
> >> Questions -- let's hear em'! :)
> >>
> >> Cheers,
> >> Chris
> >> ("Champion", incoming Apache Spark)
> >>
> >> === Abstract ===
> >> Spark is an open source system for large-scale data analysis on
> >>clusters.
> >>
> >> === Proposal ===
> >> Spark is an open source system for fast and flexible large-scale data
> >> analysis. Spark provides a general purpose runtime that supports
> >> low-latency execution in several forms. These include interactive
> >> exploration of very large datasets, near real-time stream processing,
> >>and
> >> ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
> >> with HDFS, HBase, Cassandra and several other storage storage layers,
>
Re: [PROPOSAL] Bigtop for the Apache Incubator
> On 14/06/11 05:26, Tom White wrote: > > Hi, > > > > I would like to propose Bigtop to be an Apache Incubator project. > > Bigtop is a project for the development of packaging and tests of the > > Hadoop ecosystem. The goal is to do testing at various levels > > (packaging, platform, runtime, upgrade, etc...) developed by a > > community with a focus on the system as a whole, rather than > > individual projects. > > > > Here's a link to the proposal on the wiki > > http://wiki.apache.org/incubator/BigtopProposal > > > > I've also included the initial contents below. > > > > Cheers, > > Tom > > > > I've added my name to the committer list, I won't be working on this in > much/any of work time, and am fairly overcommitted, so don't expect that > much. I can contribute some of my experience in VM setup/teardown for > testing RPM installations, and how to do functional testing of > dynamically created Hadoop clusters. I am going to add my name to the list of the committers too. Considering my other commitments I might not be able to work much on this project, but I guess the fact that I have wrote like 50% of the underlying system framework might count for something. Cos - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Bigtop for the Apache Incubator
Steve, On Tue, Jun 14, 2011 at 4:51 AM, Steve Loughran wrote: > I've added more on the limitations of the current process (not synchronised > releases, not enough automated testing on multiple-host clusters), and on a actually there's a stand-alone Hudson job in Apache https://builds.apache.org/hudson/view/G-L/view/Hadoop/job/Hadoop-22-cluster-test/ which does exactly that: testing 0.22 against a cluster deployed from every build (deployed automatically as well). The job is using a different system harness https://github.com/c0s/v4stack though, because the framework proposed here was pulled out from public access (e.g. from github) for whatever reason. Technically, speaking the commnunity could've benefit from a large set of automated cluster tests for months now. I guess late is better than never ;) Cos > risk of the project: the upstream projects need to care about and work on > more synchronized releases. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Bigtop for the Apache Incubator
Tom, Looking through the proposal with a bit more attention I've noticed that initial source code linked in here https://github.com/cloudera/bigtop refers to iTest framework as the foundation of BigTop testing. However, iTest repository at github.com/cloudera/iTest isn't available? Will it be available along with the rest of the code or it isn't opened to the public? A error in the document? What's the deal there? I believe it'd be beneficial for the community to be able to see the source code of the testing engine. Please correct me if I'm wrong though ;) -- ═ Thanks, Konstantin (Cos) Boudnik 2CAC 8312 4870 D885 8616 ═6115 220F 6980 1F27 E622 Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. On Tue, Jun 14, 2011 at 11:43, Konstantin Boudnik wrote: >> On 14/06/11 05:26, Tom White wrote: >> > Hi, >> > >> > I would like to propose Bigtop to be an Apache Incubator project. >> > Bigtop is a project for the development of packaging and tests of the >> > Hadoop ecosystem. The goal is to do testing at various levels >> > (packaging, platform, runtime, upgrade, etc...) developed by a >> > community with a focus on the system as a whole, rather than >> > individual projects. >> > >> > Here's a link to the proposal on the wiki >> > http://wiki.apache.org/incubator/BigtopProposal >> > >> > I've also included the initial contents below. >> > >> > Cheers, >> > Tom >> > >> >> I've added my name to the committer list, I won't be working on this in >> much/any of work time, and am fairly overcommitted, so don't expect that >> much. I can contribute some of my experience in VM setup/teardown for >> testing RPM installations, and how to do functional testing of >> dynamically created Hadoop clusters. > > I am going to add my name to the list of the committers too. Considering my > other commitments I might not be able to work much on this project, but I > guess > the fact that I have wrote like 50% of the underlying system framework > might count for something. > > Cos > > - > 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] Bigtop for the Apache Incubator
Oh, I see. Looks like a dangling links indeed... Thanks for pointing out. Cos On Thu, Jun 16, 2011 at 05:32PM, Roman Shaposhnik wrote: > Hi Cos, > > On Thu, Jun 16, 2011 at 5:21 PM, Konstantin Boudnik wrote: > > However, iTest repository at github.com/cloudera/iTest isn't > > available? Will it be available along with the rest of the code or it > > isn't opened to the public? A error in the document? What's the deal there? > > I > > believe it'd be beneficial for the community to be able to see the source > > code > > of the testing engine. Please correct me if I'm wrong though ;) > > iTest is now part of bigtop and resides under test/src/itest-common: > https://github.com/cloudera/bigtop/tree/master/test/src/itest-common > > So in that sense it is there, but not as a separate project. The original > documentation for iTest is available under this link: >http://cloudera.github.com/bigtop/iTest/ > > And it looks like there are could be a couple of dangling links there still > pointing to where iTest used to be on GitHub as a separate repository. > > Thanks, > Roman. > > - > 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] Bigtop for the Apache Incubator
Oh, I see. Looks like a dangling links indeed... Thanks for pointing out. On Thu, Jun 16, 2011 at 05:32PM, Roman Shaposhnik wrote: > Hi Cos, > > On Thu, Jun 16, 2011 at 5:21 PM, Konstantin Boudnik wrote: > > However, iTest repository at github.com/cloudera/iTest isn't > > available? Will it be available along with the rest of the code or it > > isn't opened to the public? A error in the document? What's the deal there? > > I > > believe it'd be beneficial for the community to be able to see the source > > code > > of the testing engine. Please correct me if I'm wrong though ;) > > iTest is now part of bigtop and resides under test/src/itest-common: > https://github.com/cloudera/bigtop/tree/master/test/src/itest-common > > So in that sense it is there, but not as a separate project. The original > documentation for iTest is available under this link: >http://cloudera.github.com/bigtop/iTest/ > > And it looks like there are could be a couple of dangling links there still > pointing to where iTest used to be on GitHub as a separate repository. > > Thanks, > Roman. > > - > 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] Bigtop for the Apache Incubator
Tom, Looking through the proposal with a bit more attention I've noticed that initial source code linked in here https://github.com/cloudera/bigtop refers to iTest framework as the foundation of BigTop testing. However, iTest repository at github.com/cloudera/iTest isn't available? Will it be available along with the rest of the code or it isn't opened to the public? What's the deal there? I believe it'd be beneficial for the community to be able to see the source code of the testing engine. Please correct me if I'm wrong though ;) -- Thanks, Konstantin (Cos) Boudnik 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. On Tue, Jun 14, 2011 at 11:43, Konstantin Boudnik wrote: >> On 14/06/11 05:26, Tom White wrote: >> > Hi, >> > >> > I would like to propose Bigtop to be an Apache Incubator project. >> > Bigtop is a project for the development of packaging and tests of the >> > Hadoop ecosystem. The goal is to do testing at various levels >> > (packaging, platform, runtime, upgrade, etc...) developed by a >> > community with a focus on the system as a whole, rather than >> > individual projects. >> > >> > Here's a link to the proposal on the wiki >> > http://wiki.apache.org/incubator/BigtopProposal >> > >> > I've also included the initial contents below. >> > >> > Cheers, >> > Tom >> > >> >> I've added my name to the committer list, I won't be working on this in >> much/any of work time, and am fairly overcommitted, so don't expect that >> much. I can contribute some of my experience in VM setup/teardown for >> testing RPM installations, and how to do functional testing of >> dynamically created Hadoop clusters. > > I am going to add my name to the list of the committers too. Considering my > other commitments I might not be able to work much on this project, but I > guess > the fact that I have wrote like 50% of the underlying system framework > might count for something. > > Cos > > - > 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] Bigtop for the Apache Incubator
Oh, I see. Looks like a dangling links indeed... Thanks for pointing out. On Thu, Jun 16, 2011 at 05:32PM, Roman Shaposhnik wrote: > Hi Cos, > > On Thu, Jun 16, 2011 at 5:21 PM, Konstantin Boudnik wrote: > > However, iTest repository at github.com/cloudera/iTest isn't > > available? Will it be available along with the rest of the code or it > > isn't opened to the public? A error in the document? What's the deal there? > > I > > believe it'd be beneficial for the community to be able to see the source > > code > > of the testing engine. Please correct me if I'm wrong though ;) > > iTest is now part of bigtop and resides under test/src/itest-common: > https://github.com/cloudera/bigtop/tree/master/test/src/itest-common > > So in that sense it is there, but not as a separate project. The original > documentation for iTest is available under this link: >http://cloudera.github.com/bigtop/iTest/ > > And it looks like there are could be a couple of dangling links there still > pointing to where iTest used to be on GitHub as a separate repository. > > Thanks, > Roman. > > - > 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] Bigtop for the Apache Incubator
Oh, I see. Looks like a dangling links indeed... Thanks for pointing out. On Thu, Jun 16, 2011 at 05:32PM, Roman Shaposhnik wrote: > Hi Cos, > > On Thu, Jun 16, 2011 at 5:21 PM, Konstantin Boudnik wrote: > > However, iTest repository at github.com/cloudera/iTest isn't > > available? Will it be available along with the rest of the code or it > > isn't opened to the public? A error in the document? What's the deal there? > > I > > believe it'd be beneficial for the community to be able to see the source > > code > > of the testing engine. Please correct me if I'm wrong though ;) > > iTest is now part of bigtop and resides under test/src/itest-common: > https://github.com/cloudera/bigtop/tree/master/test/src/itest-common > > So in that sense it is there, but not as a separate project. The original > documentation for iTest is available under this link: >http://cloudera.github.com/bigtop/iTest/ > > And it looks like there are could be a couple of dangling links there still > pointing to where iTest used to be on GitHub as a separate repository. > > Thanks, > Roman. > > - > 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] PhoneGap for Apache Incubator
Wow, great stuff to have in OSS! I would love to contribute to the project. Cos On Fri, Sep 30, 2011 at 04:57PM, Brian LeRoux wrote: > Hi everyone, > > I would like to propose PhoneGap to be an Apache Incubator project. > (Under the new, still proposed name, Apache Callback.) > > Here's a link to the proposal in the current PhoneGap wiki: > http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal > > Thank you! > Brian > > - > 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] BOM and supported platforms for Bigtop 0.4.0
On Fri, May 04, 2012 at 11:02AM, Patrick Hunt wrote: > On Fri, May 4, 2012 at 9:47 AM, Owen O'Malley wrote: > > On Fri, May 4, 2012 at 8:58 AM, Patrick Hunt wrote: > >> It's not the job of the incubator to create new rules, but rather to > >> help podlings to graduation while following existing Apache > >> guidelines. > > > > We aren't making new rules. We are trying to help the Bigtop project > > understand the rules about not releasing non-Apache software. There is > > a huge difference between depending on an artifact from another > > project and building and distributing non-Apache rpms in the project's > > /dist directory. > > They are not releasing non-Apache software. They are not forking an > existing project. Bigtop's release artifact will contain packaging > code which allows users to compile packages (deb, rpm, etc...) for > this ASL licensed component, not the source/binaries of the component > itself. Thank you Patrick to bringing this back again! It seems that this point keeps dropping on the floor all the time. BigTop releases are merely a source code for tools to produce and validate the integrity of software stacks. Let's keep in mind at the next round of deliberations. Packages are secondary and can be stored someplace else, because really anyone can produce them with ease using BigTop. If someone dislike component-A for one reason or another - it is easy to remote it from a particular release's BOM file. Cos > >> It's very clear from > >> http://www.apache.org/legal/resolved.html that what has been proposed > >> is acceptable under existing Apache rules. > > > > Can you find a single instance other than the disagreement between > > Apache Lucene and Apache Commons where one project is distributing > > another project's rpms? Are there any other non-Apache rpms in /dist? > > Clearly the answer is a resounding NO. It would be a huge violation of > > the trust the incubator is putting in me as a mentor if I didn't block > > Bigtop's plan to do so. > > If the component made an objection to being included in Bigtop then I > could see an argument to be made, that's not the case here. The > opposite is true from what I've seen -- people want their software to > be included so that users can more easily consume it. That's why they > released their software under a less restrictive license in the first > place. > > EOD existing Apache rules/license make no such distinction. "Works > under the following licenses may be included within Apache products" > (includes ASL). > > Patrick signature.asc Description: Digital signature
Re: Reform of Incubator
On Tue, Aug 04, 2015 at 02:50PM, Joe Brockmeier wrote: > On 08/04/2015 02:45 PM, Konstantin Boudnik wrote: > > Sorry if it rubs the wrong way. However, we just have seen through the > > Ignite > > discussion (most recent one) the examples where personal expectations were > > represented as graduation requirements. It is perhaps in good faith - I am > > not > > questioning the intention. I am saying that when requirements are unclear, > > people interpret them based on their own understanding of unwritten Apache > > ethos. As Brane called it earlier - "confusing opinions and policies". You > > see > > where I am going with this, right? > > Perhaps I'm unclear on the proposal - but how would that be mitigated by > this proposal? I understand that it might expose podlings to less of > this when directed towards the full IPMC for graduation, but how would > it prevent this if a mentor confuses personal expectations for > graduation requirements? > > Isn't that still a potential issue? You're right, it still might be an issue. My vision was that with a reduced involvement of the IPMC namely - IPMC delegating more day-to-day oversight of the podlings to the mentors - release votes just Cc'ed to general@ instead of an explicit IPMC vote. It doesn't contradict the requirement of the binding votes, but the primarily would be coming from mentors, I believe - more precise graduation guidelines, eg w/o moot 'diversity'-like points the environment will be less accommodating for such confusions and would cause lesser number of complex debates. This, in turn, will make the incubation process more transparent and less counter-intuitive for newcomers. Hopefully it clarifies my point a bit better. What do you think? Cos > I may misunderstand or have lost track of how that's handled in all the > discussion. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator
Sorry if it rubs the wrong way. However, we just have seen through the Ignite discussion (most recent one) the examples where personal expectations were represented as graduation requirements. It is perhaps in good faith - I am not questioning the intention. I am saying that when requirements are unclear, people interpret them based on their own understanding of unwritten Apache ethos. As Brane called it earlier - "confusing opinions and policies". You see where I am going with this, right? Cos On Tue, Aug 04, 2015 at 08:56AM, Julian Hyde wrote: > Cos, > > There is no "bureaucratism outbreak". People are not "express[ing] > their expectations as a law-of-the-land". People are trying, in good > faith, to make sure that decisions are made consistent with the Apache > ethos. And before you ask, no, that ethos cannot be written down; it > has to be interpreted via debate. This is what debate sounds like. > > Julian > > > On Mon, Aug 3, 2015 at 9:03 PM, Konstantin Boudnik wrote: > > On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote: > >> On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz > >> wrote: > >> > On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik > >> > wrote: > >> >> ...who else thinks the movement towards empowering > >> >> PPMCs and making IPMC very much like the board makes sense?... > >> > > >> > How is that different from the status quo where a podling with active > >> > mentors can have their releases +1ed by their mentors, requiring > >> > minimal interaction with the IPMC? > >> > >> I think it is more of a bias issue. IOW, today it seems that the default > >> bias > >> of IPMC is to consider itself a final authority (or a gatekeeper) on > >> podling > >> releases. We need to break that bias and make it so that it is truly a > >> safety > >> net, rather than a gatekeeper. > >> > >> IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE] > >> emails, not [VOTE]. > > > > We perhaps are observing the well known phenomena called self-selection bias > > [1] And it seems to me that the simplification and better clarification of > > the > > incubation guidelines might be exactly what's needed to prevent a > > bureaucratism outbreak. As well as the situation when ppl express their > > expectations as a law-of-the-land (even from best intentions). > > > > Cos > > > > - > 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] Graduate Apache Usergrid from the Incubator
+1 (binding) Good luck! Cos On Mon, Aug 10, 2015 at 04:15PM, Dave wrote: > The Usergrid project has made three releases from the Incubator (1.0.0, > 1.0.1 and 1.0.2), has added multiple and diverse committers, and the > project has completed all required items on the graduation check-list [1]. > Consensus appears to be ([2] and [3]) that the project is ready to graduate > and so I'm calling this vote and sharing the Usergrid Top Level Project > Resolution (see below). > > The vote will run for 72 hours, ending 3pm EST Thursday Aug 13, 2015. > Everyone in the Usergrid and Incubator communities is invited and > encouraged to vote, although only PPMC votes are binding > > [ ] +1 Graduate Apache Usergrid from the Incubator. > [ ] +0 Don't care. > [ ] -1 Don't graduate Apache Usergrid from the Incubator because ... > > Here's my binding vote: +1. > > Thanks, > Dave > > [1] http://incubator.apache.org/projects/usergrid.html > [2] Dev list discussion: > http://mail-archives.apache.org/mod_mbox/incubator-usergrid-dev/201507.mbox/%3CCAF1aazBvhYD3ZM_nKDDbrwO%3D4y6d%2BR1nH1M-2FWc9GZNuPtAjw%40mail.gmail.com%3E > [3] Incubator discussion: > http://mail-archives.apache.org/mod_mbox/incubator-general/201508.mbox/%3CCAF1aazCBCKNNYGT42%2BuGo%3DAdMb9uLkBrEm04rWj2tPe5LG%2BE9A%40mail.gmail.com%3E > > > Apache Usergrid top-level project resolution: > >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 related to the Usergrid BaaS software, >for distribution at no charge to the public. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management >Committee (PMC), to be known as the "Apache Usergrid Project", >be and hereby is established pursuant to Bylaws of the >Foundation; and be it further > >RESOLVED, that the Apache Usergrid Project be and hereby is >responsible for the creation and maintenance of open-source >software related to the Usergrid BaaS software; and be it further > >RESOLVED, that the office of "Vice President, Usergrid" 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 Usergrid Project, and to have primary responsibility for >management of the projects within the scope of responsibility >of the Apache Usegrid 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 Usegrid Project: > >* Tim Anglade >* Askhat Asanaliev >* John D. Ament >* Ed Anuff >* Furkan Bıçak >* Ryan Bridges >* Jake Farrell >* Scott Ganyo >* Sungju Jin >* Dave Johnson >* Alex Karasulu >* Salih Kardan >* Jim Jagielski >* Shaozhuang Liu >* Nate McCall >* John Mcgibbney >* Alex Muramoto >* Todd Nine >* Luciano Resende >* Yiğit Şaplı >* Rod Simpson >* Jeff West > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Todd Nine >be appointed to the office of Vice President, Usergrid, 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 Usergrid Project be and hereby >is tasked with the migration and rationalization of the Apache >Incubator Usegrid podling; and be it further > >RESOLVED, that all responsibility pertaining to the Apache >Incubator Usergrid podling encumbered upon the Apache Incubator >PMC are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: September 2015 Report
I have just updated the podlings.xml to reflect that Ignite has graduated. So
they won't be reporting as a part of Incubator any more.
Thanks,
Cos
On Sat, Aug 29, 2015 at 08:58AM, jan i wrote:
> Hi.
>
> I really like our open way of reporting using the wiki but we have a small
> flaw in the procedure.
>
> The wiki is not the place to report a section, so I
> will send it to private@i.a.o and hope it will be included.
>
> rgds
> jan i.
>
>
> On 29 August 2015 at 01:00, Marvin Humphrey wrote:
>
> > Greetings, {podling} developers!
> >
> > This is a reminder that your report is due next Wednesday, September
> > 2nd. Details below.
> >
> > Best,
> >
> > Marvin Humphrey, Report Manager for September, on behalf of the
> > Incubator PMC
> >
> > ---
> >
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 16 September 2015, 10:30 am
> > Pacific. The report for your podling will form a part of the Incubator
> > PMC report. The Incubator PMC requires your report to be submitted 2
> > weeks before the board meeting, to allow sufficient time for review and
> > submission (Wed, September 2nd).
> >
> > Please submit your report with sufficient time to allow the incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > * Your project name
> > * A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > * A list of the three most important issues to address in the move
> > towards graduation.
> > * Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > * How has the community developed since the last report
> > * How has the project developed since the last report.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > http://wiki.apache.org/incubator/September2015
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
> >
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept HAWQ into the Apache Incubator
from existing customers and > partners. We intend to convert that interest directly into > participation and will be investing in activities to recruit > additional committers from other companies. > > === Reliance on Salaried Developers === > Most of the contributors are paid to work in the Big Data space. While > they might wander from their current employers, they are unlikely to > venture far from their core expertise and thus will continue to be > engaged with the project regardless of their current employers. > > === Relationships with Other Apache Products === > As mentioned in the Alignment section, HAWQ may consider various > degrees of integration and code exchange with Apache Hadoop, Apache > Spark and Apache Hive projects. We expect integration points to be > inside and outside the project. We look forward to collaborating with > these communities as well as other communities under the Apache > umbrella. > > === An Excessive Fascination with the Apache Brand === > While we intend to leverage the Apache ‘branding’ when talking to > other projects as testament of our project’s ‘neutrality’, we have no > plans for making use of Apache brand in press releases nor posting > billboards advertising acceptance of HAWQ into Apache Incubator. > > == Documentation == > The documentation is currently available at http://hawq.docs.pivotal.io/ > > == Initial Source == > Initial source code will be available immediately after Incubator PMC > approves HAWQ joining the Incubator and will be licensed under the > Apache License v2. > > == Source and Intellectual Property Submission Plan == > As soon as HAWQ is approved to join the Incubator, the source code > will be transitioned via an exhibit to Pivotal's current Software > Grant Agreement onto ASF infrastructure and in turn made available > under the Apache License, version 2.0. We know of no legal > encumberments that would inhibit the transfer of source code to the > ASF. > > == External Dependencies == > > Runtime dependencies: > * gimli (BSD) > * openldap (The OpenLDAP Public License) > * openssl (OpenSSL License and the Original SSLeay License, BSD style) > * proj (MIT) > * yaml (Creative Commons Attribution 2.0 License) > * python (Python Software Foundation License Version 2) > * apr-util (Apache Version 2.0) > * bzip2 (BSD-style License) > * curl (MIT/X Derivate License) > * gperf (GPL Version 3) > * protobuf (Google) > * libevent (BSD) > * json-c (https://github.com/json-c/json-c/blob/master/COPYING) > * krb5 (MIT) > * pcre (BSD) > * libedit (BSD) > * libxml2 (MIT) > * zlib (Permissive Free Software License) > * libgsasl (LGPL Version 2.1) > * thrift (Apache Version 2.0) > * snappy (Apache Version 2.0 (up to 1.0.1)/New BSD) > * libuuid-2.26 (LGPL Version 2) > * apache hadoop (Apache Version 2.0) > * apache avro (Apache Version 2.0) > * glog (BSD) > * googlemock (BSD) > > Build only dependencies: > * ant (Apache Version 2.0) > * maven (Apache Version 2.0) > * cmake (BSD) > > Test only dependencies: > * googletest (BSD) > > Cryptography N/A > > == Required Resources == > > === Mailing lists === > * priv...@hawq.incubator.apache.org (moderated subscriptions) > * comm...@hawq.incubator.apache.org > * d...@hawq.incubator.apache.org > * iss...@hawq.incubator.apache.org > * u...@hawq.incubator.apache.org > > === Git Repository === > https://git-wip-us.apache.org/repos/asf/incubator-hawq.git > > === Issue Tracking === > JIRA Project HAWQ (HAWQ) > > === Other Resources === > > Means of setting up regular builds for HAWQ on builds.apache.org will > require integration with Docker support. > > == Initial Committers == > * Lirong Jian > * Hubert Huan Zhang > * Radar Da Lei > * Ivan Yanqing Weng > * Zhanwei Wang > * Yi Jin > * Lili Ma > * Jiali Yao > * Zhenglin Tao > * Ruilong Huo > * Ming Li > * Wen Lin > * Lei Chang > * Alexander V Denissov > * Newton Alex > * Oleksandr Diachenko > * Jun Aoki > * Bhuvnesh Chaudhary > * Vineet Goel > * Shivram Mani > * Noa Horn > * Sujeet S Varakhedi > * Junwei (Jimmy) Da > * Ting (Goden) Yao > * Mohammad F (Foyzur) Rahman > * Entong Shen > * George C Caragea > * Amr El-Helw > * Mohamed F Soliman > * Venkatesh (Venky) Raghavan > * Carlos Garcia > * Zixi (Jesse) Zhang > * Michael P Schubert > * C.J. Jameson > * Jacob Frank > * Ben Calegari > * Shoabe Shariff > * Rob Day-Reynolds > * Mel S Kiyama > * Charles Alan Litzell > * David Yozie >
Re: [VOTE] Accept MADlib into the Apache Incubator
ested interest in making MADlib > succeed by driving its close integration with sister ASF projects. We > expect this to further reduces the risk of orphaning the product. > > Even in the absence of support by a particular vendor such as Pivotal, > and in a worst-case scenario where HAWQ and Greenplum Database fail to > gain traction in OSS, the existence of an established PostgreSQL OSS > project means there’s will still be a working stack for MADlib. > > === Inexperience with Open Source === > MADlib has been an open source project from the outset. All developers > working on the project (regardless of their employment affiliation) > did so completely in the open. While the governance model of MADlib > has been more of a benevolent dictator model, the project has always > been receptive to accepting contributions from all sources and > including them in future releases based on thorough code review, > testing, and compliance with the project’s coding best practices. > > === Homogeneous Developers === > While most of the initial committers are employed by Pivotal, there's > still a healthy level of interest coming from academia. On top of that > we expect to spark curiosity in sister ASF projects and attract > developers unaffiliated with Pivotal. Finally, MADlib is being used > extensively whenever Pivotal engages with customers on data science > projects. This typically means that the skills remain within a > customer organization which further increases the chance of turning > customer data scientists into MADlib contributors. > > === Reliance on Salaried Developers === > A large percentage of the contributors are paid to work in the Big > Data space. While they might wander from their current employers, they > are unlikely to venture far from their core expertise and thus will > continue to be engaged with the project regardless of their current > employers. In addition, the project is still enjoying popularity in > academic circles and we hope that will help mitigate reliance on > salaried developers as well. > > === Relationships with Other Apache Products === > As mentioned in the Alignment section, MADlib may consider various > degrees of integration and code exchange with Apache Spark (MLlib), > Apache Mahout, Apache Hive and Apache Drill projects. We expect > integration points to be inside and outside the project. We look > forward to collaborating with these communities as well as other > communities under the Apache umbrella. > > === An Excessive Fascination with the Apache Brand === > While we intend to leverage the Apache "brand" when talking to other > projects as a testament to our project’s neutrality, we have no plans > for making use of the Apache brand in press releases nor posting > billboards advertising acceptance of MADlib into Apache Incubator. > > == Documentation == > The documentation is currently available at: > https://github.com/madlib/frontpage > > The documentation is currently licensed under 2-clause BSD license. > > == Initial Source == > Initial source code is available at: >* MADlib: https://github.com/madlib/madlib >* Testsuite: https://github.com/madlib/testsuite >* Contributors: https://github.com/madlib/contrib > > The code is currently licensed under 2-clause BSD license. > > == Source and Intellectual Property Submission Plan == > As soon as MADlib is approved to join the Incubator, the source code > will be transitioned via the Software Grant Agreement onto ASF > infrastructure and in turn made available under the Apache License, > version 2.0. We know of no legal encumbrances that would inhibit the > transfer of source code to the ASF. > > == External Dependencies == > > Runtime dependencies: >* boost-1.47.0 (Boost Software License) >* _m_widen_init (MIT for this subcomponent of GCC) >* python-argparse-1.2.1 (PSF LICENSE AGREEMENT FOR PYTHON 2.7.1) >* pyyaml-3.10 (MIT license) >* cern_root-5.34 (LGPL, however this dependency will be removed > since the 2 cern modules used are being entirely re-written in MADlib) >* eigen-3.2.2 (Mozilla Public License) >* pyxb-1.2.4 (Apache license version 2) >* python (Python Software Foundation License Version 2) >* mathjax-2.5 (Apache license version 2) > > Build only dependencies: >* doxypy-0.4.2 (GPL) >* cmake-2.8.4 (BSD 3-clause License) >* doxygen >= 1.8.4 (GPL) >* flex >= 2.5.33 (BSD) >* bison >= 2.4 (GPL) >* latex (LaTeX Project Public License) >* TikZ-UML (no license information) > > Cryptography >* N/A > > == Required Resources == > > === Mailing lists === > * priv...@madlib.incubator.apache.org (moder
Re: Should Apache VOTEs be in a first-come, first-serve queue?
Am I the only one who sees an issue of moral hazard in this proposal?
On Mon, Sep 14, 2015 at 12:28PM, Marko Rodriguez wrote:
> HI,
>
> Here is an idea:
>
> Can we offer $20 to the first 3 binding voters of a release on general@? We
> would structure the contract as such:
>
> "The first 3 binding voters on Apache TinkerPop x.y.z get $20
> regardless of their vote being a -1 or +1. However, the binding voter must
> give an honest review of the artifacts and specify exactly what they did
> which led them to their ultimate vote decision. Any dishonesty in voting
> disqualifies the individual from receiving their cash prize."
>
> This seems a reasonable (and fair way) of getting VOTE attention much like
> the other marketing models currently being posited by the general@ list.
>
> Thoughts?,
> Marko.
>
> http://markorodriguez.com
>
> On Sep 14, 2015, at 12:18 PM, Marko Rodriguez wrote:
>
> > Hello,
> >
> > I suppose my concern is exactly what the two replies thus far espouse --
> > "human whim."
> >
> > This means that a "song and dance" must be done to "entice" the human to
> > entertain a VOTE. I suspect The Apache Software Foundation would argue that
> > paying people to VOTE (regardless if they +1 or -1) is bad. Or is it?
> > However, there seems little difference between paying someone to vote and
> > doing some other marketing behaviors that would lure the human voter in.
> >
> > My concern is that this means its a popularity contest and not a "lets
> > develop software that is respective of the Apache2 license." Shouldn't
> > Apache's VOTE infrastructure be beyond fancying the human with magical
> > marketing tricks?
> >
> > Thank you for your thoughts,
> > Marko.
> >
> > http://markorodriguez.com
> >
> > On Sep 14, 2015, at 11:49 AM, John D. Ament wrote:
> >
> >> I know one thing that always grabs my attention is when the community
> >> behind it votes on the topic, regardless of having binding/non-binding
> >> votes to back it. It shows me that there is a lot of interest in it, and
> >> will remind me to look at it closely and throw my vote in.
> >>
> >> Another way to compare it is is against US Voter turn out. Typically in
> >> non-presidential elections its down at 40%, but in presidential its up
> >> around 60%.
> >>
> >> John
> >>
> >> On Mon, Sep 14, 2015 at 12:50 PM Ted Dunning wrote:
> >>
> >>> Marko,
> >>>
> >>> Isn't the real problem a project level problem? Some projects are simply
> >>> higher profile than others?
> >>>
> >>> As such, wouldn't be better to raise the profile of the projects not
> >>> getting the votes rather than impair the ability to vote on popular
> >>> projects?
> >>>
> >>> Votes on project admission haven't generally been a problem. The problem
> >>> is generally with release votes. Doing a good review of a release takes a
> >>> significant amount of time and I think that it is hard to impose that
> >>> burden on everybody who wants to vote on a different project's release.
> >>>
> >>> In the projects that I have mentored, I have seen the problem with getting
> >>> IPMC votes on releases. My own response has been to
> >>>
> >>> 1) make darn sure that the mentors will vote if they possibly can
> >>>
> >>> 2) reach out to others privately to encourage them on a one-to-one basis
> >>> to
> >>> review the release and vote
> >>>
> >>> 3) warn the general list that a vote is coming and talk it up
> >>>
> >>> Most projects should have three mentors who are, by definition, IPMC
> >>> members with the ability to case binding votes. If a project finds that
> >>> some mentors are persistently MIA, they should find some new ones. If
> >>> mentors find that other mentors are MIA, then they should describe to the
> >>> project why that is a problem and suggest ways to get additional mentors
> >>> involved.
> >>>
> >>> Ultimately, this problem is just a preview of what happens when a project
> >>> doesn't have enough active participation and needs to be handled using
> >>> essentially the same community development methods.
> >>>
> >>>
> >>> On Mon, Sep 14, 2015 at 9:26 AM, Marko Rodriguez
> >>> wrote:
> >>>
> Hello,
>
> It appears that VOTEing in general@ is inefficient and biased. An Apache
> member will see a VOTE on the list and can choose whether to participate
> >>> in
> that VOTE or not. I believe there are problems with this algorithm. The
> first has to do with efficiency. For instance, Groovy received (out of my
> foggy memory) some 20+ VOTEs when only 3 were were needed and other
> >>> project
> VOTEs were sitting around hoping for an Apache member to spend time on
> their project. Second, if no Apache member really cares about the
> >>> project's
> VOTE, then the project committee is left "hoping" that someone will care
> --- pinging around to their mentors (no reply), to the list ("please")…
> like beggars in the street.
>
> Should general
Re: [DISCUSS] Graduate Calcite from the Apache Incbuator
+1 (binding). Good luck! On Sat, Sep 12, 2015 at 03:09PM, Julian Hyde wrote: > The Calcite community has established consensus and held a > successful vote with 20 +1 votes in favor of proposing > graduation to a top-level project, including 12 votes from > committers and 6 votes from IPMC members. > > Here are: the discussion on the dev list [1], vote thread > [2] and result [3]. Also relevant are the incubation status > page [4] and a thread on this list requesting review of > whether Calcite met the criteria to graduate[5]. > > We propose that Calcite is ready to become a top-level > project. If this discussion reaches consensus we will move > to a formal vote. > > Below is our proposed resolution. > > Julian Hyde, on behalf of Calcite PPMC > > [1] http://s.apache.org/ZPC > [2] http://s.apache.org/rvB > [3] http://s.apache.org/sv > [4] http://incubator.apache.org/projects/calcite.html > [5] http://s.apache.org/itP > > - - - snip - - - > > 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 parsing and planning queries on data in a > wide variety of formats. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache Calcite > Project", be and hereby is established pursuant to Bylaws of > the Foundation; and be it further > > RESOLVED, that the Apache Calcite Project be and hereby is > responsible for the creation and maintenance of software > related to parsing and planning queries on data in a wide > variety of formats; and be it further > > RESOLVED, that the office of "Vice President, Apache > Calcite" 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 Calcite Project, and to have > primary responsibility for management of the projects within > the scope of responsibility of the Apache Calcite 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 Calcite Project: > > * Alan Gates > * Aman Sinha > * Ashutosh Chauhan > * James R. Taylor > * Jacques Nadeau > * Jesús Camacho Rodríguez > * Jinfeng Ni > * John Pullokkaran > * Julian Hyde > * Nick Dimiduk > * Steven Noels > * Ted Dunning > * Vladimir Sitnikov > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be > appointed to the office of Vice President, Apache Calcite, > 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 Apache Calcite Project be and hereby is > tasked with the migration and rationalization of the Apache > Incubator Calcite podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache > Incubator Calcite podling encumbered upon the Apache > Incubator Project are hereafter discharged. > > - - - end - - - > > - > 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] Mentor neutrality policy
On Fri, Oct 09, 2015 at 11:38AM, Greg Trasuk wrote: > Hi Daniel: > > Discussion intertwined below… > > Cheers, > > Greg Trasuk > > > On Oct 9, 2015, at 11:07 AM, Daniel Gruno wrote: > > > > Hi Incubator folks, > > > > I would like to propose we adopt a mentor neutrality policy for > > incubating podlings: > > > > - A mentor must not be financially tied to the project or its incubation > > status. > > This requirement would seem to be against the idea that we participate in > Apache as individuals, rather than as employees/representatives of some > company. If there is a case where a member appears to be representing their I'd even go as far as saying this requirement asserts that mentors aren't capable of separating their employment/advisement affiliation from their individual contribution to the ASF. If it were indeed a case it should be dealt with on a case-per-case basis, instead of putting a round of the red-tape on everything single member of IPMC. Cos > company’s interest rather than the Foundation’s interest, shouldn’t that be > dealt with in itself? > > > - A mentor must not have a vested interest in incubating, graduating or > > dismantling a podling that goes beyond the general Apache mission > > Could you elaborate on “beyond the general Apache mission”? You probably > have some concrete examples in mind, and I’m sure we don’t want to start > dissecting those examples rather than your overall suggestion, but > personally, I’m not sure what you mean. > > > - A mentor must not be affiliated with the entity granting the code > > (company or original project community) > > > > That suggestion would seem to preclude a knowledgable insider who happens to > be an Apache member from helping out with incubating a project. Which seems > kind of inefficient. > > > Furthermore, I would like to see this extended to votes on graduating or > > retiring podlings, so that only people with no organizational (aparty > > from the ASF) or financial ties to the project (or the companies behind > > it) can cast a binding vote on graduation or retirement. > > > > This would essentially mean: > > > > - If you work for a company (or are hired as consultant/advisor) that is > > entering a project into incubation, you cannot mentor it nor vote > > for/against its incubation, graduation or retirement. > > - If you are a in the original community behind the project, you cannot > > mentor it nor vote for/against it. > > > > I believe this would create a neutral mentorship whose sole mission is > > to guide podlings with the interests of the ASF in mind. > > > > > > Please do discuss this. If there is (mostly) positive feedback, I would > > like to, at some point, have a vote on including this in the Incubator > > policy. I realize this would cut down on the number of potential > > mentors, and I would ask that more people step up to the challenge of > > mentoring if adopted. > > > > With regards, > > Daniel > > > > - > > 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: [DISCUSS] Mentor neutrality policy
On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote: > Does there always have to be an actual problem before we can propose a > policy? must we always be reactive instead of proactive? "We can't just stay on a side and wait, we should do something!" - sounds all too familiar, eh? > Yes, I am in a way implying that some mentors are, perhaps, not neutral > in their work. I will not back it up with specific names or contexts, as > I don't want to take a trip to lawsuit town for things I cannot back up > with publicly available information. > > I don't find this to be uncivil accusations - can you outline a specific > segment that you find uncivil? I am proposing a set of basic rules - > which is naturally up for discussion and improvement - that would > potentially alleviate us from having some nasty discussions - whether > they be public or private - about the neutrality and honesty of > recommendations, and hopefully ensure we have a more leveled playing > field in the incubator. > > I'll stop here, as my eyesight is playing a trick on me today and not > allowing me to see what I type. > > With regards, > Daniel. > > On 10/09/2015 08:03 PM, Chris Douglas wrote: > > What problem does this solve? > > > > This proposal lacks context. It implies that mentors are not neutral, > > and that they are motivated by interests not shared by the ASF. But it > > does not outline the merits of that belief, neither does it specify > > how this proposal would address them. Instead of allowing those > > definitions to float, this discussion would be more productive if it > > were about some concrete problems for which there is evidence. Yet > > another thread of rude responses to uncivil accusations is > > unproductive, even if it is an IPMC tradition. -C > > > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno wrote: > >> Hi Incubator folks, > >> > >> I would like to propose we adopt a mentor neutrality policy for > >> incubating podlings: > >> > >> - A mentor must not be financially tied to the project or its incubation > >> status. > >> - A mentor must not have a vested interest in incubating, graduating or > >> dismantling a podling that goes beyond the general Apache mission > >> - A mentor must not be affiliated with the entity granting the code > >> (company or original project community) > >> > >> Furthermore, I would like to see this extended to votes on graduating or > >> retiring podlings, so that only people with no organizational (aparty > >> from the ASF) or financial ties to the project (or the companies behind > >> it) can cast a binding vote on graduation or retirement. > >> > >> This would essentially mean: > >> > >> - If you work for a company (or are hired as consultant/advisor) that is > >> entering a project into incubation, you cannot mentor it nor vote > >> for/against its incubation, graduation or retirement. > >> - If you are a in the original community behind the project, you cannot > >> mentor it nor vote for/against it. > >> > >> I believe this would create a neutral mentorship whose sole mission is > >> to guide podlings with the interests of the ASF in mind. > >> > >> > >> Please do discuss this. If there is (mostly) positive feedback, I would > >> like to, at some point, have a vote on including this in the Incubator > >> policy. I realize this would cut down on the number of potential > >> mentors, and I would ask that more people step up to the challenge of > >> mentoring if adopted. > >> > >> With regards, > >> Daniel > >> > >> - > >> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Mentor neutrality policy
On Sat, Oct 10, 2015 at 01:29AM, Pierre Smits wrote: > What are you referring to, Konstantin? I am referring to the progressives of the world and all "policy frameworks" they are so readily unleashing on everybody because they have an urge to meddle. I am very much agree with Chris and Ross on immorality of the guilt-by-association policy. Cos > Best regards, > > Pierre Smits > > *OFBiz Extensions Marketplace* > http://oem.ofbizci.net/oci-2/ > > On Sat, Oct 10, 2015 at 1:31 AM, Konstantin Boudnik wrote: > > > On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote: > > > Does there always have to be an actual problem before we can propose a > > > policy? must we always be reactive instead of proactive? > > > > "We can't just stay on a side and wait, we should do something!" - sounds > > all > > too familiar, eh? > > > > > Yes, I am in a way implying that some mentors are, perhaps, not neutral > > > in their work. I will not back it up with specific names or contexts, as > > > I don't want to take a trip to lawsuit town for things I cannot back up > > > with publicly available information. > > > > > > I don't find this to be uncivil accusations - can you outline a specific > > > segment that you find uncivil? I am proposing a set of basic rules - > > > which is naturally up for discussion and improvement - that would > > > potentially alleviate us from having some nasty discussions - whether > > > they be public or private - about the neutrality and honesty of > > > recommendations, and hopefully ensure we have a more leveled playing > > > field in the incubator. > > > > > > I'll stop here, as my eyesight is playing a trick on me today and not > > > allowing me to see what I type. > > > > > > With regards, > > > Daniel. > > > > > > On 10/09/2015 08:03 PM, Chris Douglas wrote: > > > > What problem does this solve? > > > > > > > > This proposal lacks context. It implies that mentors are not neutral, > > > > and that they are motivated by interests not shared by the ASF. But it > > > > does not outline the merits of that belief, neither does it specify > > > > how this proposal would address them. Instead of allowing those > > > > definitions to float, this discussion would be more productive if it > > > > were about some concrete problems for which there is evidence. Yet > > > > another thread of rude responses to uncivil accusations is > > > > unproductive, even if it is an IPMC tradition. -C > > > > > > > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno > > wrote: > > > >> Hi Incubator folks, > > > >> > > > >> I would like to propose we adopt a mentor neutrality policy for > > > >> incubating podlings: > > > >> > > > >> - A mentor must not be financially tied to the project or its > > incubation > > > >> status. > > > >> - A mentor must not have a vested interest in incubating, graduating > > or > > > >> dismantling a podling that goes beyond the general Apache mission > > > >> - A mentor must not be affiliated with the entity granting the code > > > >> (company or original project community) > > > >> > > > >> Furthermore, I would like to see this extended to votes on graduating > > or > > > >> retiring podlings, so that only people with no organizational (aparty > > > >> from the ASF) or financial ties to the project (or the companies > > behind > > > >> it) can cast a binding vote on graduation or retirement. > > > >> > > > >> This would essentially mean: > > > >> > > > >> - If you work for a company (or are hired as consultant/advisor) that > > is > > > >> entering a project into incubation, you cannot mentor it nor vote > > > >> for/against its incubation, graduation or retirement. > > > >> - If you are a in the original community behind the project, you > > cannot > > > >> mentor it nor vote for/against it. > > > >> > > > >> I believe this would create a neutral mentorship whose sole mission is > > > >> to guide podlings with the interests of the ASF in mind. > > > >> > > > >> > > > >> Please do discuss this. If there is (mostly) positive feedback, I >
Re: [DISCUSS] Mentor neutrality policy
On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote: > On 10/10/2015 07:51 AM, Andrew Purtell wrote: > > We should address perceived, and certainly provable, instances of > > corruption at the Foundation directly, rather than prescribe policy that > > seeks to prevent future instances as if there is a precedent (but there > > isn't one here... at least one not spoken aloud, right?). > > We shouldn't need to have publicly available cases of wrong-doings to > say "no wrong-doings please". We hold our politicians to this standard > where I come from - it's called the Arm's Length Principle, and it's > worked very well. But we aren't dealing with politicians here, who are by definition are the scam of the earth. So, let's not even get there, please. Cos > >> A mentor must not be financially tied to the project or its incubation > > status. > > > > Aside from deviating greatly from treating mentors and all other persons as > > individuals, for verification purposes this would require a level of > > intrusive financial reporting that we don't remotely approach today and to > > which most members would probably object. > > I'm not suggesting we start auditing people. As later clarified, I am > suggesting people recuse themselves from voting if they (or others?) > feel that they have economic or other corporate interests that may cloud > either their judgment or their perceived judgment. The reason I said > 'mentors' here is because the mentor role, as it currently is, is a mix > of attorney, judge, jury and executioner in the podlings. If we were to > separate this and mentors were solely in charge of _mentoring_, the > issue would be more moot. > > > > >> A mentor must not have a vested interest in incubating, graduating or > > dismantling a podling that goes beyond the general Apache mission > > > > None of this is well defined. > > Agreed, I picked the wrong word to use here. I prefer Sam's revisement, > as stated earlier. > > With regards, > Daniel. > > > > >> If you are a in the original community behind the project, you cannot > > mentor it nor vote for/against it. > > > > This diminishes the pool of available mentors and in particular those > > probably most vested in the success of the podling. > > > > > > > > > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno wrote: > > > >> Hi Incubator folks, > >> > >> I would like to propose we adopt a mentor neutrality policy for > >> incubating podlings: > >> > >> - A mentor must not be financially tied to the project or its incubation > >> status. > >> - A mentor must not have a vested interest in incubating, graduating or > >> dismantling a podling that goes beyond the general Apache mission > >> - A mentor must not be affiliated with the entity granting the code > >> (company or original project community) > >> > >> Furthermore, I would like to see this extended to votes on graduating or > >> retiring podlings, so that only people with no organizational (aparty > >> from the ASF) or financial ties to the project (or the companies behind > >> it) can cast a binding vote on graduation or retirement. > >> > >> This would essentially mean: > >> > >> - If you work for a company (or are hired as consultant/advisor) that is > >> entering a project into incubation, you cannot mentor it nor vote > >> for/against its incubation, graduation or retirement. > >> - If you are a in the original community behind the project, you cannot > >> mentor it nor vote for/against it. > >> > >> I believe this would create a neutral mentorship whose sole mission is > >> to guide podlings with the interests of the ASF in mind. > >> > >> > >> Please do discuss this. If there is (mostly) positive feedback, I would > >> like to, at some point, have a vote on including this in the Incubator > >> policy. I realize this would cut down on the number of potential > >> mentors, and I would ask that more people step up to the challenge of > >> mentoring if adopted. > >> > >> With regards, > >> Daniel > >> > >> - > >> 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: [DISCUSS] Retire the Droids podling (was Re: Droids Podling Issue)
Looks like it is one of those situations that happens from time to time. Makes sense to me. Thanks. Cos On Sat, Oct 10, 2015 at 06:26AM, Marvin Humphrey wrote: > It's been a month and we haven't heard from Thorsten, nor any lurker > in the Droids community. > > I've changed the subject to make it clear that retirement is being > contemplated. Per the Incubator Retirement Guide[1], the next step is > to call a community VOTE on droids-dev, which I will do in a few days. > Should that vote go as expected given these discussions, I will > subsequently call a VOTE of the IPMC. > > Marvin Humphrey > > [1] http://incubator.apache.org/guides/retirement.html > > On Tue, Sep 8, 2015 at 6:13 PM, Marvin Humphrey > wrote: > > Thorsten, any commentary? > > > > Marvin Humphrey > > > > On Mon, Aug 31, 2015 at 8:05 AM, Richard Frovarp > > > >> Thanks Marvin. I'm probably at that point. I'd be happy to work on it, and > >> help out the community. However, I don't have the energy to push and build > >> a > >> community, which is what is needed. I was waiting to see if Thorsten had > >> something to say. I know he was out of the office when the last report was > >> due. > > - > 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] Mentor neutrality policy
On Sat, Oct 10, 2015 at 09:05PM, Branko Čibej wrote: > On 10.10.2015 20:11, Konstantin Boudnik wrote: > > On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote: > >> On 10/10/2015 07:51 AM, Andrew Purtell wrote: > >>> We should address perceived, and certainly provable, instances of > >>> corruption at the Foundation directly, rather than prescribe policy that > >>> seeks to prevent future instances as if there is a precedent (but there > >>> isn't one here... at least one not spoken aloud, right?). > >> We shouldn't need to have publicly available cases of wrong-doings to > >> say "no wrong-doings please". We hold our politicians to this standard > >> where I come from - it's called the Arm's Length Principle, and it's > >> worked very well. > > But we aren't dealing with politicians here, who are by definition are the > > scam of the earth. So, let's not even get there, please. > > "Scam of the Earth" ... one of the better puns I ran into recently. :) And indeed they are, as they are scamming everyone into a believe that they are here to solve "issues" for the rest of dumb-us. I am glad that pun hasn't gone lost ;) Cos - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Mentor neutrality policy
Continuing this line of reasoning I won't be able to mentor _any_ of the projects I've mentored or still mentoring because of different levels of involvements either at my $dayjob or with the organizations that donated the code initially. Is this really an intent of the original proposal to prevent people from they care doing in the open-source? And based on what again? Cos On Mon, Oct 12, 2015 at 11:14AM, Andrew Purtell wrote: > I would not have been able to mentor Phoenix should it have come along now. > At the time I was not employed by the originator of the project. Later I > chose to join them in part because they contributed the results of their > labor to Apache. My evaluation of how well a podling might be > functioning would not have been in any way different before or after I took > the job. > > > On Mon, Oct 12, 2015 at 10:13 AM, Ted Dunning wrote: > > > The practical effect on me of this requirement would be that > > > > a) I couldn't have mentored Drill > > > > b) I couldn't have mentored Zookeeper (assuming it were to come along now) > > > > c) I couldn't mentor Kylin (it affects Drill and MapR customers are > > considering using it) > > > > d) I couldn't mentor Calcite (same as Drill) > > > > e) I couldn't mentor Storm (MapR distributes it) > > > > f) I couldn't mentor Flink (I am co-writing a book that highlights it) > > > > g) I couldn't help with Zeppelin (our SE's use it for demos) > > > > h) I couldn't mentor Apex (MapR is a partner of DataTorrent) > > > > In fact, I can't think of any project that I have helped out that would be > > allowable under this policy. > > > > Take Julian Hyde and Taylor Goetz as additional examples. They wouldn't be > > able to help on any of the projects they have been helping on. > > > > So I *could* mentor Corinthia. Or some of the projects that I had never > > heard of and couldn't care less about. > > > > Well, that doesn't work because I don't care about those projects and I am > > not going to waste my time. I care about machine learning and big data and > > streaming and query languages. That is what drives my choice of work and > > what drives my choice of open source projects to contribute to. It also > > leads me to advocate for adoption of those projects at work and for driving > > some of the work I do into open source. > > > > > > > > On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) < > > chris.a.mattm...@jpl.nasa.gov> wrote: > > > > > So here’s my elaboration. > > > > > > The proposal below would have prevented me from ever helping > > > projects to the ASF and convincing them that it may be a good > > > home for them. I’ve always had financial ties to a project’s > > > Incubation status. In many cases, projects being at the ASF, > > > and my involvement in them has assisted my mission of doing > > > scientific research and helping win proposals and so forth for > > > NASA and other agencies. > > > > > > Further, I’ve many times been at the same institution in which > > > the project has originated from before the ASF. > > > > > > I think I’ve done a good job on the projects I’ve helped to > > > bring here and they have been successful too and have overall > > > benefitted the ASF. > > > > > > This rings to me very similar to Roy’s email circa 2012 I believe > > > in which in the Incubator we tried to force the diversity requirement > > > as a graduation requirement, and Roy succinctly explained that we > > > can’t punish e.g., a podling for having people all from the same > > > institution. That would punish that institution for hiring folks > > > for open source who work on code at the ASF. Diversity is always > > > a strong property of a podling as I feel it makes it more resilient > > > but it’s not a hard requirement. I feel the same thing in this thread. > > > > > > Cheers, > > > Chris > > > > > > ++ > > > Chris Mattmann, Ph.D. > > > Chief Architect > > > Instrument Software and Science Data Systems Section (398) > > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > > Office: 168-519, Mailstop: 168-527 > > > Email: chris.a.mattm...@nasa.gov > > > WWW: http://sunset.usc.edu/~mattmann/ > > > ++ > > > Adjunct Associate Professor, Computer Science Department > > > University of Southern California, Los Angeles, CA 90089 USA > > > ++ > > > > > > > > > > > > > > > > > > -Original Message- > > > From: jpluser > > > Reply-To: "general@incubator.apache.org" > > > Date: Friday, October 9, 2015 at 5:14 PM > > > To: "general@incubator.apache.org" > > > Subject: Re: [DISCUSS] Mentor neutrality policy > > > > > > >I do not agree with this proposal I will elaborate more later > > > > > > > >Sent from my iPhone > > > > > > > >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno > > wrote: > > > >> > > > >> Hi Incubator folks, > > > >> >
Re: [DISCUSS] Mentor neutrality policy
On Sun, Oct 11, 2015 at 06:52PM, Reto Gmür wrote: > On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik > wrote: > > > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno wrote: > > > Hi Incubator folks, > > > > > > I would like to propose we adopt a mentor neutrality policy for > > > incubating podlings: > > > > > > - A mentor must not be financially tied to the project or its incubation > > > status. > > > > I'm very strongly -1 on this for two reasons. One fundamental > > and one operational. Fundamentally, this goes against a core > > ASF principle that we all collaborate here as individuals by > > checking our corporate affiliation at the door. > > > I think it's naive to think that just because the members are individual > and corporate affiliations don't formally play a role there is no influence > by the employer. When I'm paid by a company or government agency to work on > an apache project I don't have an effective protection against the > directives of my employer. Maybe if I refuse to follow an employer's > instruction to write some code for an Apache project of which I'm committer > I could not be fired without notice, maybe I could write the patch and say > on the list that I wrote this patch for my employer but that as an > individual PMC member I vote against it (did something like this ever > happen?), whichever way I'm likely to act against my financial interest. > > In medical journals the author's are also writing in their own name, yet > they must declare all competing interests. Following your logic such as > declaration would be unnecessary if the journal says somewhere that authors > leave their affiliation at the door. That's a straw-man argument. Unlike people writing for the medical journals who're working for the, sadly, the most regulated industry ever and making millions if their research happen to be acknowledged as promising, even when harmful, Apache contributors are _individual volunteers_ developing the software for public consumption. And you _have_ to leave your affiliation elsewhere when you're wearing your Apache hat. Hence your affiliation is of no relevance here. Cos > > IOW, we are explicitly granting our members and committers the trust > > required to make sure they do the right thing while they themselves (or > > their employees) can significantly benefit (financially and otherwise) from > > the projects. > > > > Even if we trust our commiters that they do not commit a hidden back door > on behalf of the spy agency they work for, the conflict of interest can be > much more subtle. The company has a deadline and a release of an apache > project before that deadline would come in very handy, will you scrutinize > the notice files at the risk of finding something that delays the release? > > If a main customer of my consulting firm is the main promoter of the XY > file format, will I by neutral in choosing the best file format for the > Apache Project I'm involved in? I probably really believe that XY is the > way to go, but is should be an Apache rule that I declare that I have some > financial ties to it. > > > > > > This is what makes ASF unique and anything that goes even slightly > > in the direction of reducing this level of trust will have me up in arms > > (regardless of whether it is related to Incubator or not). > > > > Operationally, this is extremely tricky to enforce. I speak here > > from experience of somebody who has to be appreciative of the same > > set of issues while consulting for companies and yet working for my > > current employer. Even in a corporate world (where stakes are much > > higher from legal perspective) this typically gets handled by trusting > > the individual to do the right thing and disclose any potential conflict > > of interest (financial or otherwise). > > > > We would not have to ask people for their tax declaration, a self > declaration of any potentially competing interest would do. > > Cheers, > Reto signature.asc Description: Digital signature
Re: [DISCUSS] Mentor neutrality policy
On Sun, Oct 11, 2015 at 02:45PM, Pierre Smits wrote: > Producing good code is a community effort. When it comes down to just the > mentors fix that themselves, there is something wrong with the community of > the podling. > > This discussion is not about what participants do with their mentor hat on > in the podling. I expect we all appreciate what mentors do within the > podling and how they help out with explanation when a podling is discussed > in this ML. The discussion is about people wearing two (or more) hats while > mentoring a podling. > > And yes, the ASF should be wary of mentors pushing their podling toward > graduation beyond their mentor role. Do the mentors fear podling failure > (not graduating) so much, that they need a control on both the internal > process of the podling (e.g. regarding graduation) and the process at IPMC > level? At this point, this is all a hearsay. Supporters of the proposal are making an assumption nearing the base-less accusation of someone putting their employment or financial affiliation in front of that of Foundation. It is suboptimal, lacking the implementation mechanism, and finally smells bad to impose a blanket policy without real ground, but just because "not doing something isn't a option". Cos > Was the whole evalution process not intended to ensure that eyes of others > than those with a vested interest (and yes graduation success can be regard > as such) look and decide on the aspects of community diversity/project > independence/code risk of the podling? > > > Best regards, > > Pierre Smits > > *OFBiz Extensions Marketplace* > http://oem.ofbizci.net/oci-2/ > > On Sun, Oct 11, 2015 at 11:48 AM, Mark Struberg wrote: > > > -1 > > > > Mentors who have no interest (financially or purely technical doesn’t > > matter in the end) will not find enough time to _really_ look into the > > projects health. > > > > Be honest with yourself: how much do you look into the code if you are not > > working on it yourself? How could you then detect that code is > > bulk-imported from another project (I‚ve even seen LGPLed code slip in). > > And this doesn’t happen because people want us something bad. They often > > simply don’t know how much the ASF cares about code provenance and legal > > things. That’s an important part in the mentor work. And you cannot do this > > if you are only somehow loosely checking the project every other month. > > > > Or do you fear a mentor will push through his own ‚baby‘ with knowingly > > ignoring ASF rules? > > > > > > LieGrue, > > strub > > > > > > > > > Am 09.10.2015 um 17:07 schrieb Daniel Gruno : > > > > > > Hi Incubator folks, > > > > > > I would like to propose we adopt a mentor neutrality policy for > > > incubating podlings: > > > > > > - A mentor must not be financially tied to the project or its incubation > > > status. > > > - A mentor must not have a vested interest in incubating, graduating or > > > dismantling a podling that goes beyond the general Apache mission > > > - A mentor must not be affiliated with the entity granting the code > > > (company or original project community) > > > > > > Furthermore, I would like to see this extended to votes on graduating or > > > retiring podlings, so that only people with no organizational (aparty > > > from the ASF) or financial ties to the project (or the companies behind > > > it) can cast a binding vote on graduation or retirement. > > > > > > This would essentially mean: > > > > > > - If you work for a company (or are hired as consultant/advisor) that is > > > entering a project into incubation, you cannot mentor it nor vote > > > for/against its incubation, graduation or retirement. > > > - If you are a in the original community behind the project, you cannot > > > mentor it nor vote for/against it. > > > > > > I believe this would create a neutral mentorship whose sole mission is > > > to guide podlings with the interests of the ASF in mind. > > > > > > > > > Please do discuss this. If there is (mostly) positive feedback, I would > > > like to, at some point, have a vote on including this in the Incubator > > > policy. I realize this would cut down on the number of potential > > > mentors, and I would ask that more people step up to the challenge of > > > mentoring if adopted. > > > > > > With regards, > > > Daniel > > > > > > - > > > 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 > > > > signature.asc Description: Digital signature
Re: [DISCUSS] [REVISED] Mentor neutrality policy
And still -1 on the revised proposal for the same reasons I stated before. Cos On Sun, Oct 11, 2015 at 11:39PM, Daniel Gruno wrote: > First off: Can we *please* focus on the revised proposal and not get > into a loop about the original email? I'll change the topic if that helps. > > The revised edition, as partly suggested by Sam (and echoed by Bertrand) > was: > > - Binding votes on incubation, graduation and/or retirement are only > valid when given by members of the IPMC who are independent from the > podling in question. Mentors are free to recommend such actions, but > cannot cast a vote themselves. > > I don't believe I mentioned MIA mentors anywhere - is that something you > wish to discuss as well? > > With regards, > Daniel. > > On 10/11/2015 11:34 PM, Alan D. Cabrera wrote: > > I’m -1 on on this. The whole premise of the ASF is that it is a > > meritocracy and that volunteers at various “levels” of the organization > > have attained their status because they are trustworthy. Without this > > premise, the ASF falls apart. > > > > Finally, it’s not clear to me that this addresses the problem of MIA > > mentors. If they were supposedly tied in some manner to the incubation and > > graduation of a podling, then they are definitely active during its > > incubation; I have no problem with that because in my book, they are > > trustworthy. > > > > I’ve made proposals to solve the problems listed below, the causes of which > > are, imo, volunteerism and a free ride into a project and its PMC. My > > proposal was after 3 missed votes, the mentor is automatically removed with > > simple no-fuss reinstatement procedures should the mentor wish to redeem > > themselves. Mentors cannot stay with the podling when it graduates. > > > > > > Regards, > > Alan > > > >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno wrote: > >> > >> Hi Incubator folks, > >> > >> I would like to propose we adopt a mentor neutrality policy for > >> incubating podlings: > >> > >> - A mentor must not be financially tied to the project or its incubation > >> status. > >> - A mentor must not have a vested interest in incubating, graduating or > >> dismantling a podling that goes beyond the general Apache mission > >> - A mentor must not be affiliated with the entity granting the code > >> (company or original project community) > >> > >> Furthermore, I would like to see this extended to votes on graduating or > >> retiring podlings, so that only people with no organizational (aparty > >> from the ASF) or financial ties to the project (or the companies behind > >> it) can cast a binding vote on graduation or retirement. > >> > >> This would essentially mean: > >> > >> - If you work for a company (or are hired as consultant/advisor) that is > >> entering a project into incubation, you cannot mentor it nor vote > >> for/against its incubation, graduation or retirement. > >> - If you are a in the original community behind the project, you cannot > >> mentor it nor vote for/against it. > >> > >> I believe this would create a neutral mentorship whose sole mission is > >> to guide podlings with the interests of the ASF in mind. > >> > >> > >> Please do discuss this. If there is (mostly) positive feedback, I would > >> like to, at some point, have a vote on including this in the Incubator > >> policy. I realize this would cut down on the number of potential > >> mentors, and I would ask that more people step up to the challenge of > >> mentoring if adopted. > >> > >> With regards, > >> Daniel > >> > >> - > >> 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 > signature.asc Description: Digital signature
Re: Mentor disengagement - a suggestion
On Wed, Oct 14, 2015 at 06:10AM, Ted Dunning wrote: > If it can work, that is very good. With intermittent availability, I have > often seen the need for a spare. Exactly! I've been out for 6 weeks back in May/June and missed all the reports and other activity on the projects I am/was a mentor to. But I didn't fret as there were a couple of other guys to make sure the podlings aren't hanging high and dry Cos > On Wed, Oct 14, 2015 at 5:53 AM, Jim Jagielski wrote: > > > Agreed. My only comment would be that I still think that the > > optimal number of mentors is 1. > > > > > On Oct 14, 2015, at 12:45 AM, Julian Hyde wrote: > > > > > > It's not activity on the dev list, or even report signoffs, that > > > matter most. Podlings, especially new podlings, have lots and lots of > > > questions, especially about infrastructure. Without at least two > > > responsive mentors to field those questions you feel like banging your > > > head on the wall. And you start wondering why you left the comfort and > > > convenience of github and whether Apache itself is fascinated by its > > > own brand. > > > > > > Before you ask, you won't get podlings to send their questions to > > > another list, because we're all too proud to ask questions which in > > > retrospect always turn out to be dumb questions. > > > > > > It's not possible to measure that kind of mentor activity, so I think > > > people are inclined to measure the "public" forms of activity as proxy > > > indicators. > > > > > > Julian > > > > > > > > > On Tue, Oct 13, 2015 at 4:19 AM, Jim Jagielski wrote: > > >> For me, I consider being a mentor as I do being a member of a PMC. > > >> Occasionally one simply lacks cycles to be actively involved, but > > >> one is involve enough to see that others *ARE* involved, and so I > > >> am "unconcerned" about my inactivity during those times. > > >> > > >> My understanding is that this is OK and its one of the reasons > > >> why we *have* multiple mentors. > > >> > > >> "Shaming" inactive mentors would be akin to "shaming" PMC members who > > >> didn't post on the dev@ list this month, or who didn't vote on a > > release > > >> or etc... > > >> > > >> I am not, of course, referring to mentors who are truly MIA month in and > > >> month out. But, as someone said, if you remove those from the equation, > > >> the list of "active" mentors is pretty constant. > > >> > > >> So the question is "Is there a difference or problem between a podling > > >> with 10 mentors, of which 4 are 'active', as compared to a podling with > > >> 4 mentors, all of which are 'active'"?? > > >> > > >>> On Oct 13, 2015, at 2:29 AM, Ted Dunning > > wrote: > > >>> > > >>> On Mon, Oct 12, 2015 at 11:05 PM, Sam Ruby > > wrote: > > >>> > > > Sounds like reaching out to the inactive mentors is a great idea and > > I > > > think we have a great example here of how complicated it can be. > > > > Nope. I posted that link knowing that my name would be on it, and > > advocated that we should be having exactly this discussion. I should > > either become more active on this, or (and probably more likely) > > remove myself as a mentor for this podling. > > >>> > > >>> > > >>> And possibly by so doing become a great example to others of us who > > can't > > >>> admit to ourselves that we are over-extended. > > >> > > >> > > >> - > > >> 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 > > > > signature.asc Description: Digital signature
[VOTE] Graduate Groovy from the Incubator
Following discussions [1] about its current status, the Groovy community has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s total, 5 are binding: Guillaume Laforge Cédric Champeau Paul King Jochen Theodorou Pascal Schumacher Emmanuel Lécharny (binding) Bertrand Delacretaz (binding) Andrew Bayer (binding) Jim Jagielski (binding) Konstantin Boudnik (binding) Russel Winder Guillaume Alleon The Groovy community has: * completed all required paperwork: https://incubator.apache.org/projects/groovy.html * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) * completed the name check procedure: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 * addressed 50+ JIRAs: http://is.gd/1tACON * voted in multiple new committers/PPMC members Therefore, I'm calling a VOTE to graduate Groovy with the following Board resolution. The VOTE will run for at least 72 hours, ending Saturday, October 31st 8 PM PST. [ ] +1 Graduate Apache Groovy from the Incubator. [ ] +0 Don't care. [ ] -1 Don't graduate Apache Groovy from the Incubator because ... Regards, Cos [1] http://is.gd/DX41lO [2] http://is.gd/pPweq3 [3] http://is.gd/VTLiqO Apache Groovy graduation resolution draft Establish the Apache Groovy Top-Level 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 evolution and maintenance of the Groovy programming language, NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Groovy Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Groovy Project be and hereby is responsible for the evolution and maintenance of the Groovy programming language; and be it further RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Groovy 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 Groovy Project PMC: Cédric Champeau Paul King Guillaume Laforge Pascal Schumacher Jochen Theodorou Andrew Bayer Konstantin Boudnik NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be appointed to the office of Vice President, Apache Groovy, 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 Apache Groovy Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Groovy podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Groovy podling encumbered upon the Apache Incubator Project are hereafter discharged. signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
+1 (binding, reiterating my earlier vote on dev@groovy) On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote: > Following discussions [1] about its current status, the Groovy community > has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s > total, 5 are binding: > > Guillaume Laforge > Cédric Champeau > Paul King > Jochen Theodorou > Pascal Schumacher > Emmanuel Lécharny (binding) > Bertrand Delacretaz (binding) > Andrew Bayer (binding) > Jim Jagielski (binding) > Konstantin Boudnik (binding) > Russel Winder > Guillaume Alleon > > The Groovy community has: > * completed all required paperwork: > https://incubator.apache.org/projects/groovy.html > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > * completed the name check procedure: > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > * addressed 50+ JIRAs: > http://is.gd/1tACON > * voted in multiple new committers/PPMC members > > Therefore, I'm calling a VOTE to graduate Groovy with the following Board > resolution. The VOTE will run for at least 72 hours, ending > Saturday, October 31st 8 PM PST. > > [ ] +1 Graduate Apache Groovy from the Incubator. > [ ] +0 Don't care. > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > Regards, > Cos > > [1] http://is.gd/DX41lO > [2] http://is.gd/pPweq3 > [3] http://is.gd/VTLiqO > > Apache Groovy graduation resolution draft > > Establish the Apache Groovy Top-Level 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 evolution > and maintenance of the Groovy programming language, > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache Groovy Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache Groovy Project be and hereby is responsible > for the evolution and maintenance of the Groovy programming language; > and be it further > > RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy > Project, and to have primary responsibility for management of the > projects within the scope of responsibility of the Apache Groovy > 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 Groovy Project > PMC: > > Cédric Champeau > Paul King > Guillaume Laforge > Pascal Schumacher > Jochen Theodorou > Andrew Bayer > Konstantin Boudnik > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be > appointed to the office of Vice President, Apache Groovy, 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 Apache Groovy Project be and hereby is tasked with > the migration and rationalization of the Apache Incubator Groovy > podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > Groovy podling encumbered upon the Apache Incubator Project are > hereafter discharged. signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
Agree with the use of @apache.org addresses 100% - should've been caught earlier by the mentors (shame on my, particularly, for submitting without re-checking this bit). If people here feel like restarting the vote - I'd be happy to do it. If no one has a strong opinion about the re-voting - I will fix it before adding to the board's agenda for Nov (assuming the vote passes). Cos On Wed, Oct 28, 2015 at 02:14PM, Marvin Humphrey wrote: > On Wed, Oct 28, 2015 at 1:26 PM, Konstantin Boudnik wrote: > > > [ ] +1 Graduate Apache Groovy from the Incubator. > > [ ] +0 Don't care. > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > +1 > > I lurked on the Groovy dev list for a while and they did great. The > community handled some pretty challenging licensing stuff well (stars > to Paul King for doing some heavy lifting). > > The incubation checklist looks good. The language of the graduation > resolution looks good, but one thing: > > > Cédric Champeau > > Paul King > > Guillaume Laforge > > Pascal Schumacher > > Jochen Theodorou > > Andrew Bayer > > Konstantin Boudnik > > If past resolutions are guide, those should all be Apache email addresses. > > No need for a revote, as the text of the resolution is only advisory > -- but I think it should be updated before submitting to the Board. > > Bon voyage! > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
Per suggestions on this thread and thanks to Marvin's effort, the emails of the proposed PMC will be updated on the draft with the @apache.org addresses as in: Cédric Champeau Paul King Guillaume Laforge Pascal Schumacher Jochen Theodorou Andrew Bayer Konstantin Boudnik Also, we missed one of the mentors in action; the invitation has been extended to him, but due to his travels he was late to respond. So, if there's no objections I will add one more PMC member when submitting the resolution to the board (given this vote will pass): Roman Shaposhnik If anyone feels that the [VOTE] needs to be restarted because of the clerical error - please speak and I'd be happy to do it. Sorry for all the jitter. Cos On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote: > Following discussions [1] about its current status, the Groovy community > has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s > total, 5 are binding: > > Guillaume Laforge > Cédric Champeau > Paul King > Jochen Theodorou > Pascal Schumacher > Emmanuel Lécharny (binding) > Bertrand Delacretaz (binding) > Andrew Bayer (binding) > Jim Jagielski (binding) > Konstantin Boudnik (binding) > Russel Winder > Guillaume Alleon > > The Groovy community has: > * completed all required paperwork: > https://incubator.apache.org/projects/groovy.html > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > * completed the name check procedure: > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > * addressed 50+ JIRAs: > http://is.gd/1tACON > * voted in multiple new committers/PPMC members > > Therefore, I'm calling a VOTE to graduate Groovy with the following Board > resolution. The VOTE will run for at least 72 hours, ending > Saturday, October 31st 8 PM PST. > > [ ] +1 Graduate Apache Groovy from the Incubator. > [ ] +0 Don't care. > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > Regards, > Cos > > [1] http://is.gd/DX41lO > [2] http://is.gd/pPweq3 > [3] http://is.gd/VTLiqO > > Apache Groovy graduation resolution draft > > Establish the Apache Groovy Top-Level 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 evolution > and maintenance of the Groovy programming language, > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache Groovy Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache Groovy Project be and hereby is responsible > for the evolution and maintenance of the Groovy programming language; > and be it further > > RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy > Project, and to have primary responsibility for management of the > projects within the scope of responsibility of the Apache Groovy > 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 Groovy Project > PMC: > > Cédric Champeau > Paul King > Guillaume Laforge > Pascal Schumacher > Jochen Theodorou > Andrew Bayer > Konstantin Boudnik > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be > appointed to the office of Vice President, Apache Groovy, 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 Apache Groovy Project be and hereby is tasked with > the migration and rationalization of the Apache Incubator Groovy > podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > Groovy podling encumbered upon the Apache Incubator Project are > hereafter discharged. signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
And with Jim's late response to the Groovy community invitation to join the PMC the final list going into the resolution will look like this Cédric Champeau Paul King Guillaume Laforge Pascal Schumacher Jochen Theodorou Andrew Bayer Konstantin Boudnik Roman Shaposhnik Jim Jagielski Again - my apologies for the mess. The [VOTE] goes for another day, and if anyone feel like it needs to be restarted because of the last minute additions - please voice your opinion here. Thanks, Cos On Thu, Oct 29, 2015 at 10:17PM, Konstantin Boudnik wrote: > Per suggestions on this thread and thanks to Marvin's effort, the emails of > the proposed PMC will be updated on the draft with the @apache.org addresses > as in: > > Cédric Champeau > Paul King > Guillaume Laforge > Pascal Schumacher > Jochen Theodorou > Andrew Bayer > Konstantin Boudnik > > Also, we missed one of the mentors in action; the invitation has been extended > to him, but due to his travels he was late to respond. So, if there's no > objections I will add one more PMC member when submitting the resolution to > the board (given this vote will pass): > > Roman Shaposhnik > > If anyone feels that the [VOTE] needs to be restarted because of the clerical > error - please speak and I'd be happy to do it. Sorry for all the jitter. > > Cos > > On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote: > > Following discussions [1] about its current status, the Groovy community > > has voted [2] to graduate from the Incubator. The vote passed [3] with 12 > > +1s > > total, 5 are binding: > > > > Guillaume Laforge > > Cédric Champeau > > Paul King > > Jochen Theodorou > > Pascal Schumacher > > Emmanuel Lécharny (binding) > > Bertrand Delacretaz (binding) > > Andrew Bayer (binding) > > Jim Jagielski (binding) > > Konstantin Boudnik (binding) > > Russel Winder > > Guillaume Alleon > > > > The Groovy community has: > > * completed all required paperwork: > > https://incubator.apache.org/projects/groovy.html > > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > > * completed the name check procedure: > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > > * addressed 50+ JIRAs: > > http://is.gd/1tACON > > * voted in multiple new committers/PPMC members > > > > Therefore, I'm calling a VOTE to graduate Groovy with the following Board > > resolution. The VOTE will run for at least 72 hours, ending > > Saturday, October 31st 8 PM PST. > > > > [ ] +1 Graduate Apache Groovy from the Incubator. > > [ ] +0 Don't care. > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > > > Regards, > > Cos > > > > [1] http://is.gd/DX41lO > > [2] http://is.gd/pPweq3 > > [3] http://is.gd/VTLiqO > > > > Apache Groovy graduation resolution draft > > > > Establish the Apache Groovy Top-Level 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 evolution > > and maintenance of the Groovy programming language, > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > (PMC), to be known as the "Apache Groovy Project", be and hereby is > > established pursuant to Bylaws of the Foundation; and be it further > > > > RESOLVED, that the Apache Groovy Project be and hereby is responsible > > for the evolution and maintenance of the Groovy programming language; > > and be it further > > > > RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy > > Project, and to have primary responsibility for management of the > > projects within the scope of responsibility of the Apache Groovy > > 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 Groovy Project > > PMC: > > > > Cédric Champeau > > Paul King > > Guillaume Laforge > > Pascal Schumacher > > Jochen Theodorou > > Andrew Bayer > > Konstantin B
Re: [VOTE] Retire Droids (IPMC)
+1 On Thu, Oct 29, 2015 at 12:36PM, Marvin Humphrey wrote: > Greetings, > > The Droids community has voted to retire: > > http://s.apache.org/Rko > > This is a vote of the IPMC to confirm the decision to retire the podling. > > [ ] +1 to retire Droids from the incubator > [ ] -1 to keep Droids in the incubator > > This vote will be held open for at least 72 hours. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [VOTE] Retire Kalumet (IPMC)
+1 On Thu, Oct 29, 2015 at 12:38PM, Marvin Humphrey wrote: > Greetings, > > The Kalumet community has voted to retire: > > http://s.apache.org/fP > > This is a vote of the IPMC to confirm the decision to retire the podling. > > [ ] +1 to retire Kalumet from the incubator > [ ] -1 to keep Kalumet in the incubator > > This vote will be held open for at least 72 hours. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
John, according to [1] the discussion could be done inside of the voting and isn't explicitly required. That was my only motive going to the [VOTE] directly. Regards, Cos [1] https://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation On Fri, Oct 30, 2015 at 06:35AM, John D. Ament wrote: > The only thing that catches me off guard is lack of a discuss thread. But > I can give +1 > On Oct 28, 2015 16:26, "Konstantin Boudnik" wrote: > > > Following discussions [1] about its current status, the Groovy community > > has voted [2] to graduate from the Incubator. The vote passed [3] with 12 > > +1s > > total, 5 are binding: > > > > Guillaume Laforge > > Cédric Champeau > > Paul King > > Jochen Theodorou > > Pascal Schumacher > > Emmanuel Lécharny (binding) > > Bertrand Delacretaz (binding) > > Andrew Bayer (binding) > > Jim Jagielski (binding) > > Konstantin Boudnik (binding) > > Russel Winder > > Guillaume Alleon > > > > The Groovy community has: > > * completed all required paperwork: > > https://incubator.apache.org/projects/groovy.html > > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > > * completed the name check procedure: > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > > * addressed 50+ JIRAs: > > http://is.gd/1tACON > > * voted in multiple new committers/PPMC members > > > > Therefore, I'm calling a VOTE to graduate Groovy with the following Board > > resolution. The VOTE will run for at least 72 hours, ending > > Saturday, October 31st 8 PM PST. > > > > [ ] +1 Graduate Apache Groovy from the Incubator. > > [ ] +0 Don't care. > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > > > Regards, > > Cos > > > > [1] http://is.gd/DX41lO > > [2] http://is.gd/pPweq3 > > [3] http://is.gd/VTLiqO > > > > Apache Groovy graduation resolution draft > > > > Establish the Apache Groovy Top-Level 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 evolution > > and maintenance of the Groovy programming language, > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > (PMC), to be known as the "Apache Groovy Project", be and hereby is > > established pursuant to Bylaws of the Foundation; and be it further > > > > RESOLVED, that the Apache Groovy Project be and hereby is responsible > > for the evolution and maintenance of the Groovy programming language; > > and be it further > > > > RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy > > Project, and to have primary responsibility for management of the > > projects within the scope of responsibility of the Apache Groovy > > 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 Groovy Project > > PMC: > > > > Cédric Champeau > > Paul King > > Guillaume Laforge > > Pascal Schumacher > > Jochen Theodorou > > Andrew Bayer > > Konstantin Boudnik > > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be > > appointed to the office of Vice President, Apache Groovy, 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 Apache Groovy Project be and hereby is tasked with > > the migration and rationalization of the Apache Incubator Groovy > > podling; and be it further > > > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > > Groovy podling encumbered upon the Apache Incubator Project are > > hereafter discharged. > > signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
Yup, and as Marvin said it is 'should' which doesn't imply a compulsion. I am going to wrap the vote now. Thanks, Cos On Sat, Oct 31, 2015 at 10:12PM, John D. Ament wrote: > Cos, > > You mean this line? > > The resolution > <https://incubator.apache.org/guides/graduation.html#tlp-resolution> should > be proposed on the general incubator list > before > a VOTE <http://www.apache.org/foundation/voting.html> is started to allow > feedback. > > John > > On Fri, Oct 30, 2015 at 2:37 PM Konstantin Boudnik wrote: > > > John, > > > > according to [1] the discussion could be done inside of the voting and > > isn't > > explicitly required. That was my only motive going to the [VOTE] directly. > > > > Regards, > > Cos > > > > [1] > > https://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation > > > > On Fri, Oct 30, 2015 at 06:35AM, John D. Ament wrote: > > > The only thing that catches me off guard is lack of a discuss thread. > > But > > > I can give +1 > > > On Oct 28, 2015 16:26, "Konstantin Boudnik" wrote: > > > > > > > Following discussions [1] about its current status, the Groovy > > community > > > > has voted [2] to graduate from the Incubator. The vote passed [3] with > > 12 > > > > +1s > > > > total, 5 are binding: > > > > > > > > Guillaume Laforge > > > > Cédric Champeau > > > > Paul King > > > > Jochen Theodorou > > > > Pascal Schumacher > > > > Emmanuel Lécharny (binding) > > > > Bertrand Delacretaz (binding) > > > > Andrew Bayer (binding) > > > > Jim Jagielski (binding) > > > > Konstantin Boudnik (binding) > > > > Russel Winder > > > > Guillaume Alleon > > > > > > > > The Groovy community has: > > > > * completed all required paperwork: > > > > https://incubator.apache.org/projects/groovy.html > > > > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > > > > * completed the name check procedure: > > > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > > > > * addressed 50+ JIRAs: > > > > http://is.gd/1tACON > > > > * voted in multiple new committers/PPMC members > > > > > > > > Therefore, I'm calling a VOTE to graduate Groovy with the following > > Board > > > > resolution. The VOTE will run for at least 72 hours, ending > > > > Saturday, October 31st 8 PM PST. > > > > > > > > [ ] +1 Graduate Apache Groovy from the Incubator. > > > > [ ] +0 Don't care. > > > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > > > > > > > Regards, > > > > Cos > > > > > > > > [1] http://is.gd/DX41lO > > > > [2] http://is.gd/pPweq3 > > > > [3] http://is.gd/VTLiqO > > > > > > > > Apache Groovy graduation resolution draft > > > > > > > > Establish the Apache Groovy Top-Level 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 evolution > > > > and maintenance of the Groovy programming language, > > > > > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > > > (PMC), to be known as the "Apache Groovy Project", be and hereby is > > > > established pursuant to Bylaws of the Foundation; and be it further > > > > > > > > RESOLVED, that the Apache Groovy Project be and hereby is responsible > > > > for the evolution and maintenance of the Groovy programming language; > > > > and be it further > > > > > > > > RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy > > > > Project, and to have primary responsibility for management of the > > > > projects within the scope of responsibility of the Apache Groovy > > > > Project; and be it further > > > > > &g
[RESULT] [VOTE] Graduate Groovy from the Incubator
The VOTE to graduate Groovy to the top-level project has passed with 15 binding +1s and 3 non-binding +1s. No 0 or -1 votes were casted. Binding: Chris Mattmann Konstantin Boudnik Julian Hyde Marvin Humphrey Emmanuel Lécharny Sergio Fernández Steve Loughran Luciano Resende Jean-Baptiste Onofré Jake Farrell Jean-Louis MONTEIRO Edward J. Yoon John D. Ament Jim Jagielski Roman Shaposhnik Non-binding Phillip Rhodes Jacques Le Roux Luke Han Thanks everyone for your Groovy votes! The following resolution will be added to the next board meeting agenda: Apache Groovy graduation resolution draft Establish the Apache Groovy Top-Level 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 evolution and maintenance of the Groovy programming language, NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Groovy Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Groovy Project be and hereby is responsible for the evolution and maintenance of the Groovy programming language; and be it further RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Groovy 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 Groovy Project PMC: Cédric Champeau Paul King Guillaume Laforge Pascal Schumacher Jochen Theodorou Andrew Bayer Konstantin Boudnik Roman Shaposhnik Jim Jagielski NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be appointed to the office of Vice President, Apache Groovy, 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 Apache Groovy Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Groovy podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Groovy podling encumbered upon the Apache Incubator Project are hereafter discharged. signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
Thanks for sending this around, Paul - I should've linked it to the vote thread, duh... Anyway, back to Rich's question: the answer is 'yes' as implied by my +1 on the vote. Why would I be voting for the graduation if I weren't sure the project is ready? Looks like a rhetorical question, this one. Regards, Cos On Mon, Nov 02, 2015 at 09:10AM, Paul King wrote: > I certainly don't want to limit discussion but if anyone hasn't seen it > yet, here is the direct link to our self assessment against the maturity > metrics (completed with the assistance of our mentors in particular > Bertrand): > https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc > On 2 Nov 2015 5:30 am, "Rich Bowen" wrote: > > > On Oct 28, 2015 4:26 PM, "Konstantin Boudnik" wrote: > > > > > > Following discussions [1] about its current status, the Groovy community > > > has voted [2] to graduate from the Incubator. The vote passed [3] with 12 > > +1s > > > total, 5 are binding: > > > > > > Guillaume Laforge > > > Cédric Champeau > > > Paul King > > > Jochen Theodorou > > > Pascal Schumacher > > > Emmanuel Lécharny (binding) > > > Bertrand Delacretaz (binding) > > > Andrew Bayer (binding) > > > Jim Jagielski (binding) > > > Konstantin Boudnik (binding) > > > Russel Winder > > > Guillaume Alleon > > > > > > The Groovy community has: > > > * completed all required paperwork: > > > https://incubator.apache.org/projects/groovy.html > > > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > > > * completed the name check procedure: > > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > > > * addressed 50+ JIRAs: > > > http://is.gd/1tACON > > > * voted in multiple new committers/PPMC members > > > > > > Therefore, I'm calling a VOTE to graduate Groovy with the following Board > > > resolution. The VOTE will run for at least 72 hours, ending > > > Saturday, October 31st 8 PM PST. > > > > I recognize that I have missed the vote and thus my response is moot. I > > have been traveling, but i don't expect preferential treatment. > > > > However, as useful as these other measures are, as a member, and as a > > director who will need to vote on this resolution, I'd like to know if you, > > as a mentor, feel that this project had attainded maturity as described in > > the maturity metric document, and will operate according to the Apache way? > > > > > > > > [ ] +1 Graduate Apache Groovy from the Incubator. > > > [ ] +0 Don't care. > > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ... > > > > > > Regards, > > > Cos > > > > > > [1] http://is.gd/DX41lO > > > [2] http://is.gd/pPweq3 > > > [3] http://is.gd/VTLiqO > > > > > > Apache Groovy graduation resolution draft > > > > > > Establish the Apache Groovy Top-Level 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 evolution > > > and maintenance of the Groovy programming language, > > > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > > (PMC), to be known as the "Apache Groovy Project", be and hereby is > > > established pursuant to Bylaws of the Foundation; and be it further > > > > > > RESOLVED, that the Apache Groovy Project be and hereby is responsible > > > for the evolution and maintenance of the Groovy programming language; > > > and be it further > > > > > > RESOLVED, that the office of "Vice President, Apache Groovy" 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 Groovy > > > Project, and to have primary responsibility for management of the > > > projects within the scope of responsibility of the Apache Groovy > > > 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 Groovy Project > > > PMC: > > > > > > Cédric C
Re: [VOTE] Graduate Groovy from the Incubator
On Mon, Nov 02, 2015 at 07:25AM, Rich Bowen wrote: > > > On 11/01/2015 07:48 PM, Konstantin Boudnik wrote: > >Thanks for sending this around, Paul - I should've linked it to the vote > >thread, duh... > > > >Anyway, back to Rich's question: the answer is 'yes' as implied by my +1 on > >the vote. Why would I be voting for the graduation if I weren't sure the > >project is ready? Looks like a rhetorical question, this one. > > No, it's not a rhetorical question at all. I suspect, as I have > mentioned in other threads, that some people vote +1 on these things > without doing a whole lot of background checking. Paul's response is > what I was looking for. > > If it's all just rhetorical questions then why do we bother at all? > Graduation is a one-time thing. We can afford to apply a little > additional scrutiny to it. This is something we can't afford to get > wrong. The one I called rhetorical was actually my last quesiton, not yours. Cos > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [VOTE] Graduate Groovy from the Incubator
On Mon, Nov 02, 2015 at 09:11AM, Emmanuel Lécharny wrote: > Le 01/11/15 20:30, Rich Bowen a écrit : > > On Oct 28, 2015 4:26 PM, "Konstantin Boudnik" wrote: > >> Following discussions [1] about its current status, the Groovy community > >> has voted [2] to graduate from the Incubator. The vote passed [3] with 12 > > +1s > >> total, 5 are binding: > >> > >> Guillaume Laforge > >> Cédric Champeau > >> Paul King > >> Jochen Theodorou > >> Pascal Schumacher > >> Emmanuel Lécharny (binding) > >> Bertrand Delacretaz (binding) > >> Andrew Bayer (binding) > >> Jim Jagielski (binding) > >> Konstantin Boudnik (binding) > >> Russel Winder > >> Guillaume Alleon > >> > >> The Groovy community has: > >> * completed all required paperwork: > >> https://incubator.apache.org/projects/groovy.html > >> * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works) > >> * completed the name check procedure: > >> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88 > >> * addressed 50+ JIRAs: > >> http://is.gd/1tACON > >> * voted in multiple new committers/PPMC members > >> > >> Therefore, I'm calling a VOTE to graduate Groovy with the following Board > >> resolution. The VOTE will run for at least 72 hours, ending > >> Saturday, October 31st 8 PM PST. > > I recognize that I have missed the vote and thus my response is moot. I > > have been traveling, but i don't expect preferential treatment. > > > > However, as useful as these other measures are, as a member, and as a > > director who will need to vote on this resolution, I'd like to know if you, > > as a mentor, feel that this project had attainded maturity as described in > > the maturity metric document, and will operate according to the Apache way? > Yes, and Bertrand has conducted the check we now run on poddling we > think are ready to become TLP. > > As a mentor who have followed a few podlings in the past, I must say > that Groovy was one of the easiest ! OTOH, the project was already > mature before being accepted in incubator. Keep in mind that this move > was dictated by the decision from Pivotal to stop paying the main > developpers, combined with the shutdown of the Codehaus hosting > facility. The Groovy fellows decided that The ASF was the best place to > host the project, and they did a long due diligence to check that the > ASF requirements were easy to follow for them. In many ways, it was all > about finding the right place for the project, and The ASF was a perfect > fit. If we want the credit go where it's due - let's not forget about Roman's effort to present the case, spent a lot of time advocating, and helping Groovy project to finally come under the Foundation's wing. Cos > Every single requirements (IP clearance, voting releases, accepting new > committers, discussion on the ML, etc) where easily met, and the groovy > community was really open minded and ready for any required change in > their way of doing things. Mature ? You bet ! > > My 2cts > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: Concerning Sentry: A disagreement over the Apache Way and graduation
On Mon, Nov 02, 2015 at 05:27PM, Vinod Vavilapalli wrote: > Many of the active TLPs do tend to center all project discussions on JIRA as > opposed to mailing lists. OTOH, non-code discussions are usually best served > on mailing lists. > > Instead of making it a JIRA vs mailing list discussion, how about the > podling be advised about putting a cool-off period for JIRA resolutions - > 24-36hrs before they get closed. Again, this is something a bunch of active > TLPs practice in the interest of leaving enough time windows for everyone > (many times around the world in different time-zones) to pitch in. I think these might be good development practices, but if there's an underlying issues with off-line decision making none of these tweak will solve it. The root issue needs to be addressed, if it indeed exists. But even for the tweaks you've proposed: some fixes/patches are mundane and keeping them on-hold for an arbitrary number of the hours will simply slow down the development. Some of the new features might be as well trivial: say adding new build target to combine certain build functions in a more convenient way, etc. etc. So, how to line up the rules and control they are being followed? Creation new policies even before the graduation happened sounds completely broken to me. What's important IMO is that committers on a project have enough sense to know when the input from the rest of the developers is needed and when a change is trivial enough to "just go in". That's a part of the podling maturity, as I see it: the effectiveness of the community inner-working; the trust that your peers are doing "the right thing". Cos > > On Nov 2, 2015, at 3:59 AM, Joe Brockmeier wrote: > > > > Hi all, > > > > I'm one of the mentors of Sentry, which has been in incubation for some > > time. The project has progressed in a number of ways, but my largest > > concern is that the podling is doing [in my opinion] too much > > development and discussion out-of-sight. > > > > I've raised issues about this, as has David Nalley. David had a > > conversation with members of Sentry at ApacheCon Big Data in September, > > and that discussion was brought back to the list. [1] > > > > Jiras are being filed, and swiftly acted on, in a way that strongly > > suggests that a lot of discussion and direction of the project are > > happening off-list and out-of-sight to the average participant. David > > and myself have suggested ways that the community can remedy this, but > > the most recent mail from Arvind indicates that he (and others in the > > podling) don't feel it is a "valid ask." > > > > At this point, I'm raising this to general@ because I'd like second (and > > third, etc.) opinions. Perhaps I'm deeply wrong, and others here feel > > Sentry is ready to graduate. My feeling is that the podling is not > > operating in "the Apache Way" and doesn't show a great deal of interest > > in doing so. [2] To quote Arvind: > > > > "I feel another issue being pointed out or which has been eluded to in > > the past is - who decides which Jiras should be fixed, what features to > > create etc, specially when they show up as Jira issues directly with > > patches that follow soon. It seems that in some ways the lack of using > > mailing lists directly for discussion is linked to this behavior of > > filing issues and fixing them rapidly, as if following a roadmap that > > the community does not have control over. Please pardon me if my > > interpretation/understanding of the issue is not right. But if it is > > right, then I do want to say that - that too is not an issue in my > > opinion at all. And here is why: > > > > When someone files a Jira, they are inviting the entire community to > > comment on it and provide feedback. If it is not in the interest of the > > project, I do believe that responsible members of the community will be > > quick to bring that out for discussion and even Veto it if necessary. If > > that is not happening, it is not an issue with lack of community > > participation, but rather it is an indicator of a project team that > > knows where the gaps are and understands how to go about filling them > > intuitively." > > > > The model that Sentry is pursing may work very well *for the existing > > members of the podling.* In my opinion, its process is entirely too > > opaque to allow for interested parties outside of the existing podling > > and companies interested in Sentry development to become involved. > > > > The podling is pressing to move to graduation, and I cannot in good > > conscience vote +1 or even +0 at this point. I'm strongly -1 as a mentor > > and don't feel the podling has any interest in working in "the Apache > > Way" as commonly understood. [3] > > > > However, I feel we've reached an impasse and there's little value in > > continuing to debate amongst the mentors / podling. They've stated their > > position(s) and I've stated mine. (I *think* David Nalley is in > > agreement
Re: Concerning Sentry: A disagreement over the Apache Way and graduation
On Mon, Nov 02, 2015 at 04:27PM, Joe Brockmeier wrote: > On 11/02/2015 03:57 PM, Patrick Hunt wrote: > > I see this (the release discussion threads you linked) as a semi-mature > > community that's well aligned. A number of folks responded to the request > > for discussion and said they were in favor. It was done on the ML in the > > open. What more do we want? I don't see anyone excluded and I'm sure if > > there was a new person looking to get involved they would have been > > welcomed into the discussion, no one is being turned away from what I can > > see. > > No one is being turned away, that I've noticed, but I really don't see > how anyone is supposed to follow along if they're not part of the team > already. I will say that the only Jira I've seen from outside recently > didn't exactly get a warm reception. [1] Not rejected, just radio silence. > > I'm also sad to see that being held up as a standard by other mentors. > My understanding is that projects should be attempting to create a > community that is open, and trying to self-perpetuate. Sure, you can't > do that if you turn people away actively - but you also can't do that by > having conversations offlist and having an opaque process that newcomers > can't follow along with. > > I'll say again - maybe my standards are improperly calibrated. If so, > and "not actively turning people away" is the standard we're going > for... that's disappointing as all heck. I don't think your standards have became miscalibrated all of a sudden. These community principles are what being instilled on new podlings by many here. Hence I believe that a perceived new norm of "not actively turning people away" should be dealt with by the first the mentors and backed up by the whole incubation model, including shepherds. Cos > [1] https://issues.apache.org/jira/browse/SENTRY-934 > -- > Joe Brockmeier > j...@zonker.net > Twitter: @jzb > http://www.dissociatedpress.net/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: Unsubscribe not working
Potentially it might mean that you have also subscribed from other mail aliases? On Sun, Nov 08, 2015 at 07:45PM, Robert Kausch - US wrote: > Sorry for having to send this to the whole list, but I don't think the > unsubscribe functionality is working. I've been trying for 10 days, and I'm > still receiving email from the list. > > Sent from my iPhone > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [VOTE] Retire Corinthia
+1 (binding) On Sun, Nov 15, 2015 at 07:01PM, Marvin Humphrey wrote: > Greetings, > > The Corinthia community has voted to retire: > > http://s.apache.org/odN > > This is a vote of the IPMC to confirm the decision to retire the podling. > > [ ] +1 to retire Corinthia from the Incubator > [ ] -1 to keep Corinthia in the Incubator > > This vote will be held open for at least 72 hours. > > Should this vote pass, I have volunteered to assist Corinthia with retirement, > as I am assisting Droids and Kalumet. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [DISCUSS] Kudu incubator proposal
On Tue, Nov 17, 2015 at 10:43AM, Todd Lipcon wrote: > On Tue, Nov 17, 2015 at 10:38 AM, Atri Sharma wrote: > > > Sounds great. > > > > I would love to be an help as a committer, if possible. This seems to be > > fantastic in line with my focus areas and can help existing big data > > projects to accelerate so Kudu's growth is something I would care about. > > > > Hi Atri, > > Thanks for the interest! Following the example of other recent incubator > projects, we would like to keep the initial committer list to those who are > already have a track record of contributions to the project. We'd love to > have you involved as a contributor during incubation, and of course would > be glad to add you as a committer after you've become a regular contributor. Considering that the project has been closed-sourced until very recently such "following" would surely create pretty high entry barrier for new committers. Which of course would be a concern, from the community growth perspective. Cos signature.asc Description: Digital signature
Re: [DISCUSS] Impala incubator proposal
On Tue, Nov 17, 2015 at 02:26PM, Henry Robinson wrote: > Hi Henry - > > Absolutely, although I want to point out that only two of our three mentors which clearly constitutes "almost all" as Henry pointed out :) On a different note: have the initial delopers considered a possibility of bringing the code to Apache Drill, which in my uneducated view seems to be covering most of the bases in this case? Thanks, Cos > are Cloudera employees. That said, we'd of course be delighted to consider > any additional offers of mentorship. > > Best, > Henry > > On 17 November 2015 at 14:17, Henry Saputra wrote: > > > Glad to have the proposal :) > > > > Immediate glance would show almost all, including mentors, are coming from > > Cloudera. I think it would be beneficial for the podling to have at > > least mentors from different org to provide bit of balance. > > > > - Henry > > > > On Tuesday, November 17, 2015, Henry Robinson wrote: > > > > > Hi all - > > > > > > We'd like to start a discussion regarding a proposal to submit Impala to > > > the Apache Incubator. > > > > > > The proposal text is available on the Wiki here: > > > https://wiki.apache.org/incubator/ImpalaProposal > > > > > > and pasted below for convenience. > > > > > > I'm excited to make this proposal, and look forward to the community's > > > input! > > > > > > Best, > > > Henry > > > > > > > > > = Abstract = > > > Impala is a high-performance C++ and Java SQL query engine for data > > stored > > > in Apache Hadoop-based clusters. > > > > > > = Proposal = > > > > > > We propose to contribute the Impala codebase and associated artifacts > > (e.g. > > > documentation, web-site content etc.) to the Apache Software Foundation > > > with the intent of forming a productive, meritocratic and open community > > > around Impala’s continued development, according to the ‘Apache Way’. > > > > > > Cloudera owns several trademarks regarding Impala, and proposes to > > transfer > > > ownership of those trademarks in full to the ASF. > > > > > > = Background = > > > Engineers at Cloudera developed Impala and released it as an > > > Apache-licensed open-source project in Fall 2012. Impala was written as a > > > brand-new, modern C++ SQL engine targeted from the start for data stored > > in > > > Apache Hadoop clusters. > > > > > > Impala’s most important benefit to users is high-performance, making it > > > extremely appropriate for common enterprise analytic and business > > > intelligence workloads. This is achieved by a number of software > > > techniques, including: native support for data stored in HDFS and related > > > filesystems, just-in-time compilation and optimization of individual > > query > > > plans, high-performance C++ codebase and massively-parallel distributed > > > architecture. In benchmarks, Impala is routinely amongst the very highest > > > performing SQL query engines. > > > > > > = Rationale = > > > > > > Despite the exciting innovation in the so-called ‘big-data’ space, SQL > > > remains by far the most common interface for interacting with data in > > both > > > traditional warehouses and modern ‘big-data’ clusters. There is clearly a > > > need, as evidenced by the eager adoption of Impala and other SQL engines > > in > > > enterprise contexts, for a query engine that offers the familiar SQL > > > interface, but that has been specifically designed to operate in massive, > > > distributed clusters rather than in traditional, fixed-hardware, > > > warehouse-specific deployments. Impala is one such query engine. > > > > > > We believe that the ASF is the right venue to foster an open-source > > > community around Impala’s development. We expect that Impala will benefit > > > from more productive collaboration with related Apache projects, and > > under > > > the auspices of the ASF will attract talented contributors who will push > > > Impala’s development forward at pace. > > > > > > We believe that the timing is right for Impala’s development to move > > > wholesale to the ASF: Impala is well-established, has been > > Apache-licensed > > > open-source for more than three years, and the core project is relatively > > > stable. We are excited to see where an ASF-based community can take > > Impala > > > from this strong starting point. > > > > > > = Initial Goals = > > > Our initial goals are as follows: > > > > > > * Establish ASF-compatible engineering practices and workflows > > > * Refactor and publish existing internal build scripts and test > > > infrastructure, in order to make them usable by any community member. > > > * Transfer source code, documentation and associated artifacts to the > > ASF. > > > * Grow the user and developer communities > > > > > > = Current Status = > > > > > > Impala is developed as an Apache-licensed open-source project. The source > > > code is available at http://github.com/cloudera/Impala, and developer > > > documentation is at https://github.com/cloudera/Impala/wiki. The > > majority > > > o
Re: RTC vs CTR (was: Concerning Sentry...)
On Mon, Nov 16, 2015 at 04:50PM, Greg Stein wrote: > On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon wrote: > >... > > > 1) You're right, I don't trust anybody to make code changes to a complex > > project with zero oversight. I currently work on a project that I > > > > I have always found the "complex project" to merely be an excuse for > control/no-trust. > > All software is hard. Your project is no more complex than others. +1 on that and what Ralph said. CTR provides a huge stimuli not to write-n-push a crappy or semi-baked code. Precisely because of the trust put on them by the community of the peers. Cos signature.asc Description: Digital signature
Re: RTC vs CTR (was: Concerning Sentry...)
On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote: > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning wrote: > > ...RTC can be framed as "I don't trust you to do things right"... > > Or also "I don't trust myself 100% to do things right here and would > like systematic reviews of my commits". This sounds like "if I don't trust myself then no-one has to have this freedom/choice/ability", eh? > Like all sharp tools I think RTC has its place, but shouldn't be > abused. It's perfectly possible to have some parts of a project's code > under RTC and others under CTR. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: Digital signature
Re: [DISCUSS] Kudu incubator proposal
On Tue, Nov 17, 2015 at 04:33PM, Todd Lipcon wrote: > > > > > > > Hi Atri, > > > > > > Thanks for the interest! Following the example of other recent incubator > > > projects, we would like to keep the initial committer list to those who > > are > > > already have a track record of contributions to the project. We'd love to > > > have you involved as a contributor during incubation, and of course would > > > be glad to add you as a committer after you've become a regular > > contributor. > > > > Considering that the project has been closed-sourced until very recently > > such > > "following" would surely create pretty high entry barrier for new > > committers. > > Which of course would be a concern, from the community growth perspective. > > > > Sure, I expect the IPMC and our mentors to hold us to reasonable > expectations during incubation. > > For now, I think "meritocracy" should be followed -- when contributors > demonstrate sufficient merit, we can add them as committers. Note that > there are plenty of my coworkers who have made small contributions in the > past, and they aren't listed as contributors either. So, you're saying that people were chosen to be listed or not as the contributors merely by the amount of the code they have contributed to the project. Am I reading this right? Cos signature.asc Description: Digital signature
Re: RTC vs CTR (was: Concerning Sentry...)
On Tue, Nov 17, 2015 at 04:45PM, Todd Lipcon wrote: > On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik wrote: > > > On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote: > > > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning > > wrote: > > > > ...RTC can be framed as "I don't trust you to do things right"... > > > > > > Or also "I don't trust myself 100% to do things right here and would > > > like systematic reviews of my commits". > > > > This sounds like "if I don't trust myself then no-one has to have this > > freedom/choice/ability", eh? > > > > I'd never advocate that the ASF _mandate_ RTC on other projects. But if a > project community decides to set up their process as such, I don't see why > the foundation should have any issues with it. That's all I've been arguing > in this thread: this whole discussion has pretty much no business in the > incubator. On the contrary... The business of the Incubator and IPMC is to help podlings and their communities to grok and follow the Apache Way. Trust is a foundation principal of a healthy community. Hence, this whole discussion has quite a lot of business in the incubator. Cos signature.asc Description: Digital signature
