Re: Do we need a disclaimer? (Storm)
First few words should read "A disclaimer ..." I blame a combo of jet lag and *really* slow net link. Not the guy who hit send without proofing, of course. On Fri, Nov 15, 2013 at 7:41 AM, Ted Dunning wrote: > > I disclaimer to clarify that the 0.9.0 release is neither an Apache > top-level project release nor an Apache incubator release is probably good. > A file name like DISCLAIMER might be good. > > I would worry about it being clear rather than being totally crafted by a > true legal mind. > > > On Fri, Nov 15, 2013 at 4:48 AM, P. Taylor Goetz wrote: > >> The Strom project is just entering the incubator. We have promised our >> community that we will issue a stable 0.9.0 release prior to switching over >> to the Apache release process. We are currently in a release candidate >> process. >> >> Now that we are an Incubator project, but not yet releasing under the >> Apache process, should we be including a disclaimer with our pre-Apache >> releases stating so? >> >> It feels like we should have some sort legalese in place. >> >> - Taylor >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >
Re: Cultivating Outstanding IP Stewards
On Thu, Nov 14, 2013 at 1:08 AM, ant elder wrote: > What i'd like to try is more similar to the pTLP approach previously > talked about. So take some existing podling, eg Stratos and/or > VXQuery, and give the PPMC binding votes. They have experienced and > active mentors so there will be oversight and nothing to worry about. > They already have experienced participants so know what they're doing > anyway. Anyone on the Incubator PMC can join in or watch what happens > and intervene at any point to have the experiment shutdown in the > unlikely event that they go wild. I think there are some issues with that approach. * Being listed in the initial committer list of a proposal is not sufficient justification for granting a binding vote. Each individual needs to demonstrate merit in the context of incubation and there needs to be a VOTE. * When it's already excruciatingly difficult to get IPMC members to review releases, making such reviews optional just means hardly anybody will get around to them -- even if they have the best of intentions. * Under this model, a first incubating release could be approved with solely PPMC votes. We need more accountability than that. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On Wed, Nov 13, 2013 at 10:47 AM, Alex Harui wrote: > I still think that having a "Release Auditor" role provides backup for > getting incubator releases out without having folks have to be on the IPMC > to approve the legal aspects of a release. Just like any ASF Member can > backup busy PMC Chairs for some actions, any TLP PMC member should be able > to backup a busy IPMC member for release auditing. Speaking as someone who would presumably be suitable for this "Release Auditor" role, I'm opposed to the idea -- and not just because I don't want to get stuck doing all the dirty work. People who sign up to Mentor a podling should expect to vote on releases -- especially the first. The Incubator PMC tasks Mentors with overseeing the IP clearance processes. A Mentor who votes +1 on the first incubating release is implicitly affirming that IP clearance was done properly -- because that was their assignment, and if something had gone awry they would surely not vote to release. A +1 vote from a "Release Auditor" who did not participate in IP clearance is much less meaningful: all it tells you is that whatever superficial inspection they performed on the finished product did not reveal any defects. If some committer mistakenly attaches an ALv2 header to a file that shouldn't have one, a "Release Auditor" won't find that. To catch such problems, you need someone monitoring the the dev and commits lists: possibly a Mentor, ideally a project contributor. The most meaningful +1 votes are those cast by enlightened core contributors, because they speak from deep knowledge of the code base and its history. IP stewardship is a continuous process, and the Incubator's goal should be to graduate communities with the motivation and expertise to attend to it over the long term -- not to certify code. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Do we need a disclaimer? (Storm)
If you release as an Apache Incubator project, the disclaimer is required. If you release as your prior project, with prior infra and procedures, then no. Note: you cannot release as an Incubator project unless you use Apache procedures. Cheers, -g On Nov 14, 2013 11:49 PM, "P. Taylor Goetz" wrote: > The Strom project is just entering the incubator. We have promised our > community that we will issue a stable 0.9.0 release prior to switching over > to the Apache release process. We are currently in a release candidate > process. > > Now that we are an Incubator project, but not yet releasing under the > Apache process, should we be including a disclaimer with our pre-Apache > releases stating so? > > It feels like we should have some sort legalese in place. > > - Taylor > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Do we need a disclaimer? (Storm)
The Strom project is just entering the incubator. We have promised our community that we will issue a stable 0.9.0 release prior to switching over to the Apache release process. We are currently in a release candidate process. Now that we are an Incubator project, but not yet releasing under the Apache process, should we be including a disclaimer with our pre-Apache releases stating so? It feels like we should have some sort legalese in place. - Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Release Apache Tajo-0.2-incubating RC3
Dear all, Thank you for your supports. At least vote period passed, and we have 3 IPMC +1s. We will proceed with the release. http://markmail.org/thread/njypqxvhlvwsnteb Binding votes (3) Henry Saputra (binding) Jakob Homan (binding) Olivier Lamy (binding) - hyunsik - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: the Voting Status monitor is overloaded
Thanks to those who did follow-up. That clears a bit. Another plea from me to help you to clear the clutter: I reviewed the mail archives for the outstanding ones to see why the "Vote Monitor" did not detect their vote result. I do not have time to correct them nor to tweak voter.py but hope that others can utilise my work. Here is a summary: As expected in my original mail, some tallies added extra words to the Subject, so tricked the monitor. Others did not tally. Others tallied but did not add RESULT tag. Others did cancel but did not add CANCEL tag. There were a few "community graduation" votes which were "Fwd:" but did not summarise. Perhaps voter.py could detect these "notices". There were a few with common mis-spelings, such as the CANCLE one. Thanks to Branko, the regex is nice. People could help to expand. Some possible tweaks to voter/voter.py are flagged below. Some situations could be cleared with a new RESULT or CANCEL email. Please assist. Notes: Release Apache Stratos 3.0.0 Incubating RC4 They added (passed) at the end of Subject. Release Apache Tajo-0.2-incubating RC1 Prepended tag CANCLE instead. (FIXME: voter/voter.py needs additional code to handle such typo errors.) (Now a follow-up has done a reply with CANCEL.) Apache Ambari 1.4.1-incubating RC1 No-one did summarise. Graduate Apache Marmotta from incubator and become a TLP This was a community graduation vote. Used "Fwd:" but not summarised. (FIXME: perhaps voter/voter.py needs additional code to handle such "notices".) Apache Kalumet 0.6-incubating release (3rd try) No-one did summarise. Usergrid BaaS Stack for Apache Incubator No-one did CANCEL. (A subsequent new thread was summarised, but this old one remains.) : Release Apache Sentry 1.2.0 incubating (rc0) Was tallied but no RESULT tag. Apache Chukwa graduation Was tallied and RESULT, but different thread with different Subject. first milestone release of Apache Drill (incubating) Was tallied, but broke the thread and removed the VOTE tag. Graduate Curator from Apache Incubator This was a community graduation vote. Used "Fwd:" but not summarised. (FIXME: perhaps voter/voter.py needs additional code to handle such "notices".) Release Apache Provisionr version 0.4.0-incubating, RC0 Was tallied and RESULT, but different thread with different Subject. Release Curator 2.1.0-incubating No-one did summarise. Release Apache Wave 0.4 based on RC3 No-one did summarise. Accept Stratos proposal as an incubating project Was tallied, and RESULT tag but had "Re: " in between the tags 2013-06-20 (FIXME: voter/voter.py needs additional code to handle this.) Accept Apache BeanShell in the Incubator No-one did summarise. Release Apache Mesos 0.11.0-incubating (RC1) No-one did tag with CANCEL helix 0.6.1-incubating Was tallied and RESULT, but different thread with different Subject. S4 0.6.0 Release Candidate 4 No-one did summarise. S4 0.6.0 Incubating Release Candidate 3 No-one did tag with CANCEL. Recommending DeltaSpike for Graduation to an Apache Top Level Project This was a community graduation vote. Used "Fwd:" but not summarised. (FIXME: perhaps voter/voter.py needs additional code to handle such "notices".) --- David Crossley wrote: > If the projects that are listed there cannot make the effort > to clean up, then do not be surpised if your subsequent > vote threads are overlooked. This is also not fair on the > other projects, especially new ones. > > -David > > David Crossley wrote: > > It seems that the brilliant "Voting Status" monitor > > has fallen into disrepair. Partly due to people > > not properly following up with a clear RESULT tally > > and partly perhaps inadequacies of the monitor script. > > > > Follow the top-left link from the Incubator home: > > http://incubator.apache.org/ > > > > Items coloured any shade of orange need attention. > > > > We all need to care for these tools to assist us > > through incubation efficiently. > > > > Would people who have an interest in each open entry > > please review the email archives to see why your > > result summary tally email was not detected. > > > > Perhaps you forgot to prepend "[RESULT]". > > Or maybe changed the email Subject too and so > > confused the monitor. > > > > If so then please send a followup to your VOTE thread. > > That will cause the monitor to clear its backlog. > > > > However, i do see some that should be marked as Resolved. > > > > So maybe the script that does this scan needs tweaks > > to pattern matching. The code is there for all > > in the top-level of Incubator SVN. > > http://incubator.apache.org/facilities.html#voting-status > > > > Please add more instructions to the docs: > > http://incubator.apache.org/facilities.html#voting-status > >
Re: [PROPOSAL] Phoenix for Incubation
+1 for Phoenix as well. SQL access for HBase is a repeated thread in the community and while we probably aren't at the point where there is a single answer for this - and may never be - it would be nice to have a few "preferred options", so to speak, with robust communities around them. Also, per Andy's point about SQL not being a non-goal of HBase proper, I agree, hence another project makes sense. I see both good capabilities and a growing community around Phoenix. Doug Meil On 11/14/13 12:41 PM, "Andrew Purtell" wrote: >On Wed, Nov 13, 2013 at 10:50 PM, Henry Saputra >wrote: > >> It is indeed very specific for HBase use I suppose. Would it be more >> beneficial to make it sub-project of HBase to get full community >> support from HBase? > > >I'm on the HBase PMC and am enthusiastically +1 for incubation of Phoenix >to become a TLP. > >Phoenix can be divided into a front end and a back end. > >The front end is delivered as a JDBC driver and contains, among other >things, the SQL parser and query planner. The front end is currently >written for the HBase client API but could be extended to support other >data stores in the Apache family. > >The back end is, currently, HBase specific components for pushing as much >work to the server as possible. However, if there were sufficient interest >to build them, contributions to Phoenix of new back ends for other data >stores in the Apache family would be feasible. > >Most importantly, as James mentioned in the proposal, much of the Phoenix >project's attention will focus on the query planning part. Supporting SQL >or any declarative query interface is to the best of my knowledge a >non-goal of the HBase community. > >-- >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
[CANCEL][VOTE] Release Apache Wave 0.4 based on RC3
Clean this up from the voting monitor. This has been superseded by RC4 at the project level anyway... Sorry for leaving it open for so long. (I may have forgotten it) Ali On 15 June 2013 23:24, Ali Lown wrote: > The Wave community has voted on and approved the proposal to release > Apache Wave 0.4 (incubating) based on RC3. > > This will be the initial incubator release for Wave. > > The proposal for release can be found at: > https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/%3ccabrgrvd6n5_llwuufaeky4kzldumd-txyadkmqwkmtfbwtg...@mail.gmail.com%3E > > The result from the wave-dev vote can be found at: > https://mail-archives.apache.org/mod_mbox/incubator-wave-dev/201306.mbox/%3CCABRGrVfPOwN3E8N-uScruYbxdezpfZzAJHMp8dN%2BUfpF6s%2BDGw%40mail.gmail.com%3E > > Wave 0.4 RC3 artefacts are available at: > https://people.apache.org/~al/wave_rc/0.4-rc3/ > Note: The checksums are SHA-512's > > This is a build from the subversion tag wave-0.4-rc3 at: > https://svn.apache.org/repos/asf/incubator/wave/tags/ > > A summary about the project and other information can be found in the > RELEASE-NOTES at: > https://people.apache.org/~al/wave_rc/0.4-rc3/RELEASE-NOTES > and is included in the tarballs. > > Votes, please. This vote will close at GMT 19-June 2013. > > [ ] +1 Release these artefacts > [ ] +0 OK, but... > [ ] -0OK, but really should fix... > [ ] -1I oppose this release because... > > Thanks. > Ali - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Phoenix for Incubation
On Thu, Nov 14, 2013 at 9:41 AM, Andrew Purtell wrote: > > On Wed, Nov 13, 2013 at 10:50 PM, Henry Saputra > wrote: > > > It is indeed very specific for HBase use I suppose. Would it be more > > beneficial to make it sub-project of HBase to get full community > > support from HBase? > > The back end is, currently, HBase specific components for pushing as much > work to the server as possible. However, if there were sufficient interest > to build them, contributions to Phoenix of new back ends for other data > stores in the Apache family would be feasible. Good points, Andrew, and an omission on my part from the proposal. We actually had someone internally do something similar for a POC. I'll update the proposal with this information. Regards, James > > > -- > 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
Re: [PROPOSAL] Phoenix for Incubation
Patrick Reilly php.net> writes: > > Phoenix is a wonderful addition as sub-project of HBase and I use it > everyday in production. > > +1 from me for sure. > > — Patrick > Sorry, I meant a top level project not a sub-project of HBase. I apologize for the confusion. — Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Phoenix for Incubation
Phoenix is a wonderful addition as sub-project of HBase and I use it everyday in production. +1 from me for sure. — Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Phoenix for Incubation
On Wed, Nov 13, 2013 at 10:50 PM, Henry Saputra wrote: > It is indeed very specific for HBase use I suppose. Would it be more > beneficial to make it sub-project of HBase to get full community > support from HBase? I'm on the HBase PMC and am enthusiastically +1 for incubation of Phoenix to become a TLP. Phoenix can be divided into a front end and a back end. The front end is delivered as a JDBC driver and contains, among other things, the SQL parser and query planner. The front end is currently written for the HBase client API but could be extended to support other data stores in the Apache family. The back end is, currently, HBase specific components for pushing as much work to the server as possible. However, if there were sufficient interest to build them, contributions to Phoenix of new back ends for other data stores in the Apache family would be feasible. Most importantly, as James mentioned in the proposal, much of the Phoenix project's attention will focus on the query planning part. Supporting SQL or any declarative query interface is to the best of my knowledge a non-goal of the HBase community. -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: [PROPOSAL] Phoenix for Incubation
On Wed, Nov 13, 2013 at 9:43 PM, James Taylor wrote: > Hi All, > > We're pleased to share a draft ASF incubation proposal for Phoenix, a > SQL layer over HBase, initially developed at Salesforce.com and > subsequently open sourced on github > (https://github.com/forcedotcom/phoenix). Instead of using Map-reduce > to processes queries, it compiles SQL directly into native HBase > calls. The complete proposal can be found here: > https://wiki.apache.org/incubator/PhoenixProposal, and is also pasted > below. > > Your feedback is greatly appreciated. > Enthusiastic (and rusty but binding) +1 We're looking forward to at least start using it, as well as hopefully start contributing to Phoenix in the next couple of months. Steven.
Re: [VOTE] Release Apache Tajo-0.2-incubating RC3
Thank you all guys for reviewing this release. We will move forward to the next step. Marvin, Thank you for your comment and advice. Your comments are very helpful for me to understand IPMC vote. Also, we will resolve IP audit before the next release. - hyunsik On Thu, Nov 14, 2013 at 9:46 AM, Olivier Lamy wrote: > +1 (binding) > > On 14 November 2013 03:23, Jakob Homan wrote: >> +1 (binding). Verified MD5. License, disclaimer and notice all look good. >> >> >> On Tue, Nov 12, 2013 at 8:07 PM, Hyunsik Choi wrote: >> >>> Ping - just a friendly reminder that we're seeking votes on our first >>> release here. >>> >>> - hyunsik >>> >>> On Sun, Nov 10, 2013 at 2:46 PM, Hyunsik Choi wrote: >>> > Dear IPMC members, >>> > >>> > If there are some reasons why you do not vote, please leave reasons >>> > here. I would like to proceed or cancel this vote. >>> > >>> > Best regards, >>> > Hyunsik Choi >>> > >>> > On Thu, Nov 7, 2013 at 11:59 AM, Hyunsik Choi >>> wrote: >>> >> Are there other IPMC members who are willing to review this release? We >>> need >>> >> two more votes! >>> >> >>> >> - hyunsik >>> >> >>> >> 2013년 11월 4일 월요일에 Hyunsik Choi님이 작성: >>> >> >>> >>> Hi folks >>> >>> >>> >>> This is the fourth candidate for Apache Tajo-0.2-incubating, >>> >>> and it is also the first official release for Tajo. >>> >>> >>> >>> The PPMC vote [1][2][3] was passed with 3 binding +4s and no -1. >>> >>> >>> >>> Release git tag is at: >>> >>> >>> >>> >>> https://git-wip-us.apache.org/repos/asf?p=incubator-tajo.git;a=shortlog;h=refs/tags/release-0.2.0-rc3 >>> >>> >>> >>> Release notes is at: >>> >>> >>> >>> >>> http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/RELEASE_NOTES.html >>> >>> >>> >>> Release artifacts, signatures, md5, and sha1 are at: >>> >>> http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/ >>> >>> >>> >>> and the KEYS file containing the PGP keys used to sign the release can >>> >>> currently be found at: >>> >>> http://people.apache.org/keys/group/tajo.asc >>> >>> >>> >>> The RAT report is at: >>> >>> http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/rat.txt >>> >>> >>> >>> Please vote >>> >>> [ ] +1 release this package as apache-tajo-0.2-incubating >>> >>> [ ] -1 do not release this package because ... >>> >>> >>> >>> Thanks, >>> >>> Hyunsik Choi >>> >>> >>> >>> [1] http://markmail.org/message/cvwzgdfkq2zfmmbo >>> >>> [2] http://markmail.org/message/crhbpagwo3pvm4et >>> >>> [3] http://markmail.org/message/kofx3nfjzcr7chqu >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > 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: Cultivating Outstanding IP Stewards
Those sound like fine experiments to try - having a release auditor, and a new podling with the PPMC have binding votes and initially seeded just with IPMC members - however they aren't the experiments i was thinking of. What i'd like to try is more similar to the pTLP approach previously talked about. So take some existing podling, eg Stratos and/or VXQuery, and give the PPMC binding votes. They have experienced and active mentors so there will be oversight and nothing to worry about. They already have experienced participants so know what they're doing anyway. Anyone on the Incubator PMC can join in or watch what happens and intervene at any point to have the experiment shutdown in the unlikely event that they go wild. Its just a small experimental trial. Even if successful this likely wouldn't ever become the approach used for most podlings, but it could be a useful step for some. Lets give it a try. What do you say? ...ant On Wed, Nov 13, 2013 at 7:05 PM, Suresh Marru wrote: > On Nov 13, 2013, at 1:14 PM, Marvin Humphrey wrote: > >> On Tue, Nov 12, 2013 at 11:58 PM, ant elder wrote: >>> So, we _can_ let podlings have their own binding release votes and we >>> could do our own "pTLP" type experiments without even needing to go to >>> the board. We should try that. Not for every podling but just for >>> select ones where the circumstances mean it will work better than the >>> current approach. If there are no major objections to some experiments >>> with this approach then i'd like to start trying one. >> >> +1 to run an experiment. The position that Roy has taken changes the >> equation. >> >> While a number of people have expressed a preference for the approach of >> electing more podling contributors directly onto the IPMC, in practice it >> remains uncertain whether the IPMC is capable of identifying, nominating and >> voting in enough candidates -- as evidenced by some threads currently in >> progress on private@incubator. >> >> I propose that the experiment take the following form: >> >> 1. The initial PPMC shall be composed exclusively of IPMC members. >> 2. PPMC votes are binding for every release except the first. >> 3. One IPMC vote is required for each release after the first. >> >> I believe that this model provides sufficient oversight because the first >> release must cross a high bar, and because it changes the dynamics of >> electing PPMC members: even core contributors will now have to earn PPMC >> membership, demonstrating to an initial PPMC composed of IPMC members that >> they understand the Apache Way well enough to steward their project. > > + 1, I like this balance and caveats. > > In my personal view (which I am not generalizing), getting the first release > is very time consuming but educational and very much worth it. I do not look > at it as one month or so for a release is unreasonable, but rather think it > as, one month amortized over quality subsequent releases. Which ever approach > or policy changes we take, we still need patient incumbents and overly > patient mentors. The only way mentors scale is to teach the process and groom > new teachers. Ofcourse not many students will like the teachers until they > also become teachers. Atleast this happened to me, I appreciate my mentors > more now then when I was a student :) > > Suresh > >> >> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
