Re: What is the legal basis for enforcing release policies at ASF?
This thread started as a discussion of Linux distros and trademarks. Perhaps I could try to return it there? If a distro takes a release of Apache X, compiles it with minimal changes that adapt it to the environment, and distributes it, I believe that it's a fine thing for them to call it simple Apache X, and acknowledge our marks. If a distro takes a release of Apache X, and make significant changes to it, and then distributes it, I believe that it's not OK with us for them to simply call it Apache X. I've seen some evidence that Gentoo Linux makes a regular habit of this, because their policies drive them to make some pretty scary changes in some cases. Others may not share my view. Further, if someone takes a snapshot (small 's') from source control and starts from that, with minimal changes, I think that this would also be trademark-acceptable, so long as they accurately describe what they did. The operative concept here, as Shane has taught it, is 'confusion in the marketplace.' If some third party behaves so as to cause confusion as to the identity of Apache X, there's a trademark issue. If not, not.
Re: What is the legal basis for enforcing release policies at ASF?
On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski j...@jagunet.com wrote: Coming in late. A snapshot is not a release. Licenses kick in at distribution/ release. Are you sure? When you have a public source control repo, with a LICENSE file at the top, I would think that this counts as a legal 'publication' under the terms of the license. if not, just what is the legal status of source code snipped from our repositories? There is also a trademark issue as well... only the ASF can declare something as a release. On Aug 6, 2015, at 8:50 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Hi! while answering a question on release policies and ALv2 I've suddenly realized that I really don't know what is the legal basis for enforcing release policies we've got documented over here: http://www.apache.org/dev/release.html For example, what would be the legal basis for stopping a 3d party from releasing a snapshot of ASF's project source tree and claim it to be a release X.Y.Z of said project? 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: What is the legal basis for enforcing release policies at ASF?
On Fri, Aug 7, 2015 at 12:08 PM, Gregory Chase gch...@pivotal.io wrote: Does ...based on Apache Hadoop require a clear dependency notation as to which versions of Apache component releases are part of the commercial distribution? No, it cannot. Trademark law is not a matter of such distinctions, and our very own Apache License imposes no such complexity. On Fri, Aug 7, 2015 at 5:39 AM, Sam Ruby ru...@intertwingly.net wrote: On Fri, Aug 7, 2015 at 7:53 AM, Niclas Hedhman nic...@hedhman.org wrote: Bill, So I can release Niclas Hadoop platform, based on Apache Hadoop ?? I thought the discussion a few years ago was that this was misleading... Things in law are rarely binary except at the edges or after an actual court ruling. Releasing a Niclas George platform powered by Apache Hadoop conforms with our branding requirements, so would likely be OK. The further you go away from that, the less clear that what you are doing would be OK. Hadoop would be a especially problematic case for you, as Apache Hadoop, Hadoop, Apache, the Apache feather logo, and the Apache Hadoop project logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and other countries. -- https://hadoop.apache.org/ http is a more generic term, so including variants of it in your name (including httpd) would be less problematic than incorporating a name like Hadoop. - Sam Ruby On Fri, Aug 7, 2015 at 12:30 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Thu, Aug 6, 2015 at 7:50 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Hi! while answering a question on release policies and ALv2 I've suddenly realized that I really don't know what is the legal basis for enforcing release policies we've got documented over here: http://www.apache.org/dev/release.html For example, what would be the legal basis for stopping a 3d party from releasing a snapshot of ASF's project source tree and claim it to be a release X.Y.Z of said project? Nothing other than the Trademarks. If someone wants to call httpd trunk 3.0.1-GA, they cannot do this as Apache httpd 3.0.1-GA or Apache HTTP Server 3.0.1-GA. They can certainly release trunk under the AL license and call it Kindred Http Server 3.0.1-GA, based on Apache HTTP Server. That is a statement of fact and not an abuse of the mark, IMHO. (If it was not actually based on Apache HTTP Server, then that would similarly be a Trademark infringement as it is a false use of the mark.) There are no less than two marks, one is the name of the foundation itself in conjunction with Open Source Software, and the other is the specific project name. -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Greg Chase Director of Big Data Communities http://www.pivotal.io/big-data Pivotal Software http://www.pivotal.io/ 650-215-0477 @GregChase Blog: http://geekmarketing.biz/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Please remove me from the PMC
With the graduation of NiFi I depart, at least for now. Thanks for all the fish. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling request: Gerrit
I've used crucible. It's horrible. And it comes from Atlassian, which means that infra@ is predisposed against it, as their general feeling is that the Atlassian products are very heavy. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Graduate NiFi from the Apache Incubator
Writing as a member and a mentor, I think that the NiFi podling will do fine without the 'usual' ASF member that Bertrand is asking about. However, because I think they'll do fine, I'll sign up if it makes people more comfy, secure in my belief that I will be a maytag repairman. On Fri, Jun 12, 2015 at 6:13 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, Jun 12, 2015 at 12:00 PM, jan i j...@apache.org wrote: ...one reason to be in incubator is to learn the apache way and that seems hard to learn without other apache people on the project... Not sure what you mean - the Nifi mentors have voted to graduate it, which indicates that they are confident that the project has learned how to operate as an Apache project. Still, in addition to acting as a liaison, having ASF members on the PMC is also a good way to have some form of post-graduation mentoring, when needed. Projects can always ask the board for advice, but when that advice is available in their PMC that's much better. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Graduate NiFi from the Apache Incubator
Sean sure makes more sense than me. On Fri, Jun 12, 2015 at 12:35 PM, Joe Witt joe.w...@gmail.com wrote: Sean is one of those folks i referred to. Id be an easy +1 On Jun 12, 2015 9:24 AM, Andrew Purtell apurt...@apache.org wrote: As Sean says he's been engaged with the project while acting as mentor, IMHO beyond mentor-ly duties. If the NiFi folks will have him on the initial PMC and he's willing to join it, this should resolve the stated concerns. On Friday, June 12, 2015, Sean Busbey bus...@cloudera.com wrote: On Fri, Jun 12, 2015 at 9:40 AM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: On Fri, Jun 12, 2015 at 3:53 PM, Sean Busbey bus...@cloudera.com javascript:; wrote: ...I have no reason to believe either my engagement or the PPMC's willingness to reach out to or listen to what I have to say will change upon graduation, so I don't think they need a checkbox ASF member on the initial PMC and I'd prefer they not add one... It's not about ticking a checkbox - it's about an ASF member agreeing to stay with the project to help here and there with things where members can help. Understood. I can't speak for any other ASF member, but I'm already there, engaged, and planning to stay. I don't need a binding PMC vote to do that. -- Sean -- 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: Request to create a new mailing list for apache nifi
I submitted the form, but I then need to replace myself with tkurc as a mod. Can I do that sans-jira? On Fri, Apr 17, 2015 at 11:10 AM, Joe Witt joe.w...@gmail.com wrote: Gavin, Appreciate your help. I am doing exactly what you asked and following the trail of guidance. Thanks Joe On Fri, Apr 17, 2015 at 11:06 AM, Gavin McDonald ga...@16degrees.com.au wrote: On 17 Apr 2015, at 3:42 pm, Joe Witt joe.w...@gmail.com wrote: Hello The apache nifi dev list has had a few requests and discussions about starting a user mailing list. I submitted the JIRA request for it today under here: https://issues.apache.org/jira/browse/INFRA-9462 But was advised to have the PMC chair submit the request and by doing so through this link: https://infra.apache.org/officers/mlreq Benson thought this appeared surprising but suggested i forward this to the IPMC. Can you help steer us in the proper direction so we can get u...@nifi.incubator.apache.org established? Please follow what I said and get someone to use the mailing list request form. It allows infra to use a script. No idea why Benson is surprised, its been this way for months. Gav… Thanks Joe - 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: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
If a single legal entity has the copyright, the entity makes a grant. If the code was built by a large community under the apache license, there's no one to make a grant. 'The community' expressing its desire to move to Apache is enough. This is an edge case of the principle that we only accept code when the copyright owner has a positive intent to contribute it; there's no way to test that for everyone who ever made a 2-line patch. Reference Subversion, I think. On Thu, Mar 26, 2015 at 8:40 AM, Cédric Champeau cedric.champ...@gmail.com wrote: In the case of groovy, does Pivotal own it or does someone else own it? Nobody owns it. If I look at https://github.com/groovy/groovy-core/blob/master/NOTICE it indicates that an entity known as The Groovy community owns it, in which case the SGA should probably come from them, no? Or is The Groovy community not a legal entity? The Groovy community is not a legal entity. A lot of people contributed to Groovy already, and in the Groovy ecosystem, the community is a notion larger than the language itself. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
On Thu, Mar 26, 2015 at 10:22 AM, James Carman ja...@carmanconsulting.com wrote: And that covers us from a legal standpoint? Is there anything special' about this situation that makes this appropriate? There is nothing legal to cover here. Since all the code is AL 2.0, legally, we are fine. The grant is (a) a bit of a belt atop the suspenders, and (b) a nod to our 'cultural' desire to see an intention for code to flow into the foundation in addition to the legal right. On Thu, Mar 26, 2015 at 10:19 AM, Jim Jagielski j...@jagunet.com wrote: There is no official, legal entity which can make the actual transfer. When we created the ASF, out of the Apache Group, all members of the Apache Group signed the xfer which amounted to the SGA at the time. For Groovy, it is sufficient for G to sign on behalf of the Groovy Core Team. If we could get the initial committers (who ARE the Core team) to also sign, that would be even better. - 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] Groovy Incubation proposal
You may think that the discussion has died down, but perhaps recall the lesson of NiFi. Or not, it might not strike you as applicable. On Tue, Mar 17, 2015 at 7:33 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, Mar 13, 2015 at 2:39 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ... Starting the vote on the proposal is Roman's job anyway, as the Groovy champion, so let's wait for him... Is there any reason to wait more? IMO the discussion on the proposal has died down so we can move forward. Roman, WDYT? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On Sat, Mar 14, 2015 at 10:12 AM, Steve Loughran ste...@hortonworks.com wrote: Perhaps you might consider asking Maven questions on a Maven list? If you peruse the Maven dev list, you'll find an ongoing conversation. On 14 Mar 2015, at 00:13, Jochen Theodorou blackd...@gmx.org wrote: Am 13.03.2015 22:38, schrieb Stephen Connolly: (Disclosure Ben works for my employers, so I have slightly more ability to bend his ear. As a result I got him to agree to do two full exports from JIRA, one to let us test the process and a second when we are ready to migrate) ah ok, that explains it. It does not look like we get the privilege so far somewhat related somewhat off-topic What's going to happen to those maven plugins that also live in codehaus? http://mojo.codehaus.org/ Certainly http://mojo.codehaus.org/versions-maven-plugin/ is kind of important? Is anyone trying to recruit them to the ASF project -and get their JIRA logs in there too? - 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] Groovy Incubation proposal
JimJag, for years, has written about the cultural implications of DVCS, and the email here supports what he's written. So I think we need to pay close attention. I think that we care about both PMC and committer inventory. I, for one, would not want to see an Apache project that restricted commit access to a small group of PMC gatekeepers. You might think of it as 'commit=PMC' gone bad. I think that an important piece of Apache culture is that a very wide group of people is trusted with access to add to the main line of development, trusting in the PMC to use the tools available to attend to the rare mishap. This has nothing to do with the start of incubation in my view. Groovy can start with 2 committers or 200. By the end of incubation, however, I would hope to see some cultural shift in the direction of broad commit access. Given the existing size and health of the community, I'd agree with others that the usual concern of worrying about the community reaching and maintain critical mass does not come up. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Soliciting feedback for a detailed pTLP policy document
On Wed, Mar 4, 2015 at 1:12 PM, Doug Cutting cutt...@apache.org wrote: On Mon, Mar 2, 2015 at 5:31 PM, Roman Shaposhnik r...@apache.org wrote: At this point, I would like to open this document for soliciting as wide a feedback as possible. I would like to especially request attention of the ASF board members who asked for this type of a document to be available. As a director, I still don't think the board needs to be involved in a pTLP's graduation. As far as I'm concerned, any provisional status is self-imposed by the PMC and can be removed at its pleasure. From the board's perspective it's either an ASF project or it's not, there's not a useful middle ground. As a project it needs to provide reports, release according to accepted standards, operate openly, etc. It may be a young project, with a PMC dominated by old-timers who aren't responsible for much of the contribution, but I don't see why that requires a new formal status any more than we need a formal status for old, slow-moving projects that rarely release. Put directly, what does a pTLP's graduation change from the board's perspective? How should it change the way we review the project's reports, etc.? In short, why should we care about this label? If a PMC wishes to call itself blue that's fine too, but we don't need a resolution when it decides to call itself purple. What's your view of 'incubation disclaimers'? The above paragraph makes most sense to me if there are none for pTLPs. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: GPL Code in GitHub
An Apache project may not manage a codebase outside of Apache. Some people who happen to be members of an Apache community can maintain code outside of Apache, if they are very clear in distinguishing; it must not be a product of the project. See 'Apache Extras'. On Wed, Mar 4, 2015 at 8:46 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Julian, the code is not included in the project (just a reference) ? Regards JB On 03/04/2015 02:44 PM, Julian Tenney wrote: Question: I know I've seen this discussed here before, and in any case, you guys are the best source for an answer: Can we have GPL code in a repository as long as that is not distributed with the product in a 'official' release? Thanks a lot, Julian This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -incubator in versions of podling maven artifacts
Since the only official release is the source release, perhaps that's the only place where we in fact need a policy? On Tue, Feb 10, 2015 at 9:39 PM, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Feb 11, 2015 at 7:49 AM, Stian Soiland-Reyes st...@apache.org wrote: I think formally the requirement is just that there is incubating somewhere in the released downloadables, it doesn't have to be part of the version number Originally it was a matter of the user can't avoid notice that the project is incubating. So anywhere, he/she can enter it as a dependency it needed to be present. Since many uses Maven, that meant it had to be part of group, artifact, version or classifier. If the project only releases a source tarball, then it needs to go onto that, and so on. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
On Mon, Feb 2, 2015 at 4:19 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: Matt, you're saying the same thing, except it's not one individual but two [1] (spmallette + okram) , who own the vast majority of the IP. They also claim to be in the possession of CLAs from the other contributors. The problem was not insufficient data to substantiate claims, but TMI. Secretary@ pushed back for that clear reason, the proposal for resubmission addressed that. If secretary@ will have additional concerns (including forwarding to legal@), we'll address them as they come. Well, the situation you describe here is about 180 degrees removed from the hypothetical that started this thread. So just about nothing written on this thread is relevant. If two people can make in conscience fill out an SGA, that's that. Hadrian [1] https://github.com/tinkerpop/tinkerpop3/graphs/contributors On 02/02/2015 09:53 AM, Matt Franklin wrote: On Mon Feb 02 2015 at 8:09:43 AM Hadrian Zbarcea hzbar...@gmail.com wrote: On 02/01/2015 03:19 PM, Benson Margulies wrote: On Sun, Feb 1, 2015 at 2:12 PM, John D. Ament johndam...@apache.org wrote: On Sun Feb 01 2015 at 1:05:10 AM Alex Harui aha...@adobe.com wrote: On 1/31/15, 9:09 AM, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Just curious, what if the code was under AL but not at Apache? The license is pretty clear about this: *5. Submission of Contributions*. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. So basically, anything you contribute back is assumed to be under the Apache license, unless you (the author) say otherwise or there's some other license in play (The apache license doesn't supersede other licenses). Of course you should consult with legal counsel before making any contributions though. I think to Benson's point, The ASF requires that any incoming code was put in under that license agreement or there's a SGA stating the prior license can be converted. Note the phrase, intentionally submitted for inclusion in the Work by You _to the Licensor_. Who is the licensor for a body of work not at Apache? The process has to start with a clear ownership of copyright -- the licensor. The purpose of the SGA, I think, is to get a clear answer to that question. You might be able to argue that a particular github repo is made up of an initial work with a single owner, and then contributions to it under the terms of the AL. In which case, you'd just need an SGA from that original single owner. IANAL. My understanding is that the Licensor is whomever claims to be 'it'. As long ans the claimant produces documentation to substantiate the claim that we can accept, we should be good. I don't see a need/requirement for the Licensor to necessarily be a legal organization. That is if it's not one single owner but a small group of contributors/owners, that should be ok too. My understanding is that the licensor must be able to own the copyright, thus a legal entity (company or individual). IMO, we should either take the acceptance of Tinkerpop as a Licensor to legal@ or we just ask anyone who has contributed signifiant IP to sign an ICLA with new copyright assignment. IANAL, $0.02, Hadrian
Re: Practical next steps for pTLP experiment
On Mon, Feb 2, 2015 at 5:38 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I missed a few important points in this thread last week, with which I disagree: On Tue, Jan 27, 2015 at 7:28 PM, Greg Stein gst...@gmail.com wrote: ...1) Draft a template resolution. Starting in the wiki is fine, but you'll want to involve board@ when you have your first draft done IMO board members have more important things to do than work on draft resolutions for new projects, and it's also important for drafts of new projects to be discussed in public. If only to allow new people and mentors to jump in. I strongly suggest discussing such draft resolutions on this list. Even if the Incubator PMC is not formally involved in managing those pTLPs, this list is where the know-how about creating new projects resides, I see no reason to move that work elsewhere. ...2) Create a ComDev page discussing what it means to be a provisional TLP I don't understand why people want these things to move to comdev - did you even ask the comdev PMC about this? It sounds like people want to send a bunch of tasks their way, without even asking. Three possible models: 1: 'comdev will do it'. I agree with you that this is wrong. 2: 'let's go over to comdev and volunteer to build some documentation for an alternative launch mechanism'. This experiments with expanding comdev in the direction. 3: 'build the doc at the existing incubator.' The momentary impulse is (2). You might find it tolerable. I see no reason for the pTLP process definition to happen outside of the Incubator, which is the PMC tasked with bringing new projects to the ASF. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
On Sun, Feb 1, 2015 at 2:12 PM, John D. Ament johndam...@apache.org wrote: On Sun Feb 01 2015 at 1:05:10 AM Alex Harui aha...@adobe.com wrote: On 1/31/15, 9:09 AM, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Just curious, what if the code was under AL but not at Apache? The license is pretty clear about this: *5. Submission of Contributions*. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. So basically, anything you contribute back is assumed to be under the Apache license, unless you (the author) say otherwise or there's some other license in play (The apache license doesn't supersede other licenses). Of course you should consult with legal counsel before making any contributions though. I think to Benson's point, The ASF requires that any incoming code was put in under that license agreement or there's a SGA stating the prior license can be converted. Note the phrase, intentionally submitted for inclusion in the Work by You _to the Licensor_. Who is the licensor for a body of work not at Apache? The process has to start with a clear ownership of copyright -- the licensor. The purpose of the SGA, I think, is to get a clear answer to that question. You might be able to argue that a particular github repo is made up of an initial work with a single owner, and then contributions to it under the terms of the AL. In which case, you'd just need an SGA from that original single owner. IANAL. John -Alex - 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: Software Grants for GitHub Projects...
On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? (Queue Marvin on the subject of documentation.) http://www.apache.org/licenses/ My understanding: when a significant body of code arrives all at once, the Foundation desires an SGA. That, however, assumes that one legal entity is granting the license to the whole thing. So, if you have a github repo whose contents are assembled of a uniform distribution of small contributions, there would be no point to an SGA. If, on the other hand, the histogram of contribution size versus copyright holder indicated that some copyright owners contributed 'significant' bodies of code, then SGAs from those entities might be called for. There is no established law that allows the Foundation to set hard criteria in terms of lines of code, so this has to be a judgement call, and people sometimes call upon the VP, Legal for assistance in making those judgement calls. For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Note that copyright still stays with them; they are granting a license, but we also require that code that 'moves into' Apache some with some expression of positive intent on the part of the author/copyright owner. On Saturday, January 31, 2015, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 8:44 AM, James Carman ja...@carmanconsulting.com javascript:; wrote: Is there a standard within the incubator about how we go about getting the appropriate forms filled out when we want to incubate a project from GitHub? GitHub fosters a sort of fly-by contribution model (and that's a good thing), but it makes donating the code a bit troublesome, because we need to make sure that all (to a certain degree?) of the contributors do, in fact want to donate the code they contributed to the foundation. Simple answer: no. It is up to you to get ICLA/CCLA/SGA as appropriate for all contributors based on the usual considerations of contribution size, copyright ownership, and provenance clarity. if you have some stray commits that you can't cover, you can either reimplement, or make an argument that are below the threshold of concern. The github metadata helps a bit, but since you have no guarantee that the committer is the author, there's no possible way to see this as automated. The fact that code is published under the AL does _not_ make it automatically code that you can pull in no matter what else. We require a positive intent to contribute the code to the foundation. Note that this problem isn't necessarily unique to GitHub, but Git itself somewhat highlights the issue because contributions from outside parties (pull requests) do maintain metadata about their original authors. With SVN, typically someone with karma has to do the commit and it gets tagged with their identity, so the audit trail goes cold (comments can contain attributions, but that's hard to report on). Anyway, just looking for some guidance here. We are trying to move TinkerPop forward and how exactly we go about getting the forms filled out properly is somewhat of a blocker. Thanks, James Carman, Assistant Secretary Apache Software Foundation - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
On Sat, Jan 31, 2015 at 8:44 AM, James Carman ja...@carmanconsulting.com wrote: Is there a standard within the incubator about how we go about getting the appropriate forms filled out when we want to incubate a project from GitHub? GitHub fosters a sort of fly-by contribution model (and that's a good thing), but it makes donating the code a bit troublesome, because we need to make sure that all (to a certain degree?) of the contributors do, in fact want to donate the code they contributed to the foundation. Simple answer: no. It is up to you to get ICLA/CCLA/SGA as appropriate for all contributors based on the usual considerations of contribution size, copyright ownership, and provenance clarity. if you have some stray commits that you can't cover, you can either reimplement, or make an argument that are below the threshold of concern. The github metadata helps a bit, but since you have no guarantee that the committer is the author, there's no possible way to see this as automated. The fact that code is published under the AL does _not_ make it automatically code that you can pull in no matter what else. We require a positive intent to contribute the code to the foundation. Note that this problem isn't necessarily unique to GitHub, but Git itself somewhat highlights the issue because contributions from outside parties (pull requests) do maintain metadata about their original authors. With SVN, typically someone with karma has to do the commit and it gets tagged with their identity, so the audit trail goes cold (comments can contain attributions, but that's hard to report on). Anyway, just looking for some guidance here. We are trying to move TinkerPop forward and how exactly we go about getting the forms filled out properly is somewhat of a blocker. Thanks, James Carman, Assistant Secretary Apache Software Foundation - 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: Software Grants for GitHub Projects...
On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? (Queue Marvin on the subject of documentation.) http://www.apache.org/licenses/ My understanding: when a significant body of code arrives all at once, the Foundation desires an SGA. That, however, assumes that one legal entity is granting the license to the whole thing. So, if you have a github repo whose contents are assembled of a uniform distribution of small contributions, there would be no point to an SGA. If, on the other hand, the histogram of contribution size versus copyright holder indicated that some copyright owners contributed 'significant' bodies of code, then SGAs from those entities might be called for. There is no established law that allows the Foundation to set hard criteria in terms of lines of code, so this has to be a judgement call, and people sometimes call upon the VP, Legal for assistance in making those judgement calls. For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Note that copyright still stays with them; they are granting a license, but we also require that code that 'moves into' Apache some with some expression of positive intent on the part of the author/copyright owner. On Saturday, January 31, 2015, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 8:44 AM, James Carman ja...@carmanconsulting.com javascript:; wrote: Is there a standard within the incubator about how we go about getting the appropriate forms filled out when we want to incubate a project from GitHub? GitHub fosters a sort of fly-by contribution model (and that's a good thing), but it makes donating the code a bit troublesome, because we need to make sure that all (to a certain degree?) of the contributors do, in fact want to donate the code they contributed to the foundation. Simple answer: no. It is up to you to get ICLA/CCLA/SGA as appropriate for all contributors based on the usual considerations of contribution size, copyright ownership, and provenance clarity. if you have some stray commits that you can't cover, you can either reimplement, or make an argument that are below the threshold of concern. The github metadata helps a bit, but since you have no guarantee that the committer is the author, there's no possible way to see this as automated. The fact that code is published under the AL does _not_ make it automatically code that you can pull in no matter what else. We require a positive intent to contribute the code to the foundation. Note that this problem isn't necessarily unique to GitHub, but Git itself somewhat highlights the issue because contributions from outside parties (pull requests) do maintain metadata about their original authors. With SVN, typically someone with karma has to do the commit and it gets tagged with their identity, so the audit trail goes cold (comments can contain attributions, but that's hard to report on). Anyway, just looking for some guidance here. We are trying to move TinkerPop forward and how exactly we go about getting the forms filled out properly is somewhat of a blocker. Thanks, James Carman, Assistant Secretary Apache Software Foundation - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript
Re: [VOTE] Release Apache NiFI 0.0.1-incubating
On Wed, Jan 28, 2015 at 6:05 PM, jan i j...@apache.org wrote: +1 (binding) I am a bit confused about the mangling of license/notice files in respect of the source/binary releases. Can I please ask you to make a clear distinction between source and binary (which is not official ASF release) in the next release. On side note, I am still not quite comfortable having binary releases, we (the incubator in general) need a discussion on how we look at jar files, they are not really object files (as from C/C++) but they are still binary. I acknowledge and DO NOT dispute the fact that java projects needs this. Jan, I'm not sure precisely what you are uncomfortable about, but I note that http://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven is official. The Apache Maven Project, just to cite an example, puts up several releases a month like this. We run the release plugin, it produces the 'official source release' bundle which is cited in the vote, and it also stages the binaries. All of this is staged in repository.apache.org. Maybe the correct response is, 'You don't look at binary files. The only thing up for a vote is the official source release bundle referenced specifically in the vote email. Pay No Attention To The Convenience Items Behind the Curtain.' If you are discomfortable with this, I think it would be helpful if you would raise this on comdev or some other venue that applies to the Foundation as a whole, so as not to end up accidently seeming to hold podlings to standards different than the project communities. regards, benson rgds jan I. On 28 January 2015 at 23:42, Billie Rinaldi bil...@apache.org wrote: The source artifacts look good. The nar and war files deployed in the orgapachenifi-1022 repository seem to have default LICENSE files that don't have license info for their bundled dependencies, but they do all have DEPENDENCIES files listing this information. I haven't worked with these dependencies files before. Are they sufficient for communicating license information? On Mon, Jan 26, 2015 at 7:33 PM, Joe Witt joe.w...@gmail.com wrote: Hello The Apache NiFi (incubating) team is pleased to be calling this vote for the source release of Apache NiFi 0.0.1-incubating. With six binding (in the ppmc sense) +1 votes and no dissenting votes the PPMC has approved the vote for the release in this thread: http://s.apache.org/nifi-rc3 We now ask the IPMC to vote for this release. Since this is our first release as part of the Apache Incubator it will be slightly unique because we need to release two components. The first component is the 'nifi-nar-maven-plugin' which allows us to build 'NiFi Archives' which is part of our classloader isolation model. The second is simply 'nifi' which is the full build and application that is 'Apache NiFi (incubating)'. After this first release we expect to be releasing the 'nifi-nar-maven-plugin' very rarely. So we'll break the information sections of this vote into two parts where one is for 'nifi-nar-maven-plugin' and the other 'nifi'. For the 'nifi-nar-maven-plugin' -- The source zip, including signatures, digests, etc. can be found at: https://repository.apache.org/content/repositories/orgapachenifi-1021 The specific repository path in that staging repo is: orgapachenifi-1021/content/org/apache/nifi/nifi-nar-maven-plugin/1.0.0-incubating/ The sources.zip is called 'nifi-nar-maven-plugin-1.0.0-incubating-source-release.zip' The Git tag is nifi-nar-maven-plugin-1.0.0-incubating-RC3 The Git commit ID is 6e69d99444e22772df300cd777096dc21a7c8e35 https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=6e69d99444e22772df300cd777096dc21a7c8e35 Checksums of nar-maven-plugin-1.0.0-incubating-source-release.zip: MD5: 2681be25c32a45df07fbac59f768c5d2 SHA1: 1e6057e07c32a7a0208afdc36e7ce725bd9935e4 7 issues were closed/resolved for this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020version=12329307 Note once you have completed the verification of the 'nifi-nar-maven-plugin' you will have 'nifi-nar-maven-plugin:1.0.0-incubating' in your local repo and thus you can move on to the 'nifi' build below which depends on it. For 'nifi' - The source zip, including signatures, digests, etc. can be found at: https://repository.apache.org/content/repositories/orgapachenifi-1022 The specific repository path in that staging repo is: orgapachenifi-1022/org/apache/nifi/nifi/0.0.1-incubating/ The sources.zip is called 'nifi-0.0.1-incubating-source-release.zip' The Git tag is 'nifi-0.0.1-incubating-RC3' The Git commit ID is 3a7625920866deaab1f3973fc4db0847d054a9b5 https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=3a7625920866deaab1f3973fc4db0847d054a9b5
Re: [VOTE] Release Apache NiFI 0.0.1-incubating
+1 (binding) On Wed, Jan 28, 2015 at 4:44 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, +1 (binding) I checked (for both release artefacts): - signatures and hashes all good - incubating in source package name - LICENSE and NOTICE good (but complex!) - NOTICE has correct year - no unexpected binary files (except in some test directories but that's probably OK) - all source files have correct headers - can compile from source - tests pass Some suggestions: - Consider having separate licence and notice file for the binary release - The NOTICE file is a little odd in that while it mentions what licenses effect notice it doesn't list the software, but they are listed in the license file. Perhaps take a look at what other projects have done. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Practical next steps for pTLP experiment
On Tue, Jan 27, 2015 at 1:28 PM, Greg Stein gst...@gmail.com wrote: There are a few things that I would suggest for next steps: 1) Draft a template resolution. Starting in the wiki is fine, but you'll want to involve board@ when you have your first draft done. This will also start the discussion among the Directors (recall: the Board hasn't even agreed to try this!), and may produce some refinements. 2) Create a ComDev page discussing what it means to be a provisional TLP. The disclaimers/warnings/release-naming should likely mirror what we do for incubating podlings. +1000. This translates the idea of using ComDev as a venue for managing documentation into reality. Writers here want to pave a path for new projects outside the IPMC that depends on ComDev to take up some tasks. The sooner the action moves from 'here' to 'there', bringing actual volunteer effort, the better. 3) Note that I use provisional, since probationary implies you got in trouble. I wouldn't really worry about time frames. This will be a very subjective process, and every project is different. It will be hard to make a solid determination on day X in the future. If I were to put my thumb in the air, I'd say 6 and 12 months, rather than your 3/6. Cheers, -g On Tue, Jan 27, 2015 at 11:28 AM, Roman Shaposhnik r...@apache.org wrote: Hi! as I mentioned in a different thread, I feel really passionate about championing the pTLP experiment. To that end, here's what's going to happen shortly: #1 a couple of new projects that feel equally enthusiastic about trying a pTLP route (and have a level of support from a few board members) will submit a pTLP proposal to the board. #2 based on how #1 goes we will try to establish a path for existing (willing!) podlings to be converted to pTLP. A solicitation and details of what to expect will be posted on general@ with the expectations of having a couple existing podlings as part of the experiment In about 3 months time frame, if #1 and #2 are moving in the right direction, I'd like to start offering pTLP *option* for new communities seeking to join ASF. By that time I hope to have some amount of documentation detailing the process and pros/cons compared to the existing IPMC led model. In about 6 months time frame I would like to have enough details in place to submit to IPMC and start a discussion on whether pTLP is a viable model that needs to be encouraged and what does it mean for IPMC and ASF Incubation process. For all practical purposes, consider me a self-appointed pTLP champion and please, please help along as much as you can! 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: my pTLP view
On Tue, Jan 27, 2015 at 12:14 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Tue, Jan 27, 2015 at 6:58 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 27, 2015 at 3:38 PM, Alan D. Cabrera l...@toolazydogs.com wrote: In short, the pTLP designation is a bit too opaque So you mean all TLPs should have status labels? Might be useful...probatory, active, low activity, attic candidate...why not. Absolutely. And it belongs to a different effort (just trying as hard as I can not to boil the ocean with pTLP for now). I support Greg's idea that, in the initial experiment, they are flagged (and presumably required to DISCLAIM and respect PR restrictions), because that's the incremental path of not changing everything all at the same time. I support Bertrand's suggestion that, if this idea really turns out to work, the flag may go into the attic over time. 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Wed, Jan 21, 2015 at 11:53 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 21, 2015, at 3:39 AM, Benson Margulies bimargul...@gmail.com wrote: On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote: On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done Agreed - but I don't see how that improves things anyway, I don't see any problem caused by those inactive members. The near-ad-hominem tone of this thread has extracted a reply in my own defense. It is a misunderstanding, verging on willful, to claim that the V2 proposal is primarily intended to remove either inactive or noisy persons from the group. it is a fabrication that there is any idea that some person other than the board might select an initial set of people to further some particular agenda. The idea here of the small group, extracted from something Ross wrote on the Wiki in 2013, is that an incubator committee doesn't need to be big and it doesn't need to grow via merit, if its only job is to accept the board's delegation of a limited set of supervisory tasks. If you make a smaller group, it might still contain vigorous disagreement, but on a scale where they can manageably reach consensus. It would think less of the board if they failed to select people likely to have some significant disagreements. I resent your and Chris’ characterization of this thread. All that’s been taking place is a frank and civil discussion of opinions as to what the implication of some proposals mean. Your, and Chris’, attempt to characterize them as taking on an ad-hominem tone suggest to me that we are poking at the Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the Incubator. Since it is the tone of Chris' messages that I am predominantly objecting to, I am nonplussed. Since the purpose of V2 was to highlight my perception of the Achilles heel of pTLP, or alternatively to try to build the rest of the structure it required, I am bemused to see you looking for a heel of a heel. Would it help if I deleted the silly thing? No one seems to like it, and it is failing as a tool to focus discussion on my perceptions of the missing parts of the pTLP idea. No one seems to express any affirmative interest. All it seems to do is provoke ventilation. It is certainly true that you and I have very different views of the essential character of the some of the issues, but I see no value to this discussion, the incubator, or the asf in trying any further to bridge the gap. I, personally, would be happy to see effort put into Marvin's documentation project first and foremost, and any discussion about radical or structural changes to incubation deferred until we see the impact of that project. I, personally, would be happy to see the Board establish an 'unincubated' project now and again when there is a nuclear group of people qualified to run it without IPMC supervision. I, personally, prefer that the legal structure of a thing like an incubator match the function, but I accept that I'm apparently unique. But I have a very hard time typing nothing when there are people repeatedly accusing me, personally, of conspiratorial intentions. You and other, feel that the effect of V2 would be to exclude. Fine. That's a great reason to oppose it. (And also the change to ApacheCon.) But I perceive trolling, or worse, when people choose to oppose it by claiming that I drafted it with the intention of taking control by stuffing a committee with my co-thinkers. That's the plain sense of what Chris wrote, and I don't like it. At the heart of both there is a culling of IPMC members. Sure, the new IPMC may have Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s a distraction from the real problem that I, and maybe Bertrand, are trying to point out. At the proposals' core is that there are IPMC members who want to participate but would be left out and in the end the “problems” with the Incubator would not be resolved since, as Chris accurately puts it, we will have distilled dysfunction. But is it dysfunctional? Only when it tries to be like a school of business and come up with new and improved processes for bringing in new projects instead of focusing on the core problems which don’t go away, tooling and mentor accountability. Otherwise, I think we do a pretty good job. We make mistakes, sure, but mistakes will always be made and I think we’ve made good, focused, incremental pivots to address their causes. Regards, Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas cdoug...@apache.org wrote: On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done Agreed - but I don't see how that improves things anyway, I don't see any problem caused by those inactive members. The near-ad-hominem tone of this thread has extracted a reply in my own defense. It is a misunderstanding, verging on willful, to claim that the V2 proposal is primarily intended to remove either inactive or noisy persons from the group. it is a fabrication that there is any idea that some person other than the board might select an initial set of people to further some particular agenda. The idea here of the small group, extracted from something Ross wrote on the Wiki in 2013, is that an incubator committee doesn't need to be big and it doesn't need to grow via merit, if its only job is to accept the board's delegation of a limited set of supervisory tasks. If you make a smaller group, it might still contain vigorous disagreement, but on a scale where they can manageably reach consensus. It would think less of the board if they failed to select people likely to have some significant disagreements. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: When is an ICLA needed?
On Tue, Jan 20, 2015 at 1:40 PM, Branko Čibej br...@apache.org wrote: On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote: I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. Really? That can't be right: one can't become the author of a change (and therefore can't license it to the ASF) merely by having committed it. That's why we require an audit trail to the original author, right? It has to be 'right', but you're reading too much into Ross' remark. When you signed the ICLA, you agreed to abide by its terms. That doesn't make you the author of everything you commit. In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. That's a different matter, and I agree. -- Brane - 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
I'm in the odd situation of not particularly wanting to argue in favor of the proposal I wrote, yet finding it hard to resist the provocation of messages that appear, to me, to misunderstand it. So I'll restrict myself to the following, and I won't reply to any further dispute. Anyone else is welcome to have a last-er word than me. The incubator is like no other Apache project. It is not a meritocratic, volunteer, community, producing a software product for the public good. It is a volunteer, meritocratic, group of people solving a problem for the board. The problem that the incubator sets out to solve is this: How do you bootstrap a community from scratch? Because it is a group of people solving a problem for the board, there's no special 'merit' in shaping it in the usual ASF PMC growing community mold. There may by some problems with that shape related to scale, noise, and responsibility. Some people who find those problems to be severe want to make changes. Others, not so much. The board is always free to solve any problem with any structure that it finds effective; there's no 'constitutional' requirement that everything is a meritocratic PMC. Witness what happened to ApacheCon. We have here two competing visions. The current vision says: Let people who have never run an Apache community it start doing it with coaching and supervision from 'mentors'. The alternative vision says, Start with a kernel of people who have done it before. Those of you who are happy with the current vision? Great! I wrote up the alternative vision to try to put some clarity onto a lot of prior writing that found fault with the current model and looked for an alternative. In neither model are people powerless in any meaningful sense. In the current model, people have an interaction with the full IPMC. They can get pretty frustrated, but, as Mavin has documented, the frustration is more the fault of the lack of documentation than of the behavior of the IPMC. In the alternative model, they _start out_ with a group of 'strangers' at the center of their community, but those strangers are chosen specifically for their ability and experience in building a consensus community. And, in any case, they they will rapidly become an ever-smaller fraction of the group. Badly-behaved mentors (and other IPMC members) can overbear in the current model, and badly-behaved seed-PMC members could overbear in the alternative. I very much doubt that email discussion will yield any consensus to do anything radical. Which might be fine. When the time comes to find Roman's successor, an interesting situation may arise in which candidates might declare their intention to implement changes. And just to be clear, _I_ am not running on the platform of implementing what I wrote -- or any other way. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [pTLP] Apache Commons sub-mailing lists discussion
On Fri, Jan 16, 2015 at 10:39 AM, Stian Soiland-Reyes st...@apache.org wrote: Relating to IncubatorV2 and pTLP proposals - on Apache Commons I seem to have spurred a discussion about making sub-mailing lists (And thus forming sub-communities) - but keep the formalities on the general list. (email below) http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3C23d5b03fc1cdb4079ceb52c55458f0e3%40scarlet.be%3E My slight concern (even though I would benefit from the proposal :)) is that this is in danger of forming a mini incubator with less clear guidance and follow-up: http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAPRnXt%3DDwqk9p-b-yYBYRnrp%3DanvLgdTanMkenLfm6fGQgcHfw%40mail.gmail.com%3E The pTLP proposal has not mentioned what would be the process for projects with a sponsor different from Incubator (e.g. which don't aspire to become TLPs) - presumably they would usually have mentors from and report to the parent project? Well, the idea of non-incubator sponsors seems to me to have been a dead letter for years. As of now, the board's expectation is that all incubating projects are supervised by the IPMC. While the proposal template still has a slot for sponsor, it does not mean anything in practice. It's the IPMC and only the IPMC that accepts new projects, and then supervises them. In the very remote case that my version of the pTLP proposal goes anywhere, the board would, of course, have the option of passing a resolution to establish a pTLP without prior vetting by the Incubator Committee. As for subcommunities, I reference the very complex process of a few years back of _getting rid of_ 'umbrella projects.' I don't see any proposals with Apache Commons as the sponsor at http://incubator.apache.org/projects/index.html .. is that because Commons already have a lightweight entry path with its sandbox? https://commons.apache.org/sandbox.html -- Forwarded message -- From: Gilles gil...@harfang.homelinux.org Date: 16 January 2015 at 00:47 Subject: [ALL] Too much traffic on the dev ML To: Commons Developers List d...@commons.apache.org Hi. In the discussion that started about RDF, it seems that the traffic volume is a stumbling block. [For some time now, it has been a growing nuisance, and the usual dismissal about filters won't change the fact: Setting up a filter that will redirect stuff to /dev/null is a waste of bandwidth.] If different ML are created, people interested in everything can subscribe _once_, and nothing will change for them. For people who spend a lot of time just deleting dozens messages and notifications a day, it will be a relief. Maintaining community conversation is not a problem: just create an all-...@commons.apache.org ML for things that need input form a larger audience (like votes). Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 - 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: What is The Apache Way?
On Tue, Jan 13, 2015 at 10:43 AM, David Nalley da...@gnsa.us wrote: On Mon, Jan 12, 2015 at 12:55 PM, Doug Cutting cutt...@apache.org wrote: On Sun, Jan 11, 2015 at 9:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I think a better analogy would be US Culture. Yes it is as nebulous as it gets, but the fact that US Constitution exists as a written document makes a LOT of things WAY easier. Apache's constitution is the corporate bylaws: http://www.apache.org/foundation/bylaws.html US Culture is stuff like Starbucks, Elvis, Manifest Destiny, etc. Most of that is not coded as law, thankfully. Except that there generally aren't authority figures to whom I am answerable to telling me I am doing it wrong if I don't drink Pumpkin Spice Latte's while listening to Blue Suede Shoes. Going back to a conversation from the middle of last year as an example, there is no documented expectation (unless you consider Shane's recently created page authoritative) that the canonical source code repository must live on ASF hardware. Which is fine, we all know the reason why, but when newcomers show up, they don't, and it seems like we are a mass of unwritten rules that MUST be followed. And the fact that it seems a blindly obvious implication of the general principles to the 'old original' people around here does not help. At the Incubator, we're trying to teach people these principles via practice. Expecting them to draw the implications naturally from the principles at the outset of this process is asking too much of them and of us. A concrete idea that I doubt I have the time to volunteer for: Write a description of a prototypical, middle-of-the-road, Apache project. For as many salient characteristics as possible, write up the explanation of why the particular thing is the way it is. Use a practical example of the 'way' in operation to teach principles, instead of expecting it to work the other way around. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clear expectations
Does it help anything to look at this, again, as failure modes? One failure mode is a project that emerges from the incubator showing, well, gross signs that it 'doesn't get it.' Another failure mode is that a group of people who really do get it, at the level of the broad principles, get into trouble trying to translate those principles into very practical matters, due to conflicting sources of authority and documentation. Talking about one of these does not invalidate the other as a concern. I have an complementary suggestion to Marvin's push for documentation. My request is for a much clearer channel of communication to the board. All too often, projects wind up communicating with individuals; some board members, some not. Those individuals are in an unclear state of headware. Board members are always free to express their personal gut reaction, but I find that much confusion results from mistaking a gut reaction for an _ex cathedra_ statement -- and, in the end, board members don't even own such seats. Only the board together can issue a binding ruling. Since we're talking IPMC here, perhaps the solution is for the VP to even more actively take the role of 'bring your troubles to me, and I'll take them up with the board if I can't settle it.'
Re: What is The Apache Way?
The temperature of this might be reduced by replacing, 'no one knows what the Apache Way is' with 'a lot of us have trouble translate it into practical decisions in a repeatable fashion.' Or not. As reported here, we have performed multiple experiments in which multiple members, directors, and others have derived conflicting _practical_ interpretations from 'the way.' People need to make practical decisions about releases, web sites, brands, and the like. People don't enjoy being told that they have 'trangresssed'. People particularly don't like this when their trangression was an action recommended by someone who is 'supposed to know,' and, in fact, thinks that she or he does know. So, either a lot of us are really stupid, or the Foundation as a whole has a gap between the general principles and their application. No, we can't have a rule book that details every particle of how to run an Apache project, but apparently we could have more concrete guidance. On Fri, Jan 9, 2015 at 10:30 AM, Jim Jagielski j...@jagunet.com wrote: Please tell me where the examples you give diverge or conflict? On Jan 9, 2015, at 10:20 AM, Marvin Humphrey mar...@rectangular.com wrote: On Fri, Jan 9, 2015 at 6:58 AM, Jim Jagielski j...@jagunet.com wrote: And I think that someone who is an ASF member who claims that the Apache Way is completely unknown and nebulous and that there is no clear understanding of what the Apache Way is, well I think that's a big problem as well. We've seen Brane's version of The Apache Way. Here are some others: https://www.apache.org/foundation/how-it-works.html#philosophy While there is not an official list, these six principles have been cited as the core beliefs of philosophy behind the foundation, which is normally referred to as The Apache Way: * collaborative software development * commercial-friendly standard license * consistently high quality software * respectful, honest, technical-based interaction * faithful implementation of standards * security as a mandatory feature http://communityovercode.com/2013/11/apache-governance-projects-first/ These include things like The Apache Way of: volunteer and collaborative led community built software projects; using the permissive Apache license; and having a consistent and stable brand, infrastructure services, and home for all Apache projects. http://www.slideshare.net/rgardler/the-apache-way-and-openofficeorg * Open Development vs. Open Source * Everyone is equal, everyone is a volunteer * All technical decisions about a project are public * She who has the best ideas leads * Until a better idea emerges http://theapacheway.com/ The Apache Way is sort of like Zen. It's something that's difficult to explain, has many interpretations, and the best way to learn it is to do it. The Incubator stands accused, on this list and others, of graduating pudlings who fail to understand the Apache Way. Like me, these podlings have an their own interpretation of the Apache Way. But we don't know, and can't know, every possible interpretation of The Apache Way. If the Board thinks that not knowing The Apache Way is a problem, give us a specific definition -- and then don't hold us accountable for knowledge of any other version. 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: What is The Apache Way?
On Thu, Jan 8, 2015 at 11:01 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: WTF? There have been presentations about the apache way at every ApacheCon for about 15 years (twice in most years). I personally give 5-10 such presentations a year (sometimes public sometimes not). I'm sure many others here do the same. The Apache Way is really simple. There are very few immutable rules but anything that undermines those rules is not part of the Apache Way. The problem is not a lack of clarity its a lack of agreeing what does/does not undermine those few immutable. The way we get around that is to have a group of members who define it and take any action necessary to ensure the Apache Way is protected. Those members can become IPMC members and help incoming projects learn the immutable rules and how to evaluate whether an action will undermine those rules. There is a process for building consensus around what is and is not acceptable. There is an escalation process if consensus cannot be reached. In the IPMC it goes... PPMC - Mentors - IPMC - Board - Members In TLPs it is similar: Community - Committers - PMC - Board - Members Nobody expects the PPMC to understand. Everyone expects Members to understand, which means everyone expects Mentors to understand (see how it is designed to be flat?) You can become a member without ever living through a commit veto, or a nasty argument about corporate (over)involvement, or any number of other critical test cases of whether a community is, in fact, successfully putting the principles into practice. This wouldn't worry me so much except that I fear that (rarely) some members who have become mentors don't even recognize when something is happening which calls for them to call for backup. This is not a top down organization where rules govern what we can do. It is not the boards job to define policy, that's the members job (and the IPMC is mostly members). The board are the end of the escalation chain, they break deadlocks only (and approve policies defined by the membership). In my experience, there are some people who consistently act as if there is some sort of top-down flow of rules. (In fact, in some cases, I would even count myself as one of them.) The usual source of floods of email on this subject is not the community principles of governance, but rather the legal details of releases. Some people 'round here think that's it is very important that the contents of NOTICE files are completely correct. Some podlings have achieved extreme frustration in this area, especially when some of those people disagree about what constitutes 'correct'. So, when Martin writes what he writes, I'm reasonably sure that what he's looking for is not a rule book of how to run a consensus community, but rather clear, complete, and non-contradictory documentation of how to produce a proper release. I have always had a sense that, at the VP Legal level, there is a sensible application of the legal principle of _de minimus_ -- that, in fact, little problems with this stuff are just not material. But, if I am right about that, I feel pretty clear that this does not get communicated downwards. Here's where I come in as a legalist: at the end of the day, a PMC is a legal formalism. The board delegates certain legal authority (notable, to make releases) to the PMC, and appoints the chair. The IPMC thus is a complex device: on the one hand, it is the legally constituted PMC with responsibility for the releases of podlings. On the other hand, it has spent the last few years trying to find ways to push authority downwards into the podlings. The pTLP business asks, 'well, is there a way to just simplify this by letting each new project just be a PMC?' My writeup asks, 'OK, if you want that, what _might_ it look like?'
Re: proposal: mentor re-boot
On Thu, Jan 8, 2015 at 1:16 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Chip is correct. The tools we use in board meetings make it easy for us to see how many PMC members in a TLP resolution are members. If there are not enough we will sometimes put the project on an informal watch list (as well as ensuring appropriate people from the PMC go on the members watch list), occasionally we bounce the proposal back (this is pretty rare). With my Directors hat on I don't want a member being there just for mentoring, it confuses the evaluation since that person will appear as a committed PMC member but will in fact be nothing more than a mentor. What is important is that the PMC knows where to go for help when they are unsure of something. That expertise can (and should be) be present without a mentor or a Member on the PMC. Maybe there's a hair to be split here. On a few occasions, I was asked by board members if I would join a graduating PMC that I had mentored. I have never felt that my role on these PMCs was to be a continuing mentor, it was to be a PMC member who had some extra experience, and I have been gradually leaving them over time.
Re: What is The Apache Way?
On Thu, Jan 8, 2015 at 1:49 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: To be clear my email was not targeted at Marvin. We all know how hard Marvin has worked to create the clear policy documents I talk about here. I hope Marvin knows me well enough to recognize my debating style. This is not about *him* it's about the impression of the top down rules you describe below - as you seem to be implying that should not exist in the Apache Way apart from a few immutable areas and I agree. Last for me for today: I recognize both of your debating styles, and my reference to Marvin was a combination of my personal tendency to conflict-aversion and an attempt, indeed, to distinguish between the narrow area where there can or should be rules, and the broader area where we are all discussing cultural diffusion without the use of initiation ceremonies. I particularly want to highlight my view that the most important thing is to know when you need help, and the other most important thing is for there to be help available.
pTLP, concretely
For your reading and wrangling pleasure, I offer: https://wiki.apache.org/incubator/IncubatorV2. The goal of this exercise is to turn the idea of the pTLP into a practical alternative. By 'practical', I mean: 'based on the constraints as I see them'; the board and comdev are not going to find a little bottle labelled 'drink this' and swig away at new responsibilities. I'm not offering this to advocate for it, or against it. My purpose is more to argue that it would be a ton of work. 'Mentors in the Project' in the existing, messy, noisy, IPMC would be a lot less work and has the potential to deliver comparable results on the important issues. But if people want to take this up, or if someone wants to campaign for chair using this as a platform, that would be more productive that discussing the pTLP alternative in the abstract. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: pTLP, concretely
On Mon, Jan 5, 2015 at 8:41 AM, Alan Cabrera l...@toolazydogs.com wrote: On Jan 5, 2015, at 5:38 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com wrote: For your reading and wrangling pleasure, I offer: https://wiki.apache.org/incubator/IncubatorV2. ... IIUC the main difference (besides subtle naming changes) is that pTLPs vote on their own releases, based on pTLP PMC members who have been accepted by the board? So more work for the board, and each pTLP needs to form an acceptable PMC roster with at least 4-5 members? My thoughts exactly. What this proposal effectively does is pawn off the responsibility of holding mentors accountable to the board. No. The original uncooked pTLP scheme did that. This scheme locates that responsibility in the renamed committee, which serves the board by supervising the pTLPs. They aren't mentors, they are PMC members. - 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: pTLP, concretely
On Mon, Jan 5, 2015 at 9:25 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Jan 5, 2015 at 3:15 PM, Benson Margulies bimargul...@gmail.com wrote: ...This scheme locates that responsibility in the renamed committee, which serves the board by supervising the pTLPs. They aren't mentors, they are PMC members... Ok, but the board needs to accept those folks, and the incoming pTLP needs to locate 4-5 such folks that the board will accept. I bet that would result in smaller potential projects just fading away, which goes against our inclusive principles. I agree. It painfully obvious (to me) that we don't have enough qualified mentors to handle all the small projects that want to show up. In my view, any move in any direction has to confront this. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: pTLP, concretely
On Mon, Jan 5, 2015 at 11:11 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 5, 2015, at 7:04 AM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:25 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Jan 5, 2015 at 3:15 PM, Benson Margulies bimargul...@gmail.com wrote: ...This scheme locates that responsibility in the renamed committee, which serves the board by supervising the pTLPs. They aren't mentors, they are PMC members... Ok, but the board needs to accept those folks, and the incoming pTLP needs to locate 4-5 such folks that the board will accept. I bet that would result in smaller potential projects just fading away, which goes against our inclusive principles. I agree. It painfully obvious (to me) that we don't have enough qualified mentors to handle all the small projects that want to show up. In my view, any move in any direction has to confront this. This, imo, is the crux of the problem. This proposal does not focus on this issue other than to rename the roll. Last comment from me for today: to me, PMC membership, and especially PMC chairship, is a big deal. If you accept it, you accept real responsibility, with real potential legal consequences to the Foundation if you screw it up. There's nothing like that about being a mentor. Legally, today, responsibility for podlings sits with the IPMC chair and the IPMC members, collectively, not with the particular mentors in particular of the particular project,. So, again, to me, the pTLP scheme is very different from the current scheme. It seems that other people don't see this the same way that I do. If the general feeling is that PMC membership is 'a joke' like mentorship is 'a joke', then this scheme of mine is just more standup comedy. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)
Back in 2013, I suggested asking the Champion to accept a very clear level of reporting responsibility: to write a sentence or two _every month_ or find someone else to do it. That's one person whom I wanted to ask to sign up, for the duration of an incubation, to pay enough attention to be able to report a basic heartbeat. ? On Mon, Jan 5, 2015 at 3:57 PM, Upayavira u...@odoko.co.uk wrote: On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote: On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote: On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote: On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: The tracking part is easy, though. What's difficult is the part that would require us to do something with poddlings put on hold. Unless we come up with clear exit criteria for this new state -- I don't think we're solving any real problems here. There’s no silver bullet here, if a podling cannot whip up a mentor it’s because: the podling is not popular and should probably be retired anyway, being put on hold will provide impetus for the podling to seek out a new venue there are not enough mentors There is no way to magically solve the latter. You mean popular within the pool of mentors (IPMC), the project can still be popular on several other scales. I’m not speaking of popularity of mentors; I regret that choice of words. I am stating that active and healthy podlings seem to have no trouble attracting active mentors. The converse seems to be true. Unhealthy podlings seem to attract mentors who have signed up out of pity and subsequently go MIA. I agree with the last part, I still have to see mentors volunteer for small active and healthy projects which might not be main road. Of course it depends on how active and healthy is defined, but as an example my little project Corinthia barely managed to get 2 mentors, while in the same time span we got 3 committers. Before anyone replies, I understand this is not a hard and fast rule but an imperfect qualitative observation on my part. Anyway, active and responsible mentors will eventually get to all podlings. I might lack experience, but why do more active mentors guarantee that the podling will be a better TLP ? I’m not sure who’s making that assertion. Well its because I cannot see why a podling need more than 1 active mentor at all timeshaving multiple is fine, to cover each other, but it should not take more than 1 mentor to learn a podling, what it needs to understand. The suggestion implicit says 2 mentors is the minimum needed for at podling to become a successful TLP. We try to solve the problem of mentors not being active but adding more volume. I don't believe that is the right cure. We’re not adding volume. The volume is already there. We’re just making the state of affairs more explicit and transparent and adding culpability for MIA mentors. Do we have a rule today that a podling needs at least 2 active mentors (if we have that, then we would not have a problem with sign offs, or a lot of dead podlings), at least I have not seen itthat is what I mean by adding volume. If just 1 mentor is active and sign off the reports, then I do not see the problem. I do agree with bernard that it is the podling that should ask for helpbut the IPMC should solve it., Yes, it should help solve problems but if there are no mentors available there are no mentors available. Then the IPMC should not have accepted the podling in the first place! It is simply not fair to make the life of a podling, depending on whether or not we have mentors available (REMARK after accepting the proposal) ! If the podling have a healthy community and are active, we cannot and should not close it down, just because we have a mentor problem. To me telling a podling it cannot grow its community nor make releases, is the same as closing it down. Jan, From an idealistic perspective, you are completely right. Apache should, once a project has been accepted, provide the support needed. The reality is that, given the ASF's volunteer nature, that simply won't always work. I'd much rather we be clear with projects right up front, saying something like: To join the Incubator, you need one or more mentors. To get to graduation, you will need the support of those mentors. If mentors become unavailable, you will need to seek replacements. Unless you have already learned the ways of the ASF and are ready to graduate, you will need to keep engaged with your mentors. If possible, engage in the wider ASF, and develop connections with others who might be in a position to assist with mentorship should one or all of your
Re: Reflections from the outgoing Chair
Marvin, I did go away. I came back to help with a podling, and fell into a conversation started by discontented board members. You might push back on the board, formally, and challenge them to either officially be discontented or leave the iPMC alone. Me, I have an idea for a proposal that might make everyone equally unhappy and improve some things. --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reflections from the outgoing Chair
engagement gives the board a very early indicator of its own scalability issues if any. Early warning are a good thing, not something that needs to be feared. All in all, it feels like direct overseeing of Incubating projects would be a good thing for the poddlings, a good thing for the mentors, a good thing for the board and ultimately the only mature and responsible way of making sure that the project we try to embrace get the best shot of becoming ASF TLPs. At this point, I'm struggling to see any potential negative effects. In fact, if there's one thing I really would like everybody commenting on this thread to focus on it would be that: arguing for potential downsides. With that, I'd like to thank all of my IPMC colleagues for this great opportunity and wish all of you the Happiest New Year! Thanks, Roman. == From: Mattmann, Chris A [...snip...] It’s not just the board - again please see the table I’ve listed at the bottom of the wiki. What my proposal does is remove the thinly veiled “IPMC” as the “catch all” which in fact doesn’t catch all. On its 150+ person committee - I supposed there are 20 active people who keep showing up. I have statistics to prove it (see my active mentors tool I’ve shown) - I have experience having mentored many podlings to prove it; and the mailing threads prove it. So, promote those 20 people to ComDev PMC, promote them to ASF members, promote them however, my guess is that they *care* about the foundation; we want these people helping new projects, and they will continue to help those new projects - along with the board - along with everyone else. [...snip...] === From: Benson Margulies [...snip...] Here is where the 'Mentors in the Project' (whether directly reporting to the board or not) leaps up and looks like a great idea to me. The whole goal of incubation is to run an Apache project on training wheels. How does an Apache project run? WIth a chair and PMC members supervising it and _reporting to the board_. The proposal, as I see it, is to tell the champion and other mentors that they, and not the entire IPMC in some nebulous fashion, are the PMC in the PPMC. By the time the podling graduates, their need to have expanded themselves to a larger group. The board may choose to keep the IPMC around to organize and support this process. The board may choose to continue to ask the IPMC to add an extra layer of supervision. But the heart of the proposal is to insist that every podling be nucleated around at least three people who have the experience to operate as a PMC and have volunteered for the responsibility. [...snip...] - 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: Reflections from the outgoing Chair
I'd like to raise a topic directly related to the succession. To start, three cheers for Roman for all his hard work! For all other projects in the Foundation, we say, 'The chair is just a clerk who facilitates communications with the board.' Here at the IPMC, we expect the chair to be moderator of a very fractious set of arguments about how to incubate (or whether to even have an incubator). A leader, even. This strikes me as odd. It is my impression that no one is very happy with the current state of the incubation process. On the other hand, I'm sure, from extensive personal experience, that the IPMC's size is a serious impediment to addressing its issues. It's just very, very, hard to reach consensus at this scale. So, is there an alternative to attempting to find a hero to pull the sword from the stone? My proposal is to form a select committee. This committee would accept the job of creating a comprehensive proposal for where to go with integration. It would, of course, deliberate in public, but the members of the committee would be the only 'committers' on the proposal. The committee would not be required to find a consensus of the entire IPMC, let alone all of members@. The committee would make interim reports to the board so that the proposal could be tuned, incrementally, to be one that the board could accept. This would allow the next IPMC chair to be sign up only to be the sort of modest bureaucrat that we usually talk about. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Git write access for podlings
Every PMC member of a running PMC has a responsibility to keep an eye out for crazy commits. Once this is reflected in the doc, it's good practice for PPMC members. On Wed, Dec 31, 2014 at 3:56 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Wed, Dec 31, 2014 at 12:27 PM, John D. Ament johndam...@apache.org wrote: On Wed Dec 31 2014 at 2:45:48 PM David Nalley da...@gnsa.us wrote: On Wed, Dec 31, 2014 at 2:40 PM, John D. Ament johndam...@apache.org wrote: On Wed Dec 31 2014 at 2:24:36 PM David Nalley da...@gnsa.us wrote: On Wed, Dec 31, 2014 at 11:59 AM, John D. Ament johndam...@apache.org wrote: Hi, So something Jan and I ran into on the infra list, does anyone know definitively what the access rights given to a podling's git repo are, if they request one (instead of a svn directory)? If nothing else we should document it somewhere on the incubator site indicating the permission sets for both svn and git. My current understanding is that svn sites are typically incubator wide, svn repos are confined to a specific list, and git repos are incubator wide. The git one in particular because we don't create ldap groups for podlings and I've heard that we only do groups in git (not individual lists). git is tied to LDAP, and all podling repos are writable by anyone in the incubator LDAP group. (there are no podling LDAP groups) Got it thanks. I'll update the docs to reflect this as the permission scheme. And here I think will come in Jan's bigger question - do we really want all podling committers to be able to commit to all other podlings? My question is: What problem are you trying to solve? And has it really proven to be a problem? I don't think anyone has abused their ability to commit to all projects, and it's been this way as long as git has been available. I'm not sure that there will be an issue. It could just be a couple of IPMC members being a little more cautious that needed. It's more than likely no one's going to care. To date, we have always told podlings that the initial committers and your mentors are the ones who have write access. Now we're saying if you're using git, it's any of the 1k + (i might be way off) members of the incubator group. Would it be much harder to create the ldap group up front when the podling's created, and shuffle people in/out at graduation? If it ain't broke ... Is there even a problem? I haven't ever heard of it. If there isn't a problem, why are you worried about it? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Running an experiment with pTLP
I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it. 2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new board members that represent their views and ethos (including themselves as new board members) 3. Having those board members be part of checks and bounds to *care* and review these projects part of our foundation Or some subset of the above. My point being - IPMC or not - the things you cite below as important will still exist, since this foundation and its people will, hopefully for the next 50+ years. 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: Marvin Humphrey mar...@rectangular.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, December 30, 2014 at 8:03 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Running an experiment with pTLP On Mon, Dec 29, 2014 at 9:01 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: The structure would still be there - my hypothesis is that the mentors + the board will both uplift structure, and help to identify (more quickly) situations like no report, lack of mentors, etc. I am skeptical that Apache policies will be applied evenly under such a regime. For example, release candidates routinely make it to the full IPMC vote with binary dependencies embedded in source. Regardless of intent, removing final review by the wider IPMC will have the effect of liberalizing the policy on bundled binary dependencies for those pTLPs who do not count any sticklers among their Mentors. Rather than change effective release policy for a minority through administrative laxity, the Board should grapple with the full implications of changing it explicitly for everyone. (Yes, that will turn a huge, gory fight considering liability, etc.) Atomizing the IPMC will also yield inconsistency in other areas where there is either confusion or honest disagreement among the Membership as to what our policies are, such as provenance documentation requirements for contributions arriving via Github, or whether PMC chairs are special. Nevertheless, +1 to move forward with the pTLP experiment (whatever that means). Odds are that any given pTLP will work
Re: Running an experiment with pTLP
On Tue, Dec 30, 2014 at 2:25 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Thanks Benson - I would suggest using the Incubator wiki if you need one (but the point about there not being a Board wiki - interesting, would be nice to have one). At the end of the day the resolution would look like a typical board resolution after Incubator graduation e.g., “Create Apache X”, so it would be summarized as you mention in point #3 below. Chris, I agree that the simplest model of (p)TLP hasn't much of a (p): it would be a normal resolution, and we'll be off to the races. I plan, if the Nifi group is game, to send mail to the board offering that option, and then back off to a more complex proposal if the board wants more (p) -- like PR restrictions, or some sort of policy on how the initial podling group gets incorporated into the PMC. --benson Cheers and good luck. 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: Benson Margulies bimargul...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, December 30, 2014 at 11:12 AM To: general@incubator apache. org general@incubator.apache.org Subject: Re: Running an experiment with pTLP I plan to: 1. Ask the nifi community if they want to be experimental subjects. Can't expect IRB approval without it. 2. Write a proposal for the board to read. There are a number of details to worry over. Any suggestions about where to put it? There in no board wiki. Is there? 3. Submit a board resolution when I think there is a consensus. On Dec 30, 2014 12:24 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Marvin, I completely agree with you - to sum it up - my take on your point that Apache has a lot of information and guidelines for new podlings that is somewhat inconsistently brought down to new generations and those after them of incoming projects. Have a mentor that’s a stickler for release candidates - you will see projects come out believing that is the end-all be-all for Apache (“gah, Apache is the communist release foundation!”). Have a mentor that is a stickler for diversity on incoming projects, podlings will come out believing there is some rule that a committee can’t have a majority of contributors from a single organization (“Ahh _that_ company is taking over an _Apache_ project! Gasp!”). Have a mentor that’s a stickler for adding anyone that drops by on the mailing list that says hi (ahem..ducks) you’ll have podlings coming in and new committees believing in low barriers to committership and PMCship. Regardless the above is the ethos of Apache and by and far, it will exist, IPMC or not. There is no reason that the current f_active(IPMC) = [some # less than 20] couldn’t simply still exist either in official committee form (its own; or on the ComDev PMC), and continue to do the same thing. It’s my belief that the genetic makeup of active IPMC members includes a few mentors cut from each of the important incoming new project areas that are important to pass down - legal, release review, community and participation, etc - and that we should as best as possible try and have a set of 3 that represents some nice representative cross section of those skills for the new projects. Furthermore, there is nothing stopping anyone from: 1. Making ASF members out of anyone that’s part of that active IPMC list that’s not already a member 2. Having those ASF members vote in new board members that represent their views and ethos (including themselves as new board members) 3. Having those board members be part of checks and bounds to *care* and review these projects part of our foundation Or some subset of the above. My point being - IPMC or not - the things you cite below as important will still exist, since this foundation and its people will, hopefully for the next 50+ years. 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
Re: Running an experiment with pTLP
On Tue, Dec 30, 2014 at 4:17 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: +1 to everything Ross said below and I monitored that experiment as well but was unaware of the 3 incidents, etc. As for pTLPs and shifting mentorship, etc., I trust Ross’s judgement but think we need more data on this across a number of projects before we know definitively what’s the cause of what, etc. If I was 'in the room' for the last time around, I seem to have forgotten. If I volunteered to write something, gosh I'm sorry and please do call me out here. Meanwhile: I think that there's some complexity here: At one extreme, consider 5 members with a demonstrable track record on IP issues and supervision who want to launch a new project (for example, a proposed VP who has been a success as a project VP on some other project(s)). Regardless of anything else, I suspect that they could go to the board, propose to launch a TLP directly, and have a pretty good chance of the board approving it. That's not really what pTLP is about, though. pTLP says, 'here we have some people who are willing to serve as the supervision structure of a new TLP but expect to fade away; they aren't necessarily planning to be write any code. They are members, but, hmm, members come in all sorts of different levels of experience with the issues faced by new projects. With all respect to ChrisM on the subject of letting the IPMC itself fade away, I read Ross' statement as pointing out that this situation seems to need some work done that the board doesn't want to do for itself. The board might want, gee, some committee, to help vet proposals, and perhaps to help keep an eye on them once they are running. That's what I meant by wondering 'how much (p) does the board want?' (Aside, as the number of projects grows and grows, it seems to me that the board might need some help supervising all the regular projects.) This brings me back to my idea of a wiki page. If the board is looking for a 'pTLP' to be more self-governing than a 'podling' but still have the IPMC accept some sort of responsibility for it, we need to write down the boundaries as part of proposing to the board. If NiFi wants to try this, I'm still happy to write the 'simple' proposal to the board, and wait upon the board's desires. If the board members in this thread feel that writing the simple proposal is a waste of time and energy, I won't write it. None of this stops the IPMC itself from shifting policy, experimentally, to require Mentors to act as PPMC members. I think I've used my quote of characters for the year on this subject. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
I'd like to look at this through a lens of failure analysis. How do podlings fail? I see two main patterns. 1. Failure to build a community. These are the podlings that we find adrift in space with the lights on but no one home on the mailing list. 2. Failure to build an _Apache_ community. These are the podlings that JimJag was referring to in another thread; they are here, perhaps, for the brand, perhaps launched/dumped here by a commercial enterprise. They have people, they make releases, but there's an empty resonant cavity where the Apache Way is supposed to be. We observe missing mentors in both cases, but I claim that it's only a serious problem in the second case. In the first case, the problem isn't lack of supervision. Here is where the 'Mentors in the Project' (whether directly reporting to the board or not) leaps up and looks like a great idea to me. The whole goal of incubation is to run an Apache project on training wheels. How does an Apache project run? WIth a chair and PMC members supervising it and _reporting to the board_. The proposal, as I see it, is to tell the champion and other mentors that they, and not the entire IPMC in some nebulous fashion, are the PMC in the PPMC. By the time the podling graduates, their need to have expanded themselves to a larger group. The board may choose to keep the IPMC around to organize and support this process. The board may choose to continue to ask the IPMC to add an extra layer of supervision. But the heart of the proposal is to insist that every podling be nucleated around at least three people who have the experience to operate as a PMC and have volunteered for the responsibility. On Mon, Dec 29, 2014 at 7:01 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Dec 29, 2014 at 6:40 AM, Rich Bowen rbo...@rcbowen.com wrote: Roman, please forgive me absence from this conversation. I started the thread, and then went on Christmas vacation. I am still on vacation for another week, but will attempt to keep up with the conversation here, and not abandon the thread I started. Please also forgive the dozen responses that I'm dropping all at once. This totally makes two of us. Every time Christmas season begins this is very much the predicament I find myself in. Thanks, Roman. P.S. Not even sure whether it would be better to simply go away 100% so at least folks get a nice auto-responder email while I can't be present anyway. - 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: Running an experiment with pTLP
On Mon, Dec 29, 2014 at 6:14 PM, Roman Shaposhnik r...@apache.org wrote: Please note the change of subject. On Mon, Dec 29, 2014 at 6:28 AM, Rich Bowen rbo...@rcbowen.com wrote: On 12/19/2014 02:20 PM, Mattmann, Chris A (3980) wrote: What it would do however if we simply did away with the notion of the IPMC/Incubator/etc., is to return to the notion of pTLPs which were proposed earlier which I would most wholeheartedly support. Having read more, and understood more, and consumed more coffee ... I wonder if we might implement this proposal with one incoming project, as a test, under close observation by the board and the IPMC? Might be seen as grossly unfair by the project that remain in the old regime (or, who knows, maybe also by the test project), but it might give us some deeper insight into whether this fixes anything? This is very much what others were suggesting on the thread as well. Given that I'll be mentoring Zeppelin, I'd love to use that as a guinea pig. Provided, that I'd have some level of collaboration from the board. Perhaps between three of us (Chris, Rich and I) this is all we need. Thoughts? Any interest in a retroactive retrofit of NiFi? 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: Incubator report sign-off
Back when I was trying to be the chair of this operation, we (ChrisM I others) had a lovely old food fight about Chris M's proposal. It seems to me that the fundamental situation as I saw it remains: this is a proposal to the board to dissolve the IPMC and replace it with something else. And just to be clear: I think that it's a _good idea_ as a proposal to the board. I think that it amounts to making the Foundation's policy be: You can launch a new project in the Foundation if you can recruit three foundation members (or others acceptable to the board) as the nucleus of your PMC to teach you the ropes and ensure that policies are respected; from the start, you're an 'incubating TLP' reporting to the board like all other TLPs. I don't think that those three people have, necessarily to be coders. But they have to be fully engaged -- they have to be members of the community and the PMC. It seems to me that any scheme short of this is guaranteed to end up right back where we are; struggling to simulate working PMCs with shepherds and mentors and champions and, I don't know, curators and wardens and counselors. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator report sign-off
On Fri, Dec 19, 2014 at 6:09 PM, Louis Suárez-Potts lui...@gmail.com wrote: Are we top posting now? My comments below Ross’ On 19 Dec 2014, at 16:33, Dennis E. Hamilton dennis.hamil...@acm.org wrote: As a participant, I have two concerns about a player-mentor requirement. 1. Sustainability. In many ways, it is mentors who need to have their attention on The Apache Way and cultivating a sustainable project. That means, from my perspective, that mentors need to encourage others to do things, especially around project management and procedural matters, and not just take on matters without leaving any bread crumbs. It seems important that others learn how to do that sort of thing too, whether or not special karma is eventually required to perform the same activities. 2. I have learned repeatedly, and it is evidently well-known, that a developer is his own worst project manager. It has to do with attention being at a completely different place when heads-down in development tasks than when heads-up watching the horizon and keeping objectives and current effort aligned. When I am in developer mode, I need someone else to pull my attention out of the weeds and look to see what course I am on and where I am at on that course. I remember in the 60s when a colleague had ended up managing a project at GE Medical Systems (or something similar) and he confessed that his team made a terrible mistake -- they allowed him to program on their project. I'm not saying that a mentor could not be an effective player. I think doing it well while mentoring is not common and it might interfere with training and development as well. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Friday, December 19, 2014 11:01 To: general@incubator.apache.org Subject: RE: Incubator report sign-off Strawman: What if a mentor is *required* to be an active participant of the project. That is contributing code, voting on releases and generally engaging with the community, they would be a better mentor since they have a vested interest in the project itself. Sure, we might reduce the number of projects coming into the foundation but (IMHO) that is not a problem. Our goal as a foundation is not to be large, it is to be high quality. [ … ] Accepting Dennis’ point, but I think that there’s a difference between being in a large corporation doing in-house work and participating part time as a mentor. It’s as if I were (as I do) to teach courses after work that relate to my expertise but are not identical to it, if only because I like to think that I’m more advanced than any student I’d have. In prior instances where we’ve had mentors, or where I know of them, e.g., Mozilla’s Firefox extension program at Seneca College, Toronto, where the lead instructor of the classroom of students (as well as of individual pupils) is a developer at Mozilla. (He’s paid indirectly by Mozilla to teach, I believe; that, at least, was at the arrangement we had with Seneca for OpenOffice instruction, and ours was modelled on Mozilla’s.) In fact, the argument presented to me by the instructor was that it was essential to be an active developer, at least if one were instructing students on both the collaborative dynamics as well as the code itself. To be sure, one need not be immersed in the project (i.e., have it as a day job), but being engaged and current with the latest was important. But to stipulate it as a requirement? Why? Why make it a requirement and not just a recommendation, albeit a strong one? the only thing gained by making it a requirement—and in bold, too—is to have a tool by which one could eliminate candidates. And I do not think that is in the spirit of a pragmatic open source project. louis - 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 I'm not top-posting. I think the 'involved mentors' is part of an attempt to resolve several conflicting desires. The mentor model is that the PPMC members start out being all of the doers, and the mentors are coaches and supervisors. Conflict #1: coaching and supervising is not always a happy combination. Conflict #2: coaching means staying in the background to a large extend, as per Ross' statement. 'In the background' can be perilously close to 'gone fishing.' How does the IPMC (or whomever) tell the difference? Conflict #3: there's a shortage of people to mentor, and that leads to people with good intentions signing up and then failing to deliver. Over years, we've send
Re: Documentation of voting rules.
Apache PMCs, including the incubator PMC, operate by consensus except in a very small number of enumerated exceptional cases. So, the vote, I think, is a test of consensus. -1 votes block consensus until discussed to 0. There's no minimum number of +1 votes. I am always prepared to be corrected. On Tue, Dec 2, 2014 at 12:09 PM, jan i j...@apache.org wrote: Hi. I have just called for a vote on corinthia, and got a question about the voting rules from the project. I digged into the documentation, and all I can find is the fact that a vote has to be called. I cannot find a definition of the vote (yes I can find our general voting rules, but not which one applies in this case). Can someone please point me towards a document where it is defined, otherwise I suggest we change the documentation to make it clear. Thanks in advance. rgds jan I. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Website for Tamaya - need help
I had incorrectly inferred pubsub from the prior email thread. On Sat, Nov 29, 2014 at 11:22 AM, John D. Ament johndam...@apache.org wrote: Thanks for your help Drew! I missed devicemap. I think I was looking for newer podlings (johnzon or batchee or usergrid) none of whom had sites. It's possible they're not going through CMS though. John On Sat Nov 29 2014 at 11:15:54 AM Drew Farris d...@apache.org wrote: On Sat, Nov 29, 2014 at 9:58 AM, John D. Ament johndam...@apache.org wrote: One other thing (sorry!) I notice on the cms.apache.org landing page, none of the podlings are listed. How do podlings publish? Actually, it looks like there are podlings listed in [export], and on cms.apache.org proper (e.g: devicemap). I'm going to assume that will be or can be modified once the site is set up properly. [export] https://svn.apache.org/repos/infra/websites/cms/webgui/ content/export.json On Sat, Nov 29, 2014 at 9:55 AM, John D. Ament johndam...@apache.org wrote: Drew, default-perl would make the most sense. They're going to manage the asciidoc files within standard source, use a site plugin to publish the html to the SVN directory. This should end up being very similar to batchee's [setup]. Thanks! John [setup]: https://git-wip-us.apache.org/repos/asf/infrastructure- puppet/repo?p=incubator-batchee.git;a=blob;f=pom.xml;h= fdad006cb0335098bd801b1159a1390334436161;hb=HEAD#l427 On Sat, Nov 29, 2014 at 9:50 AM, Drew Farris d...@apache.org wrote: John, I just took a quick look at this. It appears the options are svnpubsub or Apache CMS. For CMS, you have a choice of 'cms build type': default-perl, maven, ant, or shell. It sounds like you want Apache CMS, do you have any thoughts about the 'cms build type' option? Drew -- Drew Farris drew.far...@gmail.com d...@apache.org On Sat, Nov 29, 2014 at 9:18 AM, John D. Ament john.d.am...@gmail.com wrote: Benson, Thanks. So I don't know what that page is expecting since I can't actually see it. If you require a temporary index.html, I can upload one. In which case, the full URL would be https://svn.apache.org/repos/asf/incubator/tamaya/site/ trunk/index.html for the staging site to read from. I think we're expecting staging/production via Apache CMS ( cms.apache.org). John On Fri, Nov 28, 2014 at 8:05 PM, Benson Margulies bimargul...@gmail.com wrote: On Fri, Nov 28, 2014 at 6:13 PM, John D. Ament johndam...@apache.org wrote: https://infra.apache.org/officers/webreq I tried: Missing https://svn.apache.org/repos/asf/incubator/tamaya/site/index.html - 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: Website for Tamaya - need help
On Fri, Nov 28, 2014 at 6:13 PM, John D. Ament johndam...@apache.org wrote: https://infra.apache.org/officers/webreq I tried: Missing https://svn.apache.org/repos/asf/incubator/tamaya/site/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: NiFi setup
I'll repair my work on the metadata. On Tue, Nov 25, 2014 at 9:35 PM, John D. Ament johndam...@apache.org wrote: Group 2 is for groups podlings that started in months such as November. First report would be December. On Tue, Nov 25, 2014 at 9:30 PM, Benson Margulies bimargul...@gmail.com wrote: Starting with a December report makes sense. So, group changes too. On Tue, Nov 25, 2014 at 9:27 PM, John D. Ament johndam...@apache.org wrote: On Tue, Nov 25, 2014 at 9:18 PM, Benson Margulies bimargul...@gmail.com wrote: Oh, that was not my smartest moment. Should I change the xml file to move out a month? I don't think we've got something worth reporting. I'd leave that up to you guys. Personally I'd like to see a nifi report for December, but if you feel it should be postponed it should be postponed. But then should we consider you a reporting group 3 podling? On Tue, Nov 25, 2014 at 9:14 PM, John D. Ament johndam...@apache.org wrote: On Mon, Nov 24, 2014 at 4:58 PM, Benson Margulies bimargul...@gmail.com wrote: One message here to make progress in public before we have NiFi mailing lists: I've added nifi to podlings.xml and I've created nifi.xml. Are you intending to have nifi report this month? I noticed in podlings.xml you have the months listed of November, December January. November was reported out a few weeks back, before nifi was accepted. If you're expecting to report please add your report to the wiki. John I've opened INFRA-8706 for the mailing lists. I plan to write one other JIRA for a git repo; after that, we need discussion on the list to be sure of what we want. Once we have some mailing lists, we can coordinate next steps. Initial committers can get/keep those ICLA cards and letters coming in. - 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 - 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: SVN Access Rights question
On Tue, Nov 25, 2014 at 1:24 PM, Alan D. Cabrera l...@toolazydogs.com wrote: I suspect that only Roman and other VPs can do this. http://incubator.apache.org/guides/mentor.html seems to be claiming the contrary. Regards, Alan On Nov 25, 2014, at 10:23 AM, John D. Ament johndam...@apache.org wrote: Hi, Does anyone know what access rights are required to be able to add a podling to SVN here: http://svn.apache.org/repos/asf/incubator/ I tried adding tamaya but it came back with an error that I wasn't authorized. John - 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: NiFi setup
Oh, that was not my smartest moment. Should I change the xml file to move out a month? I don't think we've got something worth reporting. On Tue, Nov 25, 2014 at 9:14 PM, John D. Ament johndam...@apache.org wrote: On Mon, Nov 24, 2014 at 4:58 PM, Benson Margulies bimargul...@gmail.com wrote: One message here to make progress in public before we have NiFi mailing lists: I've added nifi to podlings.xml and I've created nifi.xml. Are you intending to have nifi report this month? I noticed in podlings.xml you have the months listed of November, December January. November was reported out a few weeks back, before nifi was accepted. If you're expecting to report please add your report to the wiki. John I've opened INFRA-8706 for the mailing lists. I plan to write one other JIRA for a git repo; after that, we need discussion on the list to be sure of what we want. Once we have some mailing lists, we can coordinate next steps. Initial committers can get/keep those ICLA cards and letters coming in. - 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: NiFi setup
Starting with a December report makes sense. So, group changes too. On Tue, Nov 25, 2014 at 9:27 PM, John D. Ament johndam...@apache.org wrote: On Tue, Nov 25, 2014 at 9:18 PM, Benson Margulies bimargul...@gmail.com wrote: Oh, that was not my smartest moment. Should I change the xml file to move out a month? I don't think we've got something worth reporting. I'd leave that up to you guys. Personally I'd like to see a nifi report for December, but if you feel it should be postponed it should be postponed. But then should we consider you a reporting group 3 podling? On Tue, Nov 25, 2014 at 9:14 PM, John D. Ament johndam...@apache.org wrote: On Mon, Nov 24, 2014 at 4:58 PM, Benson Margulies bimargul...@gmail.com wrote: One message here to make progress in public before we have NiFi mailing lists: I've added nifi to podlings.xml and I've created nifi.xml. Are you intending to have nifi report this month? I noticed in podlings.xml you have the months listed of November, December January. November was reported out a few weeks back, before nifi was accepted. If you're expecting to report please add your report to the wiki. John I've opened INFRA-8706 for the mailing lists. I plan to write one other JIRA for a git repo; after that, we need discussion on the list to be sure of what we want. Once we have some mailing lists, we can coordinate next steps. Initial committers can get/keep those ICLA cards and letters coming in. - 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: [RESULT] [VOTE] accept NiFi into the incubator
The vote for NiFi incubation has passed. I will go start turning cranks. Nonbinding +1: Sean Busaby Brock Noland Ryan Blue Joey Echeverria Binding +1: Tim Williams Chris Mattmann Suresh Srinivas Chris Douglas John D Ament Benson Margulies Jake Farrell Andrew Purtell Bertrand Delacretaz Advind Prabhakar Alan D. Cabrera Ted Dunning j...@apache.org Sergio Fernández
Incubator website guide
Following http://incubator.apache.org/guides/website.html, I ran 'ant' (and also build.sh) after adding nifi to podlings.xml and added the nifi.xml fille. It didn't produce any changed files to commit. Is the guide behind? Am I confused?
NiFi setup
One message here to make progress in public before we have NiFi mailing lists: I've added nifi to podlings.xml and I've created nifi.xml. I've opened INFRA-8706 for the mailing lists. I plan to write one other JIRA for a git repo; after that, we need discussion on the list to be sure of what we want. Once we have some mailing lists, we can coordinate next steps. Initial committers can get/keep those ICLA cards and letters coming in. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator website guide
On Mon, Nov 24, 2014 at 6:24 PM, John D. Ament johndam...@apache.org wrote: On Mon, Nov 24, 2014 at 5:46 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 24, 2014, at 1:49 PM, Benson Margulies bimargul...@gmail.com wrote: Following http://incubator.apache.org/guides/website.html, I ran 'ant' (and also build.sh) after adding nifi to podlings.xml and added the nifi.xml fille. It didn't produce any changed files to commit. Is the guide behind? Am I confused? python3 clutch.py ant svn ci -m Run clutch. ssh -t a...@people.apache.org publish.pl incubator adc works for me. So then the clutch is missing from the page Benson mentioned, no? Yes it is, which is ironic, given that I wrote some of the code of it. I did fix the reference to discuss target/site which is where the content actually lands. I'm going to do something about git, too. Regards, Alan - 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] NiFi for Incubation
I've advised Joe to 'asterix' the would-be mentors who are not iPMC yet, so that he can proceed to a vote on the base of the ones who are sooner rather than later, and the stragglers can be formally added to the metadata once they are on the iPMC.
[VOTE] accept NiFi into the incubator
http://wiki.apache.org/incubator/NiFiProposal has elicited a cheerful and positive conversation, so I offer this vote. Vote will be open for the usual 72 hours ... Here is my [+1]
Re: [VOTE] accept NiFi into the incubator
What, the whole text? OK. On Fri, Nov 21, 2014 at 2:03 PM, Jake Farrell jfarr...@apache.org wrote: Hey Benson Can you please include the proposal with the vote, the wiki page can change or be removed and the mailing list acts as the archive for the initial proposal. -Jake On Fri, Nov 21, 2014 at 1:55 PM, Benson Margulies bimargul...@gmail.com wrote: http://wiki.apache.org/incubator/NiFiProposal has elicited a cheerful and positive conversation, so I offer this vote. Vote will be open for the usual 72 hours ... Here is my [+1]
Re: [VOTE] accept NiFi into the incubator
to grow the community. The project user and developer base is substantial, growing, and there is already extensive operational use of Ni``Fi. === Inexperience with Open Source === The initial committers to Ni``Fi have limited experience with true open source software development. However, despite the project origins being from closed source development we have modeled our behavior and community development on The Apache Way to the greatest extent possible. This environment includes widely accessible source code repositories, published artifacts, ticket tracking, and extensive documentation. We also encourage contributions and frequent debate and hold regular, collaborative discussions through e-mail, chat rooms, and in-person meet-ups. We are committed to the ideals of open source software and will eagerly seek out mentors and sponsors who can help us quickly come up to speed. === Homogenous Developers === The initial committers of Ni``Fi come from a limited set of entities though we are committed to recruiting and developing additional committers from a broad spectrum of industries and backgrounds. === Reliance on Salaried Developers === We expect Ni``Fi development to continue on salaried time and through volunteer time. The initial committers are paid by their employers to contribute to this project. We are committed to developing and recruiting participation from developers both salaried and non-salaried. === Relationship with other Apache Projects === As described in the alignment section, Ni``Fi is already heavily dependent on other ASF projects and we anticipate further dependence and integration with new and emerging projects in the Apache family. === An Excessive Fascination with the Apache Brand === We respect the laudable Apache brand and that is certainly a factor in the decision to propose Ni``Fi for the Apache Incubator. The ASF is a natural home for Ni``Fi given our existing dependency and alignment with ASF projects. We intend to provide a great deal of energy and capability to the ASF through this project. We will be sensitive to and respectful of any overuse of the Apache brand and ensure our focus remains on how we benefit the Apache community. === Documentation === At this time there is no Ni``Fi documentation on the web. However, we have extensive documentation included within the application that details usage of the many functions. Using incubator INFRA we will be rapidly expanding the available documentation to cover things like installation, developer guide, frequently asked questions, best practices, and more. == Initial Source == Ni``Fi has been in active development since late 2006 with contributions from dozens of developers and feedback from hundreds of users and developers. The core codebase is written in Java and includes detailed Javadocs and feature documentation. == Source and Intellectual Property Submission == Previously referred to as Niagarafiles, the Ni``Fi code and documentation materials will be submitted by the National Security Agency. Ni``Fi has been developed by a mix of government employees and private companies under government contract. Material developed by the government employees is in the public domain and no U.S. copyright exists in works of the federal government. For the contractor developed material in the initial submission, the U.S. Government has sufficient authority to open source per DFARS 252.227-7014. NSA has submitted the Software Grant Agreement and Corporate Contributor License Agreement to the Apache Software Foundation. == External Dependencies == We have at least one dependency on an LGPL library which we will promptly address. Otherwise, we believe all current dependencies are compatible with the ASF guidelines. Our dependency licenses come from the following license styles: Apache v 2.0, BSD, Public Domain, Eclipse Public v1, MIT, CDDL v1. == Cryptography == Consistent with http://www.apache.org/licenses/exports/ we believe Ni``Fi is classified as ECCN 5D002. Ni``Fi doesn't implement any cryptographic algorithms but is designed to use algorithms provided by Oracle Java Cryptographic Extensions, Bouncy``Castle, and JCraft, Inc. These cryptographic algorithm providers are used to support SSL, SSH/SFTP, and the encryption and decryption of sensitive properties. In the event that it becomes necessary we will engage with appropriate Apache members to ensure we file any necessary paperwork or clarified any cryptographic export license concerns. == Required Resources == === Mailing Lists === * u...@nifi.incubator.apache.org * d...@nifi.incubator.apache.org * priv...@nifi.incubator.apache.org * comm...@nifi.incubator.apache.org === Source Control === Ni``Fi requests use of Git for source control (git://git.apache.org/nifi.git). We request a writeable Git repo for Ni``Fi with mirroring to be setup to Github through INFRA. We request sponsor Benson Margulies (bimargulies) to assist with creating the INFRA
Re: [PROPOSAL] NiFi for Incubation
, and JCraft, Inc. These cryptographic algorithm providers are used to support SSL, SSH/SFTP, and the encryption and decryption of sensitive properties. In the event that it becomes necessary we will engage with appropriate Apache members to ensure we file any necessary paperwork or clarified any cryptographic export license concerns. == Required Resources == === Mailing Lists === * u...@nifi.incubator.apache.org * d...@nifi.incubator.apache.org * priv...@nifi.incubator.apache.org * comm...@nifi.incubator.apache.org === Source Control === NiFi requests use of Git for source control (git://git.apache.org/nifi.git). We request a writeable Git repo for NiFi with mirroring to be setup to Github through INFRA. We request sponsor Benson Margulies (bimargulies) to assist with creating the INFRA ticket for this. === Issue Tracking === JIRA NiFi (NIFI) === Initial Committers === * Brandon Devries brandon.devries at gmail dot com * Matt Gilman matt.c.gilman at gmail dot com * Tony Kurc trkurc at gmail dot com * Mark Payne markap14 at hotmail dot com * Adam Taft adam at adamtaft dot com * Joseph Witt joewitt at gmail dot com === Affiliations === * Brandon Devries (Requitest, Inc.) * Matt Gilman (Raytheon) * Tony Kurc (National Security Agency) * Mark Payne (Sotera Defense Solutions, Inc.) * Adam Taft (Requitest, Inc.) * Joseph Witt (National Security Agency) == Sponsors == === Champion === * Benson Margulies (Basis Technology) bimargulies at apache dot org === Nominated Mentors === * Drew Farris (Booz Allen Hamilton) drew at apache dot org * Brock Noland (Cloudera) brock at apache dot org * Billie Rinaldi (Hortonworks) billie at apache dot org === Sponsoring Entity === We request the Apache Incubator to sponsor this project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Sean
Initial import with git
http://incubator.apache.org/guides/mentor.html#initial-provenance has some svn specific commentary. If an incoming podling has a git repo, can it just be pushed into place as the starting point? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mentors heartbeat
Everyone who has ever mentored anything is a member of this PMC, except for those who have actually chosen to depart. In addition, we have PMC members who specialize in things like NOTICE files, but don't choose to mentor individual projects. In general, there is a mentor shortage. If you have a strong mental stomach, read archives going back a few years, and you can see some rather, ahem, spirited debates as to whether the entire iPMC/mentor model is hopelessly broken and should be trashed. Of late, talented PMC chairs have managed to steer the boat away from those rocks, but the mentor shortage is never completely gone. I am a programmer and like formats like JSON, but it is true that the world does not only consist of programmers, so I suggest we make 2 webpages: - one page that create/modify the report and update svn with the JSON file - one page where mentors can sign the report json === yaml, and anyone could edit yaml. I am not so sure if its worth while with the board report. rgds jan i Regards, Alan On Aug 23, 2014, at 3:23 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Sorry https://github.com/chrismattmann/apachestuff Sent from my iPhone On Aug 23, 2014, at 3:22 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Check my apachestuff GitHub repo https://guthub.com/chrismattmann/apachestuff Sent from my iPhone On Aug 23, 2014, at 3:16 PM, Roman Shaposhnik r...@apache.org wrote: Hi! in my never ending quest to help boost the graduation rate I've come across a few cases where I had to reach out to project mentors. Typically the initial list would be around 3 individuals, but the reply would only come from a single one. I believe we owe it to the projects to monitor whether there mentors are MIA and take corrective actions. There's not too many promises that we IPMC makes to the podlings, but promising a reasonable amount of mentor attention is definitely one of them. I'm open to suggestions of how we can start tracking MIA mentors and what actions would help to remedy the situation. 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: Mentors heartbeat
On Sun, Aug 24, 2014 at 2:07 PM, jan i j...@apache.org wrote: On 24 August 2014 19:54, Alan D. Cabrera l...@toolazydogs.com wrote: On Aug 24, 2014, at 10:51 AM, Alan D. Cabrera l...@toolazydogs.com 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. I think you forget one important factor...the human one, to make the board reports in yaml, we need to convince the board, and I not convinced they have a futuristic view as you have. You might also find, just a small number of course, people who resist to using svn and want git, so we might end up with split data. It's not a problem. We turn yaml into prose with a template! The board will never know ... actually, really, I think that the board will be fine with some information in yaml. But I do agree with your POW, and would like to more automated processes. rgds jan i. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: GSoC Donation and/or clearance
If the student provides it as a patch, then you are asking the usual question about the quantity of code. There is no hard and fast rule, but unless it's very large, the AL is very clear; patches sent to mailing lists or attached to issue tracking systems or any of that are covered by the AL. If the amount of code is very large, or if the code is not clearly attached to a patch on a mailing list of issue tracker, then you would need an ICLA. The SGA usually comes into play if the code is not the work and property of an individual. The SGA allows some entity to grant the AL unambiguously. If the code is the work and property of an individual, the ICLA does that just fine. Typically, the SGA is used for corporations donating code to projects. On Thu, Jan 9, 2014 at 5:23 AM, Pepijn Noltes pepijnnol...@gmail.com wrote: Hi, On Wed, Jan 8, 2014 at 3:53 PM, Ted Dunning ted.dunn...@gmail.com wrote: The standard rules all apply to GSoC students. They should do their code in as close to the standard way as possible (which would have precluded the code being outside at this point) and they should file and ICLA if they do enough to warrant it. Thanks for the answer. It is not clear for me how the standard way would have precluded the code being outside. IMO the standard way is to communicate / discuss by mailing list, developed code outside and accept it as patch. Then the student could have earned enough karma to be accepted as committer. But maybe I am missing something? This is also how we structured the GSOC project and as result the code is written outside the foundation. The questions we are now struggling with are: to accept the donation do we need an IP clearance?, if yes is a code grant needed? and if yes again who should sign this grant ? Greetings, Pepijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Hoya Proposal
If you can work out a plan to do this directly in Hadoop, there's no need for the incubator. You just build and and contribute it in cahoots with them, and earn commit over there as you go. On Thu, Jan 9, 2014 at 11:14 AM, Alejandro Abdelnur t...@cloudera.com wrote: Mmmh, if i recall correctly this has come up in the past with other projects and it was decided against it. Could you please check with the hadoop folks about it? Thx On Jan 9, 2014, at 1:19 AM, Steve Loughran ste...@hortonworks.com wrote: no its wrong, it should all be under org.apache.hoya. I had the hadoop prefix so that I could perhaps put it straight into the hadoop code as another tools module -no need for incubation. But as the actual providers and all tests are related to the deployment of hbase and accumulo, it really comes downstream of those. so a rename is needed. but yes, ASF headers everywhere On 8 January 2014 22:48, Henry Saputra henry.sapu...@gmail.com wrote: I like how the initial code already put under org.apache.hadoop.hoya with correct ASF header =) - Henry On Wed, Jan 8, 2014 at 7:08 AM, Steve Loughran ste...@hortonworks.com wrote: I'm starting to put together the incubation proposal for Hoya: a tool to dynamically deploy applications such as HBase or Accumulo on YARN https://wiki.apache.org/incubator/HoyaProposal It does already work to the extent that it can bring up either application, run different clusters of different versions, and remember where containers were allocated so that on application restart it can ask for them back. That increases data locality and makes a big difference with HBase. It also needs a lot more work -YARN-896 is adding YARN features that help, but there's lots of fun to be had in Hoya including -leading edge work in failure handling, modelling cluster unreliability and reacting to it. Can we move beyond simple blacklisting to greylisting, accepting unreliable boxes if we have no altenatives Then there's adding more providers, to support different application installations -I'm starting to write a functional test framework which need provider-specific workload generations Other features: AM should have a web ui that redirects to the live endpoints to all the app-specific UIs (e.g. HBase Master GUI), as well as displaying cluster state itself, for people and for management tools To summarise: lots of fun to be had -steve -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. - 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: IP Clearance before releasing
Therefore, when we say that incubating releases can have small IP loose ends, we mean: * This is an official release, created by an act of the Foundation. * It is known to violate policy. * It could be removed, but no one has done so yet. I'm comfortable with relying on prosecutorial discretion for inconsequential small stuff, but not something major like source code provenance. Well, that third line is not what I meant. In law, and so in Foundation policy, there is always a concept of materiality. Nothing is perfect. People make mistakes, and the legal framework that we're working in when we make a release has room for them. If some PMC makes a release with 10 lines of 'category X' code in it, I do not believe that anyone thinks that removing it is appropriate or necessary. I was really trying to talk about trivial issues. Maybe I should have written 'tiny' instead of small. Maybe I should have focussed on LN problems, where there are many opportunities to make an immaterial error. The bottom line should be a repetition of your repetition of Doug - a release is a release, incubator or not. If we deleted every release from the main Foundation distro area that had some divergence from some policy, no matter how tiny, my suspicion is that the distro area would become rather sparse. - 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: Cultivating Outstanding IP Stewards
Joining a PMC does not meaning being handed even one of the keys to the launch console for a nuclear missile. Joining a PMC means accepting responsibility for the supervision of a project. We vote to add someone to a PMC when they have shown the necessary commitment and, well, common sense. Part of 'common sense' is knowing what you know and what you don't know. Not every PMC member needs to be prepared to wade into every swamp, just as not every committer is qualified to modify every class in the source code. We add committers when have evidence to justify trusting them to do the right thing (with the PMC as backstop supervision), and we add PMC members similarly, with the backstop of the rest of the PMC. On Sun, Nov 17, 2013 at 6:17 AM, Upayavira u...@odoko.co.uk wrote: On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: On 11/16/13 8:47 AM, Upayavira u...@odoko.co.uk wrote: Alex, I'm not sure I see the difference between a release auditor and an IPMC member. If someone is sufficiently clued up to audit a release, then they're surely ready to join the Incubator PMC. Am I missing something? To me, there is more responsibility in being on the IPMC, like reviewing proposals for new podlings and voting on their graduation and becoming a mentor. Personally, that's why I don't want to be on the IPMC, but I might be willing to help IP audit a podling's release. Just like some projects don't have all committers on the PMC, a Release Auditor is just someone who can do that specific task, and there is no need to vote them in if they are already on some other TLP PMC because any member of a TLP PMC supposedly knows how to do release auditing. My interest is in a lesser level of involvement, where someone has shown merit within their own PPMC and can get a binding vote there, but no-where else. That feels to me like a very useful intermediate step to have. I agree, except for the no-where else part. If you know how to check a RAT report and have an idea of what should be in the NOTICE files, you should be able to help out any other podling by reviewing their release and casting a binding vote so they can learn how to do that. I'd say that 3 IPMC members must vote to give a person Release Auditor status if they are not already on a TLP PMC. Consider this: I am an the Flex PMC but not the IPMC, but if I join the PPMC of some new podling, why shouldn't I be able to cast a binding vote for that podling's releases? With a two tier model - with PPMC membership granting voting rights on podling releases, then a podling would start with just mentors on its PPMC. If you clearly knew what you were doing, you'd get voted onto the PPMC pretty quickly, and thus you'd be able to vote on your releases. Upayavira - 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
On Sun, Nov 17, 2013 at 1:32 PM, Upayavira u...@odoko.co.uk wrote: Benson, How does that relate to my post? Not sure if I can see the connection. I thought I was replying to Alex, but my sentiment is applicable to what you write below. The IPMC is a group of people with a job. It's not a 'project community' in the usual sense of the term at the Foundation. My view is that a person who has shown a firm grip on how to operate inside a PPMC could be trusted to join that group. I think it's possible to explain to a proposed IPMC member that they are being invited to join a group with responsibility across all the podlings, but with the understanding that they will stick to their podling to start with. The point of my email was to emphasize the low risk to the function of the IPMC and the Foundation from this strategy -- which I appreciate is not the only consideration. If the board were offering us another structural approach, this would be a different discussion. But, unless I've gotten lost in the torrent of email, the board isn't offering an alternative. The legal framework requires three PMC members to approve a release, not three 'something else's'. So I see this as a choice of the lesser of weevils: bug #1 is releases that never get their votes, and bug #2 is this scheme of adding IPMC members based on PPMC merit. So, yes, I accept your point that inviting PPMC members to join the IPMC is not delux. While I'm using my metered window of verbiage around here, I'll add: much as I value the careful curation of NOTICE and LICENSE, those aren't where the legal risks come in. They come in every day, when code is committed. If someone goes and commits some misappropriated code into SVN with Apache headers tacked on, the chances of a 'release inspector' detecting it are small. Once a project is up and running, this is a matter of appropriate grant of commit access and appropriate supervision by PMC members -- though it's not like we supply them with Black Duck. Are you suggesting that we should be okay voting PPMC members who are taking responsibility within their project into the Incubator PMC? To me, that would be equivalent to granting a new committer ASF membership while we're at it. Sure, it'll probably be alright, but best to offer someone something at a point when they have some appreciation of what they are joining, no? Upayavira On Sun, Nov 17, 2013, at 01:24 PM, Benson Margulies wrote: Joining a PMC does not meaning being handed even one of the keys to the launch console for a nuclear missile. Joining a PMC means accepting responsibility for the supervision of a project. We vote to add someone to a PMC when they have shown the necessary commitment and, well, common sense. Part of 'common sense' is knowing what you know and what you don't know. Not every PMC member needs to be prepared to wade into every swamp, just as not every committer is qualified to modify every class in the source code. We add committers when have evidence to justify trusting them to do the right thing (with the PMC as backstop supervision), and we add PMC members similarly, with the backstop of the rest of the PMC. On Sun, Nov 17, 2013 at 6:17 AM, Upayavira u...@odoko.co.uk wrote: On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: On 11/16/13 8:47 AM, Upayavira u...@odoko.co.uk wrote: Alex, I'm not sure I see the difference between a release auditor and an IPMC member. If someone is sufficiently clued up to audit a release, then they're surely ready to join the Incubator PMC. Am I missing something? To me, there is more responsibility in being on the IPMC, like reviewing proposals for new podlings and voting on their graduation and becoming a mentor. Personally, that's why I don't want to be on the IPMC, but I might be willing to help IP audit a podling's release. Just like some projects don't have all committers on the PMC, a Release Auditor is just someone who can do that specific task, and there is no need to vote them in if they are already on some other TLP PMC because any member of a TLP PMC supposedly knows how to do release auditing. My interest is in a lesser level of involvement, where someone has shown merit within their own PPMC and can get a binding vote there, but no-where else. That feels to me like a very useful intermediate step to have. I agree, except for the no-where else part. If you know how to check a RAT report and have an idea of what should be in the NOTICE files, you should be able to help out any other podling by reviewing their release and casting a binding vote so they can learn how to do that. I'd say that 3 IPMC members must vote to give a person Release Auditor status if they are not already on a TLP PMC. Consider this: I am an the Flex PMC but not the IPMC, but if I join the PPMC of some new podling, why shouldn't I be able to cast a binding vote for that podling's releases
Re: Cultivating Outstanding IP Stewards
A summarized agreement with this thread: The bottom line, I think, is that _someone_ has to provide the supervision that the board delegates to a PMC. The virtue of the 'demolish the incubator' proposal is that it makes that point absolutely clear. If there were no incubator, the board would need to see three people whom it could trust to form the initial core of the project. The board has reiterated that it wants the IPMC to manage the bootstrap to a state: a PMC that the board can delegate to. What's the fastest path to that state? If you look at it this way, then you could look at Mentors in a slightly different light. They have two critical jobs at the outset: (a) detailed IP supervision until members of the podling community know what to do, and (b) get the members of the podling community up to speed as fast as possible. (c) then becomes: get those people onto the IPMC. That's the only tool the incubator has from the board, so the incubator should just use it. Once (c) is accomplished, the podling doesn't necessarily graduate. It is prudent to continue with some IPMC supervision for a bit, to look out for various bears. One could hope that this schema is a near-complete solution to vote problems. The _first_ release benefits from mentors who signed up to be there and vote, and subsequent releases have votes from inside the group. - 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 Sun, Nov 10, 2013 at 10:34 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Unlikely to get at least Roy’s approval because release votes are expected to be a decision of the full committee, not any one member of it. +1: Much as some people here as in favor of dismantlement, and others would like to see some structure in between IPMC membership and nothing, the legal structure requires a release to be voted by PMC members. To mangle Pogo: We have met the PMC, and, friends, it is us. It is the job of the more seasoned IPMC members to provide the backstop for the folks like Alex. On Nov 10, 2013, at 10:29 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 10, 2013, at 1:04 AM, ant elder ant.el...@gmail.com wrote: How about simply changing the rules for Incubator releases so that they don't require at least three binding votes, but instead make it at least three votes only one of which must be binding. That would mean there would still be the element of oversight that a mentor vote gives but avoids all the problems with not having three mentors. I'm sure the board would grant the Incubator authority to implement that change. The board has charged us to vet the podlings and their releases. What process is used is up to us. I would prefer a variant of your proposal. The first release needs three mentor/IPMC votes. Subsequent releases only require one mentor/IPMC vote. Regards, Alan - 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: The podling initial committers issue
I think that all of this might boil down to the observation, way back in this thread, that there are different patterns of incoming projects. Some incoming podlings are very small groups of people. If they are paying attention, they know that attracting new people will be their biggest problem. Interested, enthusiastic, existing Apache committers/PMC members/foundation members are exactly what they want. They aren't a community yet, and starting out with a batch of people who have some idea how to run one is just fine. Other incoming podlings have an existing community. They are willing to work to adapt that community to Apache norms. We may not have observed them in their past, but it's reasonable to respect them to the extent of allowing them to set up shop as themselves and then bring in others via the usual process. Open Office was a special and unusual case on just about every dimension, so I don't think that it's necessary for every mental schema to perfectly fit that history. It seems to me that the cooler voices here, including particularly Bertrand, see this whole incident as an unfortunate misunderstanding over this distinction, and a tiny bit of policy clarification will fix it, with no further need for rhetoric. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] first milestone release of Apache Drill (incubating)
-1 binding. I don't see the standard disclaimer in any of the possible
locations.
In Maven, the standard disclaimer as a remote resource via
org.apache:apache-incubator-disclaimer-resource-bundle.
The text looks like:
#if(${projectName})${projectName}#else${project.name}#end is an effort
undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making process
have stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the completeness
or stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.
On Wed, Sep 18, 2013 at 6:24 AM, Grant Ingersoll gsing...@apache.org wrote:
+1, binding
On Sep 17, 2013, at 6:29 PM, Ted Dunning ted.dunn...@gmail.com wrote:
We've held a vote on drill-dev to release the first milestone release.
The vote thread can be found here:
http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
The vote passed with
4 x +1 binding votes
7 x +1 non-binding votes
An additional non-binding +1 vote was received after the vote closed.
A summary email can be found here:
http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
The source only release artifactscan be found together with signatures here:
http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
Please vote on this release
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] first milestone release of Apache Drill (incubating)
On Wed, Sep 18, 2013 at 11:42 AM, Ted Dunning ted.dunn...@gmail.com wrote:
Benson,
The disclaimer is in the README now:
Which is to say, README.md.
OK, I was too tired last night. -1 - +1.
README.md:Apache Drill is an effort undergoing incubation at The Apache
Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is
required of all newly accepted projects until a further review indicates
that the infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF projects. While
incubation status is not necessarily a reflection of the completeness or
stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.
Subsequent to the construction of this RC, a DISCLAIMER file has been
created that will appear in the next release.
Given that
* the disclaimer is actually there,
* this is a milestone release which should be supplanted by another release
in a month or two
and
* this will be fixed
Would you reconsider?
On Wed, Sep 18, 2013 at 4:39 AM, Benson Margulies
bimargul...@gmail.comwrote:
-1 binding. I don't see the standard disclaimer in any of the possible
locations.
In Maven, the standard disclaimer as a remote resource via
org.apache:apache-incubator-disclaimer-resource-bundle.
The text looks like:
#if(${projectName})${projectName}#else${project.name}#end is an effort
undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further
review
indicates that the infrastructure, communications, and decision making
process
have stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the completeness
or stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.
On Wed, Sep 18, 2013 at 6:24 AM, Grant Ingersoll gsing...@apache.org
wrote:
+1, binding
On Sep 17, 2013, at 6:29 PM, Ted Dunning ted.dunn...@gmail.com wrote:
We've held a vote on drill-dev to release the first milestone release.
The vote thread can be found here:
http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
The vote passed with
4 x +1 binding votes
7 x +1 non-binding votes
An additional non-binding +1 vote was received after the vote closed.
A summary email can be found here:
http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
The source only release artifactscan be found together with signatures
here:
http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
Please vote on this release
-
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] PodlingBillOfRights
A simple alternative is 'expectation'. However, I have no problem with using it the way Joe wrote it. On Tue, Jun 18, 2013 at 7:27 PM, Ross Gardler rgard...@opendirective.comwrote: I did read the topmatter, but I still felt it was a concern. It's not just about mentors, that was just one example of a potential problem. Specifically the document currently says podlings have a right to expect active participation and guidance from their mentors - I fully support this, but as Upayavira asks, what can the IPMC do if this is not the case and no other mentors step up? I agree with your statement in this thread that mentoring is a best-effort attempt based on volunteer availability not something we should commit to in a Bill of Rights. I am not suggesting we commit to anything. Quite the opposite, I'm concerned that as your document is currently written it can be read as being a commitment (even with the topmatter making this explicit). It's hard to resolve without making your whole document just a bunch of words on a page. Maybe the topmatter is enough. Maybe I'm being too cautious. Anyway, as I said, on balance I really like this, if someone smart can wordsmith it then great. If not lets adopt it anyway. Ross On 19 June 2013 00:13, Joe Schaefer joe_schae...@yahoo.com wrote: Did you read the topmatter disclaimer about the terminology? Anyway no podling has a guaranteed right to a sufficient number of mentors, that's why I didn't bother addressing Upayavira's concern. That is a best-effort attempt based on volunteer availability not something we should commit to in a Bill of Rights. - Original Message - From: Ross Gardler rgard...@opendirective.com To: general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Cc: Sent: Tuesday, June 18, 2013 7:09 PM Subject: Re: [DISCUSS] PodlingBillOfRights Joe, this is (in general) great. I feel I could pick a few holes and make a few suggestions but they are mostly insignificant so I'll refrain from doing so. I do have one concern I want to air. Unfortunately I don't have a suggestion for improvement so am happy for you to ignore it, but maybe someone else has a bright idea. My concern is the use of the word right. We are a volunteer organisation. Telling a podling they have a right to Foo and Bar might set the wrong tone. Upayavira appears to be thinking something similar (unless I'm misinterpreting him) when he asks: I guess a question that it would be worth clarifying - what happens to a perfectly reasonable podling who's mentors resign/go awol, when the Incubator PMC cannot recruit replacements? Can we make any promises at that point? Perhaps we can use a slightly softer word - perhaps I'm being too cautious. On 16 June 2013 15:16, Joe Schaefer joe_schae...@yahoo.com wrote: Since I realize that most of you can't be bothered to look at the wiki page I created ;-), I'll go ahead and post the current content here for commentary. I hope the bulk of it is non-controversial, though some of it may not belong on the page... First a clarification- as provisional constructs of the Incubator PMC, podlings have no official standing in the corporation known as The Apache Software Foundation. So technically, it is a farce to claim that podlings have any formal rights whatsoever. What we write about here are promises and covenants the Incubator PMC will make a good-faith effort to honor. 1. First, podlings have a right to expect active participation and guidance from their mentors. That minimally includes participation in release votes, discussions and votes on new personnel, and signing off on a podling's quarterly reports. 2. Mentoring is done solely for the podling's benefit, and as such podlings have the right to fire mentors for any reason by a majority consensus vote on their private list. Just don't be denigrating about it, since mentors are always volunteers and not paid staff. 3. Podlings who find themselves in need of additional mentors have the right to ask general@incubator for more mentors to volunteer. 4. Podlings have the right to expect their quarterly reports to be read, reviewed, and critiqued by shepherds on the Incubator PMC, who are typically outside the podling's set of mentors. 5. Podlings have the right to express private concerns about anything related to their incubation to the Incubator Ombudsman ombudsman@incubator, who will handle such communications as if they were sent anonymously. 6. Podlings have the right to express their opinions concerning their incubation efforts post-graduation (or post-mortem) in the form of an anonymous survey. 7. Podlings have the right to ignore commentary made on general@incubator in the middle of a VOTE thread,
Re: [PROPOSAL] Creation of the Incubator Ombudsman
A paradox: The VP is not supposed to exercise authority in normal circumstances. Projects are supposed to have mentors that advocate for them. If a project comes 'to the ombudsman', whether that's the VP or not, what can this person do? All they can do is bring the matter to the community. If it's sensitive enough, to private@. The mentors can and should be doing this. So, if you ask me, this is just another way to avoid the problem of mentor-shortage. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Change of Chair
Incubator community, I have tendered my resignation as VP, Incubator. The PMC has recommend Marvin Humphrey as my successor in a motion submitted to the Foundation board for consideration at the meeting next week. --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: June report
I'm off by a week. No buttoning until next week. On Fri, Jun 7, 2013 at 7:00 PM, Benson Margulies bimargul...@gmail.com wrote: I'll button it up in the middle of tomorrow some time. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
June report
I'll button it up in the middle of tomorrow some time. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Correct process for signing keys?
I think that the RM _must_ have a key, that the key must be part of a KEYS file in svn/git, and that it _should_ be uploaded into their Apache account, and it is more better if it is signed into the GWOT (global web of trust). - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling not Poddling
In fact, someone from Wales wants to rename them to be pronounced 'pothling'. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
How many people are supervising IP clearance?
A straw poll: how many people on this PMC scrutinized any of the recent three IP clearance transactions? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Possible focal point: decision-making
If you look at proposals and email, you will notice that several people who disagree on many things agree that this group has trouble making decisions by consensus, due to size, diversity, and perhaps sheer orneriness. One possibility is to focus on the ideas in Bertrand's document that address decision-making. If, perchance, we could somehow reach consensus on how to reach consensus, we could then move along to the other questions and with a higher probability of finding consensus on them. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANNOUNCE] Release Curator 2.0.0-incubating released
Also please remember that every release is supposed to go into the next month's board report. On Sun, May 12, 2013 at 10:53 AM, Alan Cabrera l...@toolazydogs.com wrote: Sebb you are awesome and correct. But I have to say, I think that when we make suggestions to podlings, we should make it clear that we are making suggestions and are not pointing out some ASF Incubator transgression. This is one such cases where Sebb us making a very useful suggestion. Again, Sebb you are awesome. Regards, Alan On May 11, 2013, at 1:00 AM, sebb seb...@gmail.com wrote: Congrats. However, what is Curator? The mail does not say anything about it. Please ensure that any announcement e-mails about Curator include a brief description of what it is. On 10 May 2013 17:47, Jordan Zimmerman randg...@apache.org wrote: Hello, The Apache Curator team is pleased to announce the release of version 2.0.0-incubating from the Apache Incubator. Curator was originally open sourced by Netflix via Github. This is the first Apache release of Curator. I'd like to thank the mentors for their help in getting to this milestone. In particular, Patrick Hunt and Luciano Resende have been incredibly helpful and patient. Link to release notes: https://issues.apache.org/jira/browse/CURATOR#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel The most recent source release can be obtained from an Apache Mirror: http://www.apache.org/dyn/closer.cgi/incubator/curator/ (mirror sync times may vary) The binary artifacts for Curator are available from Maven Central and its mirrors. For general information on Apache Curator, please visit the project website: http://curator.incubator.apache.org Disclaimer: Apache Curator is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. -Jordan - 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: [META DISCUSS] talking about the overall state of this PMC
I'm not going to ask the May board meeting anything. There's no consensus of this community on 'probationary projects', and, more to the point, there are a host of details required to make that a viable proposal and no one has filled them in. As I wrote in the report, I plan to have a discussion with the board in June if we aren't making progress. A real experiment with 'probationary projects' would have to model the entire process of a new project launching with _no IPMC_ to participate in any way. Taking a proposal that has been groomed and vetted at the IPMC and then launching the resulting project to the board is purely an experiment in board supervision. I'm not going to bring the board a proposal to increase their workload based on my personal judgement, and there's no consensus here, today, that it's a good idea, since there are several people who are eloquently opposed. My personal thought is this: new project creation is not a 'project', it's a function of the Foundation. If the committee currently constituted by the board to handle this isn't working well enough, and can't agree on what to do, it is an issue for the board to consider. The board could decide to keep what we are, arguments and all. It could constitute a small (and thus consensus-prone) committee to survey the terrain and make a recommendation. It could tell the whiney VP to JFDI -- make some decisions and get on with it. (Consensus is desirable, but read one of the board resolutions that installs a VP.) On Sat, May 11, 2013 at 2:39 AM, ant elder ant.el...@gmail.com wrote: On Fri, May 10, 2013 at 5:33 PM, Eric Johnson e...@tibco.com wrote: If this was a software project, and the appropriate answer was unknown, they you might apply a lean startup approach, and figure out how to run tests to see which way works best. Given the number of incubating projects, should be easy to run some experiments. Then you just need to build up some consensus on how to run the experiments. And how to evaluate the results. Essential to establish some metrics that will correlate with success. Then run the experiments for a while (three months, six months?). At the end, you'll have actual data that will inform a decision. Eric. +1 for experimenting with some new approaches. Several people have been in support of the board managed poddlings or probationary TLPs, lets try that. Ask at the board meeting next week if the board would support the experiment and if so just pick half a dozen existing poddlings to try it. ...ant - 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: [META DISCUSS] talking about the overall state of this PMC
Violating my 24 hour rule just this one, and worse yet to repeat myself: +1 Joe, Ross, etc. I rather regret mentioning the direct launch alternative in my most recent email. We have some weakness in _mentoring_, and more weakness in _supervising_ (or at least in documenting supervision). We have a few competing proposals for changes to address these, especially supervision weakness. I wish that I felt confident as Joe does that just electing more people from inside the projects was all we needed to do; maybe Alan's idea combined with that is the way to go. Recently we had a situation on private where I felt that there was a consensus to be had, but some people needed to be nudged a bit to allow it to emerge. That's not what I see here when considering the choices of using more or less of shepherds, champions, and mentors. One possible path is that, at some point, I as VP pick one. I plan to let this discussion continue for at least a week, if not more, before I remotely consider taking that step. I think it's clear, though, that _this committee_ does not believe in the 'direct-to-PMC' model, so anyone interested in that alternative should talk elsewhere and/or with the board, as per Ant's message. On Sat, May 11, 2013 at 12:25 PM, Alan Cabrera l...@toolazydogs.com wrote: On May 11, 2013, at 7:26 AM, ant elder ant.el...@gmail.com wrote: I also agree that there isn't consensus in the Incubator PMC to do this, but I'm not sure we need it. Lovely. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [META DISCUSS] talking about the overall state of this PMC
If you think it's clear in either direction, call a VOTE. I think that's the only demonstrable way to suggest what's clear and what's not. Please see several emails from Greg and others on the board@ list recently pointing out the inappropriateness of overuse of votes. If even *one* person strongly objects, there is no consensus. There is a strong handful of people who strongly object. So there's no consensus. This isn't a majority issue. I don't uniquely own the role of testing consensus. If you want to send a message that tests consensus on your proposal, or more accurately tests consensus on the idea of asking the board for permission to do a trial run of your proposal, go right ahead. I feel confident that it will attract enough firm -1 votes to demonstrate a lack of consensus in favor of the idea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [META DISCUSS] talking about the overall state of this PMC
Chris, As I feel like I've explained 100 times, all of the following are true: 1) I disagree with your proposal 2) I agree with much of your analyses of problems with the IPMC 3) I I trying to do a job of consensus moderation as best I understand how, being fair to you and to all the involuntary readers of all this. My 'sweeping statements' reflect my understanding. My invitation stands and is non-ironic. If you think that there is a consensus based on your understanding of appropriate Foundation process, test it. If you are right, off we go to ask the board to to try your plan. If you are wrong, we move on. Or, you go directly to the board to make your case that this group is too disfunctional to do the right thing. That's it for me for this weekend. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
May 2013 Report
I wrote some text at the front. I plan to fill in things like PMC members coming and going tomorrow morning, and commit to svn. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [META DISCUSS] talking about the overall state of this PMC
So, here we have: Alan's idea of removing champions and shepherds and demanding mentor recommitment, with the 'teeth' of putting podlings on ice if they can't muster an adequate mentor squad. My idea of asking champions to step up to some specific supervision responsibility, thus allowing some flexibility for some mentors to be more 'supervisory' than others. Ross' ideas about shepherds, Chris' proposal to push the self-destruct button. Does anyone have a suggestion for a decision procedure? I don't see, or foresee, a consensus for any of these. My draft board report says that if we don't find a way forward in time for the June board meeting, I propose to discuss the situation with the board. On Thu, May 9, 2013 at 3:34 AM, Ross Gardler rgard...@opendirective.com wrote: Sent from a mobile device, please excuse mistakes and brevity On 8 May 2013 02:20, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, May 8, 2013 at 10:47 AM, Ross Gardler rgard...@opendirective.com wrote: ...I've made a proposal for giving the IPMC teeth but it hasn't gained support.. URL? Sorry, working from mobile device while travelling. I proposed creating a board like structure and formalising shepherd role. Very similar to Chris' proposal but leaving overhead with IPMC rather than moving to board. ...In the absence of something else with teeth then I'm +1 for probationary TLPs as proposed by Chris as long as we stop accepting projects that are likely to run into problems according to our collective experience If you're able to find out that a podling will cause problems in the future, or that its mentors will become inactive, maybe I should hire you for this lottery betting club ;-) Hehe - fair comment. I was thinking, for example, of BlueSky - the archives show my concern that was ignored and ultimately shown to be right. A counter example is OpenMeetings who addressed my concerns, came back and graduated quickly and smoothly. I'm not suggesting its always possible to get it right, but I do think we can be more rigorous in general. Apart from that I agree that the board doesn't have cycles to handle problematic podlings or missing mentors, and as a result whatever actions it would take would be much harsher than what we do here. That's the more important point. Ross -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: May 2013 Report
On Fri, May 10, 2013 at 1:47 PM, Alan Cabrera l...@toolazydogs.com wrote: I think that you should make it clear that the Marvin machinery broke down and projects did not get their notifications. Didn't the last email on the subject contradict that idea? Regards, Alan On May 10, 2013, at 9:21 AM, Benson Margulies bimargul...@gmail.com wrote: I wrote some text at the front. I plan to fill in things like PMC members coming and going tomorrow morning, and commit to svn. - 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
