Re: IP Clearance before releasing
On Sun, Dec 8, 2013 at 12:43 AM, Marvin Humphrey mar...@rectangular.comwrote: Greets, I read in the Tajo report and I see on the dev list that the Tajo developers are now diligently tackling IP clearance: http://s.apache.org/00w In my view, IP clearance is only the remain work for graduation. That was also my understanding, that IP clearance is important, and neccessary for successful incubation, but incubator releases are orthogonal and therefore carry a disclaimer being not fully vetted Apache releases because of IP and other open issues. Have I missed a change here to our policie? However, the fact that this is only happening now represents a failure of the IPMC. Tajo made a release last month. That release should not have gotten our go-ahead until IP clearance was completed[1]. In the reference [1], what exactly are you referring to? [1] http://incubator.apache.org/projects/tajo.html http://incubator.apache.org/incubation/Incubation_Policy.html#Releases http://incubator.apache.org/guides/mentor.html#initial-ip-clearance Thanks, Bernd
Re: IP Clearance before releasing
On Sun, Dec 8, 2013 at 6:14 AM, Bernd Fondermann bernd.fonderm...@gmail.com wrote: That was also my understanding, that IP clearance is important, and neccessary for successful incubation, but incubator releases are orthogonal and therefore carry a disclaimer being not fully vetted Apache releases because of IP and other open issues. So it's OK to release even if we don't have rights to the source code? Surely even the most liberal interpretation of what is permissible under incubating has limits. Have I missed a change here to our policie? No. In the reference [1], what exactly are you referring to? [1] http://incubator.apache.org/projects/tajo.html http://incubator.apache.org/incubation/Incubation_Policy.html#Releases http://incubator.apache.org/guides/mentor.html#initial-ip-clearance From the Incubation Policy page: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases Such approval SHALL be given only after the Incubator PMC has followed the process detailed in these guidelines, and SHALL NOT occur until all source has been legally transferred to the ASF. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
My understanding is that incubating releases can have small IP loose ends, but not that they can proceed before the main clearance of an initial code donation. On Sun, Dec 8, 2013 at 9:38 AM, Marvin Humphrey mar...@rectangular.com wrote: On Sun, Dec 8, 2013 at 6:14 AM, Bernd Fondermann bernd.fonderm...@gmail.com wrote: That was also my understanding, that IP clearance is important, and neccessary for successful incubation, but incubator releases are orthogonal and therefore carry a disclaimer being not fully vetted Apache releases because of IP and other open issues. So it's OK to release even if we don't have rights to the source code? Surely even the most liberal interpretation of what is permissible under incubating has limits. Have I missed a change here to our policie? No. In the reference [1], what exactly are you referring to? [1] http://incubator.apache.org/projects/tajo.html http://incubator.apache.org/incubation/Incubation_Policy.html#Releases http://incubator.apache.org/guides/mentor.html#initial-ip-clearance From the Incubation Policy page: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases Such approval SHALL be given only after the Incubator PMC has followed the process detailed in these guidelines, and SHALL NOT occur until all source has been legally transferred to the ASF. 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: Release Verification Checklist
On Dec 6, 2013, at 8:53 AM, Roman Shaposhnik wrote: On Thu, Dec 5, 2013 at 2:32 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Dec 4, 2013 at 1:31 AM, Marvin Humphrey mar...@rectangular.com wrote: http://svn.apache.org/repos/asf/incubator/public/trunk/votes/$PODLING/$RC ... Added to a new usage proposal section at https://wiki.apache.org/incubator/ReleaseChecklist - does that proposal work for you guys? I like it. It basically looks like sebb-in-a-box to me (or should be elastic sebb these days?) ;-) I like it. I think two more improvements are needed: (1) PPMC members should be sure to record the votes of community members who are not PPMC/committers and have no apache id. (2) The header should include a reference to the VOTE thread. Adding the community votes and thread reference can help the IPMC assess the other major graduation criteria - community viability and growth. We need to assess sustainability. Regards, Dave 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: Release vote thresholds
On Dec 5, 2013, at 7:26 PM, Marvin Humphrey wrote: On Sun, Dec 1, 2013 at 12:41 PM, Dave Fisher dave2w...@comcast.net wrote: I am only comfortable allowing singular IPMC votes from members of the ASF. I think the IPMC owes this much to the other members of the Foundation. I've now contemplated this condition for a few days and while I'm prepared to accept it for the sake of compromise, I'm not in favor of it. As I look over the IPMC roster, there may be people who are not the strongest with regards to reviewing releases (they are often strong in other areas), but I don't see a correlation between those people and whether or not they were elected onto the IPMC. If anything, it's the opposite -- the people who routinely miss errors, cast bare +1 votes with no explanations of what they reviewed, or fail to vote at all, are most often ASF Members who exercised their prerogative to join the IPMC by request. In contrast, the people who got onto the IPMC by demonstrating Incubator merit and getting elected tend to be more conscientious. If any group stands out as particularly competent, it is those who were elected onto the IPMC first and subsequently became ASF Members. But in my estimation, the group which would be excluded under this proposal -- people who were elected onto the IPMC but who are not ASF Members (yet) -- is on average, considerably above the level of the IPMC as a whole[1]. So... I question whether this provision will succeed at guaranteeing that solo IPMC votes come from someone highly competent. It complicates the release process by stratifying the IPMC. And it doesn't jibe with my sense of meritocracy. So, do you agree to the rule of three IPMC? Any Member can be on the IPMC. Your argument above can be expanded to support the status quo. Can we drop the VXQuery experiment notion? I put the comfort level and Member vs. IPMC as more of a thought experiment. I'd rather that we go with Bertrand's proposal unmodified, which takes a different tack: striving to improve the quality of each vote cast. What do others think? I am not an other, but... I like where Bertrand's proposal is going and it is something that can be used to assess all podlings great and small. My concerns and lack of comfort with this experiment were more to do with notion that not being able to provide oversight was leading to an experiment with institutionalizing less oversight. My argument about ASF members is that it is The ASF members who are responsible - we elect the Board. My one was asking what would be the bare minimum, it was more of a reductio ad absurdum. I think that we all are looking for Incubation to be a natural growth of a community's culture and not a process that involves unnecessarily high barriers. We are looking to create the flattest petri dish possible. What I like about Joe's experiment that the Incubator is the place to find people who are member material as this is more visible to more of the membership than people who gain merit within an individual TLP. You certainly agree. My other point was that the notion of the VXQuery experiment was going to be an invalid experiment because that podling has already had someone moved into the IPMC using the Joe experiment. So, even if the release threshold experiment was worth pursuing in this case the results would be hard to assess one way or another. I think that the situation is very positive for VXQuery. The podling has shown sustainability as it has refreshed the community with people who earned merit in the community while original members have moved on. Next question is if they have enough numbers. Here we will run into the 3 PPMC vs. 5 PPMC discussion. Regards, Dave Marvin Humphrey [1] Let's avoid mentioning names on the public list. - 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: Release Verification Checklist
On 6 December 2013 20:55, ant elder ant.el...@gmail.com wrote: On Fri, Dec 6, 2013 at 1:40 AM, Marvin Humphrey mar...@rectangular.comwrote: On Thu, Dec 5, 2013 at 8:38 AM, sebb seb...@gmail.com wrote: On 5 December 2013 10:37, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Dec 3, 2013 at 11:39 PM, Marvin Humphrey mar...@rectangular.com wrote: ... Second, I'm amused that the commits list item was quietly dropped, but new checklist items have been inserted regarding the dev and private lists... Pure oversight on my part, sorry...but what would we do if no reviewer follows the commit lists? I don't think that's a reason to kill a release. Oversight of the commit list is vital; that is how we ensure that SCM only contains material that is permitted. The source release is then checked against SCM to ensure we are only published vetted material. If there is no review of the commit list, then the whole system breaks down. I certainly agree that following the commits list is essential (and sought to emphasize as much in the post at the top of the thread). I'd barely even considered the possibility that *none* of the reviewers might be following the commits list. However, I think that Bertrand's provenance checklist item largely achieves what I'd been grasping for with the commits list item, and fits much better into the context of approving the release. If nobody's following the commits list, that's an issue with serious implications for the project, but it's not a direct release blocker. If provenance is unsettled, though, that clearly blocks the release. Personally, I wouldn't feel confident checking the provenance item if I wasn't watching the commits list. It's true that the person making the commit affirms that they have the right to their contribution, but still, I feel like you need to at least be aware of what contributions have gone into the product. Maybe there ought to be a note to such effect on the explanations page. But in any case, I'm OK with the commits list item disappearing, so long as the provenance item stays. As of revision 14 (removing the dev list and private list items) I'm now generally satisfied with the content of the checklist items and hope to move on to refining the workflow and surrounding documentation. All the stuff required to be checked when voting on a release should be documented in the ASF doc about releases. That its not in that doc suggests its not required. If someone thinks something is required then they should go get consensus around that with the wider ASF and get the ASF doc updated. Podling releases are not quite the same as TLP releases, thats why they have the DISCLAIMER and incubating naming. I think we should be making it easier for podlings to do releases, if its really necessary then make an audit of the last release a requirement of graduation. ...ant +1 I don't see why releasing in incubator must be more complicated than in TLPs and have more rules. We have a lot of pending votes and I see you guys discussing about rules why not spend your times on having a look at those votes... And with such discussion we don't look very attractive. Isn't the goal of the ASF to have a lot of project developed here? Sorry personally I don't have time to read/participate the whole thread as I prefer to spend my time on writing softwares. But my participation could be: is it possible to add something in the verification checklist as Build great/usable software for our lovely users Cheers -- /me tired reading all of this over complicated administrative threads... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Sirona 0.1-incubating
So please instead of discussing again about procedures. Just discuss about the release :-) /me trying to rock the boat On 7 December 2013 12:05, Marvin Humphrey mar...@rectangular.com wrote: On Fri, Dec 6, 2013 at 3:23 PM, John D. Ament john.d.am...@gmail.com wrote: I just wanted to clarify with you. What you're saying is that a podling must have three PPMC votes. Once that is done, they must then send the release to the incubator to vote. Once 3 IPMC's approve it, it's ready to go, right? Here's the official answer, from the Incubator's policy page: http://incubator.apache.org/incubation/Incubation_Policy.html#Releases Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL hold a vote on the Podling's public -dev list. At least three +1 votes are required (see the Apache Voting Process page). If the majority of all votes is positive, then the Podling SHALL send a summary of that vote to the Incubator's general list and formally request the Incubator PMC approve such a release. Three +1 Incubator PMC votes are required. Our release management guide, as is often the case, duplicates information better described elsewhere, adding inaccuracies and misleading rephrasings. http://incubator.apache.org/guides/releasemanagement.html#glossary-release-manager Marvin Humphrey - 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
Re: [VOTE] Phoenix for incubator project
Enthusiastic +1 for Phoenix. Thanks, Eli On Sat, Dec 7, 2013 at 2:37 PM, Nick Dimiduk ndimi...@gmail.com wrote: +1 from me; Phoenix is good for HBase and Apache is good for Phoenix, a virtuous cycle! On Thursday, December 5, 2013, Stack wrote: Discussion of the Phoenix proposal has settled since its original posting on November 7th. Feedback has been incorporated. Let us now move to a vote. Should Phoenix become an Apache incubator project? [] +1 Accept Phoenix into the Incubator [] +0 Don't care whether or which [] -1 Do not accept Phoenix into the Incubator because... The latest version of the proposal can be found here [1]. It is also posted below for your convenience. Let the vote run 72 hours. Thank you, St.Ack 1. https://wiki.apache.org/incubator/PhoenixProposal Abstract Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. Proposal Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. Background Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. Rationale As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. Initial Goals The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. Current Status Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. Meritocracy The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as 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 Phoenix project would include several of these participants as initial committers. 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 Phoenix. That community includes many contributors from various other companies, and
Re: Release Verification Checklist
On Fri, Dec 6, 2013 at 1:55 AM, ant elder ant.el...@gmail.com wrote: All the stuff required to be checked when voting on a release should be documented in the ASF doc about releases. That its not in that doc suggests its not required. If someone thinks something is required then they should go get consensus around that with the wider ASF and get the ASF doc updated. OK, I've done the research and I've migrated the manifest proposal to a new documentation page with the links. The ReleaseChecklist wiki page is now a home for optional checklist items. http://incubator.apache.org/guides/release.html https://wiki.apache.org/incubator/ReleaseChecklist Applying your criteria to the current checklist has resulted in the migration of two items to the optional list: * Each expanded source archive matches the corresponding SCM tag. It turns out the only place matching the SCM tag was documented is the Incubator's Release Management guide. Here's Leo Simons making the case against: http://markmail.org/message/2ncepopzgnshtyd6. * Build instructions are provided, unless obvious I haven't found any documentation that this is required anywhere on www.apache.org/dev or www.apache.org/legal. Bertrand, between me arguing that this won't come into play often enough and Ant and Olivier arguing that we should only include blockers documented elsewhere, I've made the judgment call that this should be moved to the optional list as well. Please let us know if you object. Podling releases are not quite the same as TLP releases, thats why they have the DISCLAIMER and incubating naming. I think we should be making it easier for podlings to do releases, if its really necessary then make an audit of the last release a requirement of graduation. I am passionately committed to making it easier for podlings to release, by granting limited self-governance to those who earn it. The proposal under consideration is a win for *both* streamlining the release voting process and improving release oversight. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Sun, Dec 8, 2013 at 2:49 PM, Olivier Lamy ol...@apache.org wrote: We have a lot of pending votes and I see you guys discussing about rules why not spend your times on having a look at those votes... If we succeed in changing the system so that my participation doesn't let AWOL Mentors off the hook[1], deny meritorious PPMC members self-governance[2], or perpetuate a status quo of inferior IP oversight[3], I definitely look forward to reviewing releases once again. And with such discussion we don't look very attractive. Isn't the goal of the ASF to have a lot of project developed here? I think we should be more embarrassed about actual errors than about what it looks like as we design processes intended to avoid them. The recent glitches with improper release vote counting[4] and not completing IP clearance before releasing[5] both would have been prevented by using the checklist. Besides, if we're talking about how the Incubator looks to outsiders, shouldn't we be concerned that we routinely have so much trouble getting IPMC members to vote on releases? This proposal is designed to ameliorate that problem. Sorry personally I don't have time to read/participate the whole thread as I prefer to spend my time on writing softwares. Not everybody has to follow every twist and turn of development. When we have something sufficiently mature, I'll start a PROPOSAL thread. Please watch for that. In the meantime, please continue to enjoy writing software! :) Marvin Humphrey [1] http://s.apache.org/Kca [2] http://s.apache.org/qSW [3] http://s.apache.org/bsy [4] http://s.apache.org/zjp [5] http://s.apache.org/tDf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Sirona 0.1-incubating
On Sun, Dec 8, 2013 at 8:20 PM, Olivier Lamy ol...@apache.org wrote: So please instead of discussing again about procedures. Just discuss about the release :-) /me trying to rock the boat Sirona has FIVE Mentors, plus another committer who is on the IPMC. Only two of you have voted: you and Jean-Baptiste Onofré. The project just entered incubation two months ago. Where is everybody? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
Hi, Been following the thread and noticed one of the items on the list is: Issue tracker clean for release version. Is that really expected? I would expect progress and issue closed since last release but not everything in the issue tracker addressed. Is it clear what clean means in this context? Committers work and fix what they want (scratch your own itch), some issues may take a while to get fixed (span releases) and some may never get fixed. A project coming into Apache may also have a number of existing issues and fixing them all may not even be possible in a reasonable amount of time. Thanks, Justin On Mon, Dec 9, 2013 at 3:49 PM, Marvin Humphrey mar...@rectangular.comwrote: On Fri, Dec 6, 2013 at 1:55 AM, ant elder ant.el...@gmail.com wrote: All the stuff required to be checked when voting on a release should be documented in the ASF doc about releases. That its not in that doc suggests its not required. If someone thinks something is required then they should go get consensus around that with the wider ASF and get the ASF doc updated. OK, I've done the research and I've migrated the manifest proposal to a new documentation page with the links. The ReleaseChecklist wiki page is now a home for optional checklist items. http://incubator.apache.org/guides/release.html https://wiki.apache.org/incubator/ReleaseChecklist Applying your criteria to the current checklist has resulted in the migration of two items to the optional list: * Each expanded source archive matches the corresponding SCM tag. It turns out the only place matching the SCM tag was documented is the Incubator's Release Management guide. Here's Leo Simons making the case against: http://markmail.org/message/2ncepopzgnshtyd6. * Build instructions are provided, unless obvious I haven't found any documentation that this is required anywhere on www.apache.org/dev or www.apache.org/legal. Bertrand, between me arguing that this won't come into play often enough and Ant and Olivier arguing that we should only include blockers documented elsewhere, I've made the judgment call that this should be moved to the optional list as well. Please let us know if you object. Podling releases are not quite the same as TLP releases, thats why they have the DISCLAIMER and incubating naming. I think we should be making it easier for podlings to do releases, if its really necessary then make an audit of the last release a requirement of graduation. I am passionately committed to making it easier for podlings to release, by granting limited self-governance to those who earn it. The proposal under consideration is a win for *both* streamlining the release voting process and improving release oversight. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
