[DISCUSS] Syncope to Join the Apache Incubator
Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 1/31/12 3:06 AM, Joe Schaefer wrote: - Original Message - From: William A. Rowe Jr.wr...@rowe-clan.net To: general@incubator.apache.org Cc: Sent: Monday, January 30, 2012 9:01 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes On 1/30/2012 7:51 PM, Joe Schaefer wrote: - Original Message - From: William A. Rowe Jr.wr...@rowe-clan.net To: general@incubator.apache.org Cc: Sent: Monday, January 30, 2012 8:47 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes On 1/30/2012 7:44 PM, Dave Fisher wrote: Sent from my iPhone On Jan 30, 2012, at 5:34 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/30/2012 6:06 PM, Joe Schaefer wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. -1 The argument is very simple, you don't allow a simple majority to tyrannize the minority. So the ASF has long held a simple standard of consensus on all committee additions and subtractions. Some majority might be irked at [insert name here]'s [actions|inaction| comments|silence] but that was never grounds to remove a committee member. If you want to propose some supermajority metric other than unanimous, that could work (e.g. 2/3 or 3/4 in agreement In your plan then a -1 is really a -2 or -3? Sounds like a filibuster... No, I'm -1 to this proposal. I'd support his proposal if it were modified to provide for a measurable super-majority consensus. Define supermajority in a way that isn't patently absurd and perhaps I'll consider amending it. 2/3. 3/4. Take your pick. I'd argue on the high end. Consider that to defeat a 3/4 supermajority consisting of 9 votes requires more than 2 people against. This committee has an order of magnitude more voters. Simple obstructionism is easy to deal with. Oh, so you want a supermajority in terms of those who have voted, not in terms of the membership of the IPMC? Not unreasonable. Let's see what others think. I would easily +1 a proposal with a 3/4 majority of the *voters*. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release MRUnit version 0.8.0-incubating
I missed antelders +1 vote and only noticed this today via this link: http://old.nabble.com/-VOTE--Release-MRUnit-version-0.8.0-incubating-td33113645.html As such, the vote passes with: 4 +1 Patrick Hunt, Chrs M, antelder, Brock Noland 0 -1 Patrick Hunt, Chrs M, antelder are all members of the IPMC Cheers, Brock On Tue, Jan 24, 2012 at 2:04 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Jan 24, 2012 at 11:28 AM, Brock Noland br...@cloudera.com wrote: Hi, On Mon, Jan 23, 2012 at 3:36 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: OK, I switch my VOTE to +1. The update worked perfectly: Great! We only need one more +1 from an IPMC member. Is there a list somewhere? I bothered Tom White last time so I'd prefer to bother someone else. Aside from Chris and myself Nigel Daley is listed as a mentor. Best to check in with him. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 31 January 2012 00:06, Joe Schaefer joe_schae...@yahoo.com wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. I intend to offer a policy vote on this issue over the coming days and that vote, as with all procedural votes, is NOT subject to veto. +1 - it has always been my understanding that only code can be vetoed. Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
Hi Simo! Sounds like a really nice project. But I wonder if there is some overlap with the Apache Shiro project [1]? LieGrue, strub [1] http://shiro.apache.org/ - Original Message - From: Simone Tripodi simonetrip...@apache.org To: general@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 10:14 AM Subject: [DISCUSS] Syncope to Join the Apache Incubator Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 10:43 AM, Ross Gardler rgard...@opendirective.com wrote: On 31 January 2012 00:06, Joe Schaefer joe_schae...@yahoo.com wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. I intend to offer a policy vote on this issue over the coming days and that vote, as with all procedural votes, is NOT subject to veto. +1 - it has always been my understanding that only code can be vetoed. This was my understanding as well. +1 to making it so. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 31/01/2012 11:08, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Hi Mark, first of all, thanks. But I wonder if there is some overlap with the Apache Shiro project [1]? [1] http://shiro.apache.org/ Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. - this means that Shiro is an Access Manager. Identity Manager's duties are about managing virtual user lifecycle, possible spread across multiple heterogeneous systems. This would involve: creating / updating / deleting /moving user credentials and attributes via LDAP / Active Directory / RDMS and so on. An Identity Manager - like Syncope - is usually working together with an Access Manager in order to provide a complete IAM (=Identity and Access Management) solution. Syncope does not provide yet a connector for interoperating with Shiro, but this looks like a nice feature to put somewhere in the roadmap. Regards. - Original Message - From: Simone Tripodi simonetrip...@apache.org To: general@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 10:14 AM Subject: [DISCUSS] Syncope to Join the Apache Incubator Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 10:43 AM, Ross Gardler rgard...@opendirective.com wrote: On 31 January 2012 00:06, Joe Schaefer joe_schae...@yahoo.com wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. I intend to offer a policy vote on this issue over the coming days and that vote, as with all procedural votes, is NOT subject to veto. +1 - it has always been my understanding that only code can be vetoed. +1, I thought that as well. Cheers Christian Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 1/31/12 11:08 AM, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Sounds nice, yes. But I wonder if there is some overlap with the Apache Shiro project [1]? IMO, Syncope spectra is wider than Shiro. Actually, Syncope *could* use Shiro. I have a Q : Can't it be a bit larger than just JEE based ? Many would like a solution which extends to tomcat only... +1 for the proposal otherwise, I can help mentoring the project to some extent. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
Hi Francesco and Simo, it looks interesting. As an Identity Manager, I wonder if we can't extend it to OSGi, in addition of JEE. Regards JB On 01/31/2012 11:17 AM, Francesco Chicchiriccò wrote: On 31/01/2012 11:08, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Hi Mark, first of all, thanks. But I wonder if there is some overlap with the Apache Shiro project [1]? [1] http://shiro.apache.org/ Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. - this means that Shiro is an Access Manager. Identity Manager's duties are about managing virtual user lifecycle, possible spread across multiple heterogeneous systems. This would involve: creating / updating / deleting /moving user credentials and attributes via LDAP / Active Directory / RDMS and so on. An Identity Manager - like Syncope - is usually working together with an Access Manager in order to provide a complete IAM (=Identity and Access Management) solution. Syncope does not provide yet a connector for interoperating with Shiro, but this looks like a nice feature to put somewhere in the roadmap. Regards. - Original Message - From: Simone Tripodisimonetrip...@apache.org To: general@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 10:14 AM Subject: [DISCUSS] Syncope to Join the Apache Incubator Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [DISCUSS] Syncope to Join the Apache Incubator
On 31/01/2012 11:31, Emmanuel Lecharny wrote: On 1/31/12 11:08 AM, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Sounds nice, yes. But I wonder if there is some overlap with the Apache Shiro project [1]? IMO, Syncope spectra is wider than Shiro. Actually, Syncope *could* use Shiro. Correct. I have a Q : Can't it be a bit larger than just JEE based ? Many would like a solution which extends to tomcat only... Syncope officially supports Apache Tomcat 7 as first option [1], Glassfish 3.1.1 (recently, on trunk) [2] and JBoss 7 (ongoing work, on trunk) [3]. +1 for the proposal otherwise, I can help mentoring the project to some extent. Does this mean that we can put your name on the proposal? ;-) Regards. [1] http://wiki.syncope-idm.org/index.php?title=GettingStarted/RunDeployment#Apache_Tomcat_7 [2] http://blog.tirasa.net/blogs/index.php/ilgrosso/openjpa-2-2-0-and [3] http://code.google.com/p/syncope/issues/detail?id=239 -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Syncope to Join the Apache Incubator
Salut Jean-Baptiste, why not? :) Feel free to add yourself in the proposal if you like it!!! :) A trés bientot, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Jan 31, 2012 at 11:34 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Francesco and Simo, it looks interesting. As an Identity Manager, I wonder if we can't extend it to OSGi, in addition of JEE. Regards JB On 01/31/2012 11:17 AM, Francesco Chicchiriccò wrote: On 31/01/2012 11:08, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Hi Mark, first of all, thanks. But I wonder if there is some overlap with the Apache Shiro project [1]? [1] http://shiro.apache.org/ Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. - this means that Shiro is an Access Manager. Identity Manager's duties are about managing virtual user lifecycle, possible spread across multiple heterogeneous systems. This would involve: creating / updating / deleting /moving user credentials and attributes via LDAP / Active Directory / RDMS and so on. An Identity Manager - like Syncope - is usually working together with an Access Manager in order to provide a complete IAM (=Identity and Access Management) solution. Syncope does not provide yet a connector for interoperating with Shiro, but this looks like a nice feature to put somewhere in the roadmap. Regards. - Original Message - From: Simone Tripodisimonetrip...@apache.org To: general@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 10:14 AM Subject: [DISCUSS] Syncope to Join the Apache Incubator Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 31/01/2012 11:34, Jean-Baptiste Onofré wrote: Hi Francesco and Simo, it looks interesting. As an Identity Manager, I wonder if we can't extend it to OSGi, in addition of JEE. Hi, I must admit that I am not very deep in OSGi stuff, but there shouldn't be nothing against making Syncope core work in - say ;-) - Karaf, due to its dependencies (see the proposal for more details). We will need an OSGi helping hand for this, of course... Regards. On 01/31/2012 11:17 AM, Francesco Chicchiriccò wrote: On 31/01/2012 11:08, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Hi Mark, first of all, thanks. But I wonder if there is some overlap with the Apache Shiro project [1]? [1] http://shiro.apache.org/ Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. - this means that Shiro is an Access Manager. Identity Manager's duties are about managing virtual user lifecycle, possible spread across multiple heterogeneous systems. This would involve: creating / updating / deleting /moving user credentials and attributes via LDAP / Active Directory / RDMS and so on. An Identity Manager - like Syncope - is usually working together with an Access Manager in order to provide a complete IAM (=Identity and Access Management) solution. Syncope does not provide yet a connector for interoperating with Shiro, but this looks like a nice feature to put somewhere in the roadmap. Regards. - Original Message - From: Simone Tripodisimonetrip...@apache.org To: general@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 10:14 AM Subject: [DISCUSS] Syncope to Join the Apache Incubator Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On 1/31/12 11:44 AM, Francesco Chicchiriccò wrote: On 31/01/2012 11:31, Emmanuel Lecharny wrote: On 1/31/12 11:08 AM, Mark Struberg wrote: Hi Simo! Sounds like a really nice project. Sounds nice, yes. But I wonder if there is some overlap with the Apache Shiro project [1]? IMO, Syncope spectra is wider than Shiro. Actually, Syncope *could* use Shiro. Correct. I have a Q : Can't it be a bit larger than just JEE based ? Many would like a solution which extends to tomcat only... Syncope officially supports Apache Tomcat 7 as first option [1], Glassfish 3.1.1 (recently, on trunk) [2] and JBoss 7 (ongoing work, on trunk) [3]. +1 for the proposal otherwise, I can help mentoring the project to some extent. Does this mean that we can put your name on the proposal? ;-) Sure. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q: including notice for binary release of artifacts that are brought in via Maven?
Hi, On Tue, Jan 31, 2012 at 2:49 AM, Jakob Homan jgho...@gmail.com wrote: Great, thanks. Using this method, I get a file layout similar to: giraph-0.1-SNAPSHOT-bin.tar.gz NOTICE (without appended text for dep1 and dep2) LICENSE (without appended text for dep1 and dep2) bin/ lib/ dep1.jar dep2.jar giraph.jar META-INF/ NOTICE (with appended text for dep1 and dep2) LICENSE (with appended text for dep1 and dep2) This matches with what I see when I checkout the jackrabbit-standalone code and do a package command from maven there. I just want to verify that this will past muster with incubator. This configuration satisfies the requirement for those notices/licenses to be included? The general idea is that the NOTICE/LICENSE pair of an artifact should cover all the bits included inside that artifact. If giraph.jar doesn't embed dep1 and dep2, then there's no need to mention them in the NOTICE/LICENSE pair of that jar. Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. If you look inside the jackrabbit-standalone jar, you'll notice that it actually contains all the external components mentioned in the NOTICE/LICENSE files. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q: including notice for binary release of artifacts that are brought in via Maven?
On 31 January 2012 11:07, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 2:49 AM, Jakob Homan jgho...@gmail.com wrote: Great, thanks. Using this method, I get a file layout similar to: giraph-0.1-SNAPSHOT-bin.tar.gz NOTICE (without appended text for dep1 and dep2) LICENSE (without appended text for dep1 and dep2) bin/ lib/ dep1.jar dep2.jar giraph.jar META-INF/ NOTICE (with appended text for dep1 and dep2) LICENSE (with appended text for dep1 and dep2) This matches with what I see when I checkout the jackrabbit-standalone code and do a package command from maven there. I just want to verify that this will past muster with incubator. This configuration satisfies the requirement for those notices/licenses to be included? The general idea is that the NOTICE/LICENSE pair of an artifact should cover all the bits included inside that artifact. Also the idea is that the NL (and Disclaimer, Readme if any) are at the top-level of the artifact. The only exception to this is that NL files are added to a jar META-INF directory instead (as that is the convention for jars) . Having the files in a standard place is intended to make it easy for the consumer to find the files. The NL files are important for the consumer; they should not have to go looking for them. If giraph.jar doesn't embed dep1 and dep2, then there's no need to mention them in the NOTICE/LICENSE pair of that jar. Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. If you look inside the jackrabbit-standalone jar, you'll notice that it actually contains all the external components mentioned in the NOTICE/LICENSE files. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] PhoneGap for Apache Incubator
On 10/7/11 10:11 PM, Gianugo Rabellino wrote: On Fri, Oct 7, 2011 at 2:49 AM, Christian Grobmeiergrobme...@gmail.com wrote: Any more questions/comments about this proposal? If not, I suggest we start the vote tomorrow. I think we're good. The one thing I'd like to do is asking to add another committer to the roster. Abu Obeida Bakhach abu.obe...@microsoft.com has been following the WP7 part of Phonegap and would be happy to continue helping out at least on that front. As he was a Stonehenge committer, he should already have a CLA on file and an Apache ID. Obeida works in my team and I already checked with him - he'd be eager to help. Can I just go ahead and edit the proposal? Yes, please go ahead. Thanks - on the same line Obeida pointed out how Sergey Grebnov has been doing the bulk of the actual work, and I took the libery (after checking with Sergey) to add him to the roster. Has PhoneGap proposal totally stalled ? Or did I miss the Vote thread ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] PhoneGap for Apache Incubator
On 10/7/11 10:11 PM, Gianugo Rabellino wrote: On Fri, Oct 7, 2011 at 2:49 AM, Christian Grobmeiergrobme...@gmail.com wrote: Any more questions/comments about this proposal? If not, I suggest we start the vote tomorrow. I think we're good. The one thing I'd like to do is asking to add another committer to the roster. Abu Obeida Bakhach abu.obe...@microsoft.com has been following the WP7 part of Phonegap and would be happy to continue helping out at least on that front. As he was a Stonehenge committer, he should already have a CLA on file and an Apache ID. Obeida works in my team and I already checked with him - he'd be eager to help. Can I just go ahead and edit the proposal? Yes, please go ahead. Thanks - on the same line Obeida pointed out how Sergey Grebnov has been doing the bulk of the actual work, and I took the libery (after checking with Sergey) to add him to the roster. Forget about my last mail. I missed the rename to Callback... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Hi Guys, On Jan 31, 2012, at 1:17 AM, Emmanuel Lecharny wrote: Oh, so you want a supermajority in terms of those who have voted, not in terms of the membership of the IPMC? Not unreasonable. Let's see what others think. I would easily +1 a proposal with a 3/4 majority of the *voters*. +1 I'm fine with this compromise. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Questions for projects
On 01/30/2012 11:32 AM, Jukka Zitting wrote: Hi, The deadline for podlings to submit their February reports is already in two days since the ASF board meeting is scheduled for Feb 15th. I spent a few moments reviewing the November reports and related information of all the projects scheduled to report in February (excluding new projects on monthly schedule). Here are a few questions or comments for each project. Hopefully they're helpful in focusing the February reports on key issues. Did I miss the reminder? Or is it not working? Droids Any progress on getting more people to contribute? I'm seeing a significant drop in list activity since December. What's up? No progress at the moment. We need to evaluate those that have contributed patches to bring in new blood. I don't know the cause for drop in last activity. I think it just needs a reboot after the holidays. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 1/30/2012 6:06 PM, Joe Schaefer wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. I intend to offer a policy vote on this issue over the coming days and that vote, as with all procedural votes, is NOT subject to veto. Just FTR; as a proposal to modify a policy/process which requires consensus today, your eventual [VOTE] does require consensus to be adopted. You can't do an end run around the current policy with a simple majority. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Hi, On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Any other rational opinions? I don't recall a case where a candidate was not elected because of an unnecessarily strict -1. All I'm seeing now is abstract discussion about hypothetical votes and a lot of hot air. I'd go for a policy vote only once there's a concrete case (i.e. a failed vote) where progress is being obstructed by reasons that the majority finds unreasonable. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 11:58, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Guys, On Jan 31, 2012, at 1:17 AM, Emmanuel Lecharny wrote: Oh, so you want a supermajority in terms of those who have voted, not in terms of the membership of the IPMC? Not unreasonable. Let's see what others think. I would easily +1 a proposal with a 3/4 majority of the *voters*. +1 I'm fine with this compromise. I'm a little unclear on wrowe's original message talking about supermajority and whether that was for *addition* or for *removal*. I'm assuming that it was only about addition because I've never seen any PMC-based ejection of a PMC member. The Board has wiped out PMC rosters before, but I really don't foresee any need to discuss (here) rules around removal. So we're only talking about addition. Please remember that these are *recommendations* to the Board. In effect, there is really no such thing as a veto, except that a Chair may simply refuse to send a request to the Board for the addition when a -1 appears. (and note the Board could do an end-around anyways and simply put that person on the PMC regardless of the vote/Chair(!)) In that light, we're talking about what kinds of voting results should be forwarded by the Chair? If the Chair sends a request to the Board to add somebody and reports 5 +1 votes, 2 -1 votes... would that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board is going to investigate the consensus and what is going on behind those negative votes. Shoot. If the Chair doesn't forward that result, somebody else could forward it with hey. we think $JOHN should be on the PMC, but the Chair isn't forwarding cuz of these negative votes. Bang. Again, an inspection results. I think the short answer gets back to Joe's suggestion (and my concurrence): simply allow for a majority vote; forward that to the Board; let them decide. Keep it simple. Rules don't matter much when you're talking about forwarding recommendations to the Board. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] PhoneGap for Apache Incubator
Hi, On Tue, Jan 31, 2012 at 5:34 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Forget about my last mail. I missed the rename to Callback... No worries, the project has been quick to change names. :-) Hopefully Cordova will stand the test of time. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
- Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: general@incubator.apache.org Cc: Joe Schaefer joe_schae...@yahoo.com Sent: Tuesday, January 31, 2012 12:11 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes On 1/30/2012 6:06 PM, Joe Schaefer wrote: It is clear that with all the turmoil of late and people lightly tossing around -1's that the notion of having veto authority over personnel matters makes little sense on this PMC. Therefore I propose we adopt the policy that personnel votes are by straight majority consensus, iow no vetoes allowed. I intend to offer a policy vote on this issue over the coming days and that vote, as with all procedural votes, is NOT subject to veto. Just FTR; as a proposal to modify a policy/process which requires consensus today, your eventual [VOTE] does require consensus to be adopted. You can't do an end run around the current policy with a simple majority. Plainly wrong: It has been repeatedly established (even by the Chair) that policy decisions here are not subject to veto. This is one of those times. Furthermore the documentation [1] clearly points out that procedural issues are to be decided by majority consensus, and nothing could be more procedural than a vote about how to count votes. [1] http://www.apache.org/foundation/voting.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
There are currently 29 outstanding no votes made on a discussion thread merely for the fact that those candidates names were listed. Are you not reading private@incubator? There is currently a -1 on a current vote thread there as well. - Original Message - From: Jukka Zitting jukka.zitt...@gmail.com To: general general@incubator.apache.org Cc: Sent: Tuesday, January 31, 2012 12:18 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes Hi, On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Any other rational opinions? I don't recall a case where a candidate was not elected because of an unnecessarily strict -1. All I'm seeing now is abstract discussion about hypothetical votes and a lot of hot air. I'd go for a policy vote only once there's a concrete case (i.e. a failed vote) where progress is being obstructed by reasons that the majority finds unreasonable. BR, Jukka Zitting - 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] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 12:18, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Any other rational opinions? I don't recall a case where a candidate was not elected because of an unnecessarily strict -1. All I'm seeing now is abstract discussion about hypothetical votes and a lot of hot air. I'd go for a policy vote only once there's a concrete case (i.e. a failed vote) where progress is being obstructed by reasons that the majority finds unreasonable. Unfortunately, that is usually a poor approach. One person needs to raise the policy change request, and that invariably ends up looking like one person who is upset with the result. That person will either stay quiet, or may be alienated by their request. I think it is always best to settle these things *before* putting somebody in the position of having to be the Bad Guy and (apparently) question/attack a vote result. I think this has been a very useful discussion. I've already seen some emails (a couple private) of people surprised that a PMC nomination could even be vetoed. That Joe's suggestion is an actual change from what they expected. Thus... we have some good clarification on precedent, what may be good practice, and what (specifically) the IPMC may want to do. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Closed] (PODLINGNAMESEARCH-4) Establish Whether Apache Creadur would be a Suitable Name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin closed PODLINGNAMESEARCH-4. - Resolution: Fixed There is little evidence that Creadur is widely used for software. Consensus has been reached that Creadur would be a suitable name for an Apache TLP. Establish Whether Apache Creadur would be a Suitable Name --- Key: PODLINGNAMESEARCH-4 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-4 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: Robert Burrell Donkin Creadur means Creature in Welsh. My grandmother was a native Welsh speaker but I have very little. As far I know, Creadur has no immoral or scandalous meanings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Closed] (PODLINGNAMESEARCH-1) Establish whether Apache Rat is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Burrell Donkin closed PODLINGNAMESEARCH-1. - Resolution: Fixed The consensus reached is that though Apache Rat is a suitable name for an product, a good top level project would be more unique name. After discussions with the wider incubator community, the Rat community aspires to become a home for a suite of related products developed in any language. The community prefers to retain Rat as the name for the original product and adopt more unique top level project name after graduation. Establish whether Apache Rat is a suitable name - Key: PODLINGNAMESEARCH-1 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-1 Project: Podling Suitable Names Search Issue Type: Suitable Name Search Reporter: Robert Burrell Donkin The Rat podling brought together aRat and the Rat plugin tooling aRat for maven. It now is a suite of small products including rat, whisker, tentacles and eye which perform various functions to assist auditing, comprehending and verifying releases. This podling hopes to graduate as a top level project once a suitable top level project name is found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 1/31/2012 11:38 AM, Joe Schaefer wrote: Plainly wrong: It has been repeatedly established (even by the Chair) that policy decisions here are not subject to veto. This is one of those times. Furthermore the documentation [1] clearly points out that procedural issues are to be decided by majority consensus, and nothing could be more procedural than a vote about how to count votes. [1] http://www.apache.org/foundation/voting.html You assert this is simply policy. I assert that this is a fundamental to project bylaws, much like we don't fork (if we don't), or all votes require 3 +1's. You change such things only by consensus or by board mandate. Greg just finished explaining that only the chair can submit any changes to the PMC. Try changing that with a simple majority vote. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 1/31/2012 11:12 AM, Greg Stein wrote: I'm a little unclear on wrowe's original message talking about supermajority and whether that was for *addition* or for *removal*. I'm assuming that it was only about addition because I've never seen any PMC-based ejection of a PMC member. The Board has wiped out PMC rosters before, but I really don't foresee any need to discuss (here) rules around removal. So we're only talking about addition. Talk about what you want. The subject line was clearly inclusive of all. Please remember that these are *recommendations* to the Board. In effect, there is really no such thing as a veto, except that a Chair may simply refuse to send a request to the Board for the addition when a -1 appears. (and note the Board could do an end-around anyways and simply put that person on the PMC regardless of the vote/Chair(!)) Right right... this is only binding on committee recommendation which is then subject to the decision of the chair which is then subject to the decisions of the board, yadda yadda. In that light, we're talking about what kinds of voting results should be forwarded by the Chair? If the Chair sends a request to the Board to add somebody and reports 5 +1 votes, 2 -1 votes... would that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board is going to investigate the consensus and what is going on behind those negative votes. Shoot. If the Chair doesn't forward that result, somebody else could forward it with hey. we think $JOHN should be on the PMC, but the Chair isn't forwarding cuz of these negative votes. Bang. Again, an inspection results. Good points. I think the short answer gets back to Joe's suggestion (and my concurrence): simply allow for a majority vote; forward that to the Board; let them decide. Keep it simple. Rules don't matter much when you're talking about forwarding recommendations to the Board. Ok, let's keep it concensus, if you want to keep it anything. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q: including notice for binary release of artifacts that are brought in via Maven?
Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. This is the case for Giraph (and Kafka and other projects that bring in transitive dependencies into the tar.gz via maven), so the jackrabbit approach won't work. Which puts me back at my original question: how to include NL for the binary distribution without having to re-create it on the release branch each time. I'll take a look at Whisker, but for now it seems like one just needs to have a release-specific NL for the binary artifact? -jg On Tue, Jan 31, 2012 at 6:05 AM, sebb seb...@gmail.com wrote: On 31 January 2012 11:07, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 2:49 AM, Jakob Homan jgho...@gmail.com wrote: Great, thanks. Using this method, I get a file layout similar to: giraph-0.1-SNAPSHOT-bin.tar.gz NOTICE (without appended text for dep1 and dep2) LICENSE (without appended text for dep1 and dep2) bin/ lib/ dep1.jar dep2.jar giraph.jar META-INF/ NOTICE (with appended text for dep1 and dep2) LICENSE (with appended text for dep1 and dep2) This matches with what I see when I checkout the jackrabbit-standalone code and do a package command from maven there. I just want to verify that this will past muster with incubator. This configuration satisfies the requirement for those notices/licenses to be included? The general idea is that the NOTICE/LICENSE pair of an artifact should cover all the bits included inside that artifact. Also the idea is that the NL (and Disclaimer, Readme if any) are at the top-level of the artifact. The only exception to this is that NL files are added to a jar META-INF directory instead (as that is the convention for jars) . Having the files in a standard place is intended to make it easy for the consumer to find the files. The NL files are important for the consumer; they should not have to go looking for them. If giraph.jar doesn't embed dep1 and dep2, then there's no need to mention them in the NOTICE/LICENSE pair of that jar. Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. If you look inside the jackrabbit-standalone jar, you'll notice that it actually contains all the external components mentioned in the NOTICE/LICENSE files. BR, Jukka Zitting - 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] eliminate vetoes on personnel votes
- Original Message - From: William A. Rowe Jr. wr...@rowe-clan.net To: Joe Schaefer joe_schae...@yahoo.com Cc: general@incubator.apache.org general@incubator.apache.org Sent: Tuesday, January 31, 2012 1:12 PM Subject: Re: [DISCUSS] eliminate vetoes on personnel votes On 1/31/2012 11:38 AM, Joe Schaefer wrote: Plainly wrong: It has been repeatedly established (even by the Chair) that policy decisions here are not subject to veto. This is one of those times. Furthermore the documentation [1] clearly points out that procedural issues are to be decided by majority consensus, and nothing could be more procedural than a vote about how to count votes. [1] http://www.apache.org/foundation/voting.html You assert this is simply policy. I assert that this is a fundamental to project bylaws, much like we don't fork (if we don't), or all votes require 3 +1's. You change such things only by consensus or by board mandate. You can assert whatever you want Bill, it has no impact on the situation at hand. People here weren't even aware of the right you seem to have taken upon, but I'm here to tell you it's a privilege- one that can be taken away by your peers should they agree that it's being abused. Greg just finished explaining that only the chair can submit any changes to the PMC. Try changing that with a simple majority vote. Relevance being that I am not empowered to make board-level decisions? BFD, never claimed the contrary. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Questions for projects
On Mon, Jan 30, 2012 at 9:32 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, The deadline for podlings to submit their February reports is already in two days since the ASF board meeting is scheduled for Feb 15th. Sure, but there isn't even a February page at the wiki : http://wiki.apache.org/incubator/ Should one just copy from Feb 2011 ? Or is there some template that I missed ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 5:18 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 1:06 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Any other rational opinions? I don't recall a case where a candidate was not elected because of an unnecessarily strict -1. All I'm seeing now is abstract discussion about hypothetical votes and a lot of hot air. I'd go for a policy vote only once there's a concrete case (i.e. a failed vote) where progress is being obstructed by reasons that the majority finds unreasonable. BR, Jukka Zitting +1 to that. I'd really like this flood of emails to stop, i've not read many since last week, can't you all take a break? If some policy is being changed can't it wait a few weeks till a quieter time so it really getting the proper attention of PMC members? ...ant ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Greg Stein wrote on Tue, Jan 31, 2012 at 12:12:50 -0500: In that light, we're talking about what kinds of voting results should be forwarded by the Chair? If the Chair sends a request to the Board to add somebody and reports 5 +1 votes, 2 -1 votes... would that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board is going to investigate the consensus and what is going on behind those negative votes. Investigate? Isn't it going to tell the PMC to decide whether or not they are recommending the addition of the person? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Questions for projects
Hi Luciano, The February page is here: http://wiki.apache.org/incubator/February2012 Best, Daniel On 31 January 2012 19:17, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Jan 30, 2012 at 9:32 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, The deadline for podlings to submit their February reports is already in two days since the ASF board meeting is scheduled for Feb 15th. Sure, but there isn't even a February page at the wiki : http://wiki.apache.org/incubator/ Should one just copy from Feb 2011 ? Or is there some template that I missed ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Questions for projects
On 31 Jan 2012, at 18:17, Luciano Resende wrote: On Mon, Jan 30, 2012 at 9:32 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, The deadline for podlings to submit their February reports is already in two days since the ASF board meeting is scheduled for Feb 15th. Sure, but there isn't even a February page at the wiki : http://wiki.apache.org/incubator/ Should one just copy from Feb 2011 ? Or is there some template that I missed ? Its there, it just hasn't got a link from the front page: http://wiki.apache.org/incubator/February2012 -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 13:20, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Tue, Jan 31, 2012 at 12:12:50 -0500: In that light, we're talking about what kinds of voting results should be forwarded by the Chair? If the Chair sends a request to the Board to add somebody and reports 5 +1 votes, 2 -1 votes... would that be sufficient? 2/3rds or 3/4ths doesn't really matter. The Board is going to investigate the consensus and what is going on behind those negative votes. Investigate? Isn't it going to tell the PMC to decide whether or not they are recommending the addition of the person? Typically, when there are negative votes, the Board will try to figure out what is going on. The PMC (obviously) has not made up its mind as a whole. The votes may be normal, everyday concerns against membership, but it can signal more than that. To put it another way: votes that reach the Board are typically unanimous. Thus, if a vote is *not* unanimous, something funny is going on and should be looked at. If you have a jackass blocking nominations, then the Board will ACK the addition. If there are real concerns, then the Board will hold up. [something like that; obviously, I don't speak for the entire Board; I'm offering my predictions of behavior based on my own vote, and what I believe the other Directors would do] Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Hi, On Tue, Jan 31, 2012 at 6:43 PM, Joe Schaefer joe_schae...@yahoo.com wrote: There are currently 29 outstanding no votes made on a discussion thread merely for the fact that those candidates names were listed. I count those as votes once I see them in an actual VOTE thread. We've had similar VOTEs earlier, the last one passing just a few days ago, and I haven't seen a -1 on them so I don't see much of a problem yet. There is currently a -1 on a current vote thread there as well. Indeed there is! I stand corrected. Sorry for missing that one. Assuming that vote indeed fails, the case for re-evaluating policy gets much stronger. I'd question though, is it then better to change the voting rules, or rather to clarify the responsibilities expected of IPMC members? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On 01/30/2012 05:12 PM, Greg Stein wrote: I've never liked vetoes for this. One person can hold an entire PMC hostage simply for disliking someone (or worse: subtle corporate concerns masked otherwise). People have said in the past, you should have veto so you're not forced to work with somebody you dislike. I respond, grow up. we work with annoying people all the time, and the majority says they *can* work When this question came up in another context, Roy's concern, as I recall it, was something to the effect that if you don't allow vetoes of proposed PMC members then you might create a dysfunctional PMC. (Roy, please correct me if I miss-recall.) A PMC needs to regularly reach consensus. If person X has technical ideas that are incompatible with person Y then perhaps they should not be on the same PMC. At least that's the way I recall Roy's argument... Also note that if you get to the point where one person is vetoing a PMC addition then the rest of the PMC could vote to remove that one person. A veto is effectively asking the PMC to choose between you and the new person, a strident move. A less confrontational approach is to have a discussion before any vote, where folks can air their concerns. If folks voice significant concerns then it might not be wise to hold a vote. Finally I'll observe that if supermajority would result in a different result than consensus then the PMC probably has serious problems collaborating that need to be fixed. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On Tue, Jan 31, 2012 at 9:52 PM, Doug Cutting cutt...@apache.org wrote: On 01/30/2012 05:12 PM, Greg Stein wrote: I've never liked vetoes for this. One person can hold an entire PMC hostage simply for disliking someone (or worse: subtle corporate concerns masked otherwise). People have said in the past, you should have veto so you're not forced to work with somebody you dislike. I respond, grow up. we work with annoying people all the time, and the majority says they *can* work When this question came up in another context, Roy's concern, as I recall it, was something to the effect that if you don't allow vetoes of proposed PMC members then you might create a dysfunctional PMC. Interesting. Reading this I think joining a pmc on request is not good and adding people to a pmc just they can have binding votes is not good aswell. (Roy, please correct me if I miss-recall.) A PMC needs to regularly reach consensus. If person X has technical ideas that are incompatible with person Y then perhaps they should not be on the same PMC. At least that's the way I recall Roy's argument... Also note that if you get to the point where one person is vetoing a PMC addition then the rest of the PMC could vote to remove that one person. A veto is effectively asking the PMC to choose between you and the new person, a strident move. A less confrontational approach is to have a discussion before any vote, where folks can air their concerns. If folks voice significant concerns then it might not be wise to hold a vote. Finally I'll observe that if supermajority would result in a different result than consensus then the PMC probably has serious problems collaborating that need to be fixed. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On Jan 31, 2012, at 12:52 PM, Doug Cutting wrote: On 01/30/2012 05:12 PM, Greg Stein wrote: I've never liked vetoes for this. One person can hold an entire PMC hostage simply for disliking someone (or worse: subtle corporate concerns masked otherwise). People have said in the past, you should have veto so you're not forced to work with somebody you dislike. I respond, grow up. we work with annoying people all the time, and the majority says they *can* work When this question came up in another context, Roy's concern, as I recall it, was something to the effect that if you don't allow vetoes of proposed PMC members then you might create a dysfunctional PMC. (Roy, please correct me if I miss-recall.) Well, it boils down to the fact that making someone a PMC member gives them veto power over the changes you make. The only way that works socially is if everyone currently on the PMC agrees that person is a peer. Having said that, I should note that the context of Incubator is significantly different than a normal PMC. If incubator wants to structure itself more like a board and less like a project, I really don't have much to say against that. Note that it should effect all of the decision guidelines that give veto power, not just personnel decisions. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
Proposal looks good. Niall On Tue, Jan 31, 2012 at 9:14 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I would like to propose Syncope, an Open Source system for managing identities in enterprise environments, implemented in JEE technology, originally developed by Tirasa, an Italian IT company, to be an Apache Incubator project. The goal for Syncope is to become the reference implementation for Open Source Identity Management, a middleware area in which there are very few and not yet mature Open Source solutions available. Here's a link to the proposal in the Incubator wiki[1] where we started collecting all needed info. As you will note, the list of mentors is in need of some volunteers, so if you find this interesting, feel free to sign up or let us know you are interested :). Hope to read from you soon, thanks in advance and have a nice day! All the best, Simo [1] http://wiki.apache.org/incubator/SyncopeProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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] eliminate vetoes on personnel votes
On 1/31/2012 3:28 PM, Roy T. Fielding wrote: Having said that, I should note that the context of Incubator is significantly different than a normal PMC. If incubator wants to structure itself more like a board and less like a project, I really don't have much to say against that. Note that it should effect all of the decision guidelines that give veto power, not just personnel decisions. That touched on something. The incubator is a meta-committee. It is entrusted with and given more latitude to operate subprojects even as the board has attempted to squash or at least minimize the practice at other projects. Probably every issue that happened at Jakarta (etc) all could and probably will happen here at some point. Is there latitude to assign PPMC's full and proper subcommittee status, such that their actions are binding? Perhaps this is something that happens later in the project, following the initial phase of incubation. Perhaps the PPMC is charged with bootstrapping itself into a subcommittee consisting of those who will serve at the TLP committee; modulo early signers-on who had not made any actual contribution during incubation. Perhaps the mentors become pivotal in identifying those PPMC participants who made contributions and proposing the subcommittee to the IPMC? So you have an almost-TLP, still operating under the oversight of the incubator, until the final incubation requirements are met and the subcommittee is passed on verbatim to the board as a TLP. This would seem to solve certain desires for more PPMC autonomy and self-governance. Back to Roy's point, the incubator PMC produces almost no code. It is not a TLP in any sense of the word we know, although that seems to be lost or ignored in several discussions about incubator operation. But a subcommittee would have the onus of operating as a familiar code-producing TLP PMC in every respect. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
Hi Roy, On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote: On Jan 31, 2012, at 12:52 PM, Doug Cutting wrote: On 01/30/2012 05:12 PM, Greg Stein wrote: I've never liked vetoes for this. One person can hold an entire PMC hostage simply for disliking someone (or worse: subtle corporate concerns masked otherwise). People have said in the past, you should have veto so you're not forced to work with somebody you dislike. I respond, grow up. we work with annoying people all the time, and the majority says they *can* work When this question came up in another context, Roy's concern, as I recall it, was something to the effect that if you don't allow vetoes of proposed PMC members then you might create a dysfunctional PMC. (Roy, please correct me if I miss-recall.) Well, it boils down to the fact that making someone a PMC member gives them veto power over the changes you make. The only way that works socially is if everyone currently on the PMC agrees that person is a peer. Having said that, I should note that the context of Incubator is significantly different than a normal PMC. If incubator wants to structure itself more like a board and less like a project, I really don't have much to say against that. Note that it should effect all of the decision guidelines that give veto power, not just personnel decisions. Isn't that the problem right now though? Like it or not, the Incubator PMC has evolved into a mini-board, in the worse sense of the word. You guys have a monthly meeting via telecon; an agenda; a set of action items, and you still don't get everything that you want to get done, done. A very small percentage of folks within the IPMC actually maintain that type of board-like oversight over its podlings. And thus, because of that, the more I think about it, quite honestly, I don't know what the Incubator PMC is doing other than delay the inveitable eventuality that many of these projects will graduate and become TLPs and thus the board's problem; whereas many of them will not graduate, and become not Apache's problem. We have an Attic for projects that make it to TLP for that. Heck, we have SVN and could even reboot Incubator dead projects if a group of individuals came along and wanted to maintain the code. My conclusion from all the ruckus recently has been that the Incubator PMC is nothing more than an Incubator mailing list where many ASF veterans and those that care about the foundation discuss (and sometimes argue) about the foundation's policies and interpretations of law that not even lawyers are perfect at -- we're all human yet we try and get on our high horse here and act like we speak in absolutes and the will of one or a small subset is the will of the many when we all know that in the end, if it's not fun anymore, we wouldn't be here. What would be so bad about saying that the Incubator, over its existence, has served its purpose and has devolved into an umbrella project of the type that we are looking to get rid of at the Foundation. I agree with Bill on the perspective that I'm sure at some point (and it's probably already happened), we will experience Jakarta type symptoms and potentially may go down that road. Instead of couching it as scary HUGE change that several Apache vets have expressed to me that the Foundation doesn't like, how about we don't call it a change at all; and simply a success. IOW, the Incubator itself has graduated and it's time for it to be Attic'ed. In replacement, I propose the following concrete actions: 1. Move the Incubator process/policy/documentation, etc., to ComDev - I agree with gstein on this. I think it could be maintained by the ASF community folks there, and updated over time. But it's not vastly or rapidly changing really anymore. 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on the back, go have a beer, watch the big game together, whatever. Call it a success, not a failure. 3. Suggest at the board level that an Incubation process still exists at Apache, in the same way that it exists today. New projects write a proposal, the proposal is VOTEd on by the board at the board's next monthly meeting, and those that cannot be are QUEUED for the next meeting, or VOTEd on during out of board inbetween time on board@. Refer those wanting to Incubate at Apache to the existing Incubator documentation maintained by the ComDev community. Tell them to ask questions there, about the process, about what to do, or if ideas make sense. But *not* to VOTE on whether they are accepted or not. 4. Require every podling to have at least 3 ASF members on it, similar to the current Incubator process. 5. Operate podlings *exactly the same* as a TLP. There is a chair. There is a committee. Committee members have binding VOTEs on releases. I'm sure folks will argue this is blasphemy or that it will just add to the board's work, or that I'm ugly ... whatever. The fact of the
Re: [DISCUSS] eliminate vetoes on personnel votes
On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote: In replacement, I propose the following concrete actions: 1. Move the Incubator process/policy/documentation, etc., to ComDev - I agree with gstein on this. I think it could be maintained by the ASF community folks there, and updated over time. But it's not vastly or rapidly changing really anymore. 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on the back, go have a beer, watch the big game together, whatever. Call it a success, not a failure. 3. Suggest at the board level that an Incubation process still exists at Apache, in the same way that it exists today. New projects write a proposal, the proposal is VOTEd on by the board at the board's next monthly meeting, and those that cannot be are QUEUED for the next meeting, or VOTEd on during out of board inbetween time on board@. Refer those wanting to Incubate at Apache to the existing Incubator documentation maintained by the ComDev community. Tell them to ask questions there, about the process, about what to do, or if ideas make sense. But *not* to VOTE on whether they are accepted or not. Note that at the time the incubator was created, there was no particular process. Projects entered the ASF helter-skelter, without really following any template. Also, the legal committee was not a resource, comdev was not a resource, trademarks was not a resource, press was not a resource. I think it's sort of silly to suggest that resource needs are completely isolated to either incubating efforts, or TLP efforts. So the question is, what does the incubator provide today that should be persisted as a resource to any incubating or full project? Obviously, mentorship; but comdev seems like a really good home for that. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
May I suggest bumping thoughts of cashiering the incubator to its own thread? It seems a much bigger question than whether to prevent vetoes on PPMC membership votes. Don On Tue, Jan 31, 2012 at 6:21 PM, William A. Rowe Jr. wr...@apache.org wrote: On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote: In replacement, I propose the following concrete actions: 1. Move the Incubator process/policy/documentation, etc., to ComDev - I agree with gstein on this. I think it could be maintained by the ASF community folks there, and updated over time. But it's not vastly or rapidly changing really anymore. 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on the back, go have a beer, watch the big game together, whatever. Call it a success, not a failure. 3. Suggest at the board level that an Incubation process still exists at Apache, in the same way that it exists today. New projects write a proposal, the proposal is VOTEd on by the board at the board's next monthly meeting, and those that cannot be are QUEUED for the next meeting, or VOTEd on during out of board inbetween time on board@. Refer those wanting to Incubate at Apache to the existing Incubator documentation maintained by the ComDev community. Tell them to ask questions there, about the process, about what to do, or if ideas make sense. But *not* to VOTE on whether they are accepted or not. Note that at the time the incubator was created, there was no particular process. Projects entered the ASF helter-skelter, without really following any template. Also, the legal committee was not a resource, comdev was not a resource, trademarks was not a resource, press was not a resource. I think it's sort of silly to suggest that resource needs are completely isolated to either incubating efforts, or TLP efforts. So the question is, what does the incubator provide today that should be persisted as a resource to any incubating or full project? Obviously, mentorship; but comdev seems like a really good home for that. - 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
BlueSky is back?
Hi, http://wiki.apache.org/incubator/February2011?action=diffrev1=55rev2=56 Or is someone just confused? For comparison: http://incubator.apache.org/projects/bluesky.html BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Syncope to Join the Apache Incubator
On Tue, Jan 31, 2012 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi Simo! Sounds like a really nice project. But I wonder if there is some overlap with the Apache Shiro project [1]? They're not the same as some have pointed out yet even if they were there's nothing wrong with having overlapping projects or ones that even duplicate each other functionally. Alex
Re: [DISCUSS] Syncope to Join the Apache Incubator
Dear Proposed Syncope mentors: Please post messages on this thread indicating your prior experience as mentors, if any, and your willing to remain in place as active mentors for at least a year. On Tue, Jan 31, 2012 at 6:59 PM, Alex Karasulu akaras...@apache.org wrote: On Tue, Jan 31, 2012 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi Simo! Sounds like a really nice project. But I wonder if there is some overlap with the Apache Shiro project [1]? They're not the same as some have pointed out yet even if they were there's nothing wrong with having overlapping projects or ones that even duplicate each other functionally. Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: BlueSky is back?
Hi, On Wed, Feb 1, 2012 at 12:58 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: http://wiki.apache.org/incubator/February2011?action=diffrev1=55rev2=56 Or is someone just confused? It's me who's confused. We're in 2012 already... :-) BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q: including notice for binary release of artifacts that are brought in via Maven?
On 31 January 2012 18:15, Jakob Homan jgho...@gmail.com wrote: Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. This is the case for Giraph (and Kafka and other projects that bring in transitive dependencies into the tar.gz via maven), so the jackrabbit approach won't work. Which puts me back at my original question: how to include NL for the binary distribution without having to re-create it on the release branch each time. I'll take a look at Whisker, but for now it seems like one just needs to have a release-specific NL for the binary artifact? Just include the binary NL files somewhere other than the top level in SVN, and copy them to the top-level in the binary artifacts. Perhaps use names like NOTICE_binary/LICENSE_binary to make it obvious. -jg On Tue, Jan 31, 2012 at 6:05 AM, sebb seb...@gmail.com wrote: On 31 January 2012 11:07, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Jan 31, 2012 at 2:49 AM, Jakob Homan jgho...@gmail.com wrote: Great, thanks. Using this method, I get a file layout similar to: giraph-0.1-SNAPSHOT-bin.tar.gz NOTICE (without appended text for dep1 and dep2) LICENSE (without appended text for dep1 and dep2) bin/ lib/ dep1.jar dep2.jar giraph.jar META-INF/ NOTICE (with appended text for dep1 and dep2) LICENSE (with appended text for dep1 and dep2) This matches with what I see when I checkout the jackrabbit-standalone code and do a package command from maven there. I just want to verify that this will past muster with incubator. This configuration satisfies the requirement for those notices/licenses to be included? The general idea is that the NOTICE/LICENSE pair of an artifact should cover all the bits included inside that artifact. Also the idea is that the NL (and Disclaimer, Readme if any) are at the top-level of the artifact. The only exception to this is that NL files are added to a jar META-INF directory instead (as that is the convention for jars) . Having the files in a standard place is intended to make it easy for the consumer to find the files. The NL files are important for the consumer; they should not have to go looking for them. If giraph.jar doesn't embed dep1 and dep2, then there's no need to mention them in the NOTICE/LICENSE pair of that jar. Instead, since you are including dep1 and dep2 inside giraph-bin.tar.gz, they should be covered by the NOTICE/LICENSE pair of the tarball. If you look inside the jackrabbit-standalone jar, you'll notice that it actually contains all the external components mentioned in the NOTICE/LICENSE files. BR, Jukka Zitting - 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: Questions for projects
Hi, On Tue, Jan 31, 2012 at 6:25 PM, Richard Frovarp rfrov...@apache.org wrote: Did I miss the reminder? Or is it not working? I suppose the reminder will go out tomorrow on the first day of the month. I guess that's not too helpful given that the deadline is also tomorrow. Droids Any progress on getting more people to contribute? I'm seeing a significant drop in list activity since December. What's up? No progress at the moment. We need to evaluate those that have contributed patches to bring in new blood. OK, cool. I don't know the cause for drop in last activity. I think it just needs a reboot after the holidays. Yep, could be just a blib. That happens to many projects every now and then, especially after holidays. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Brilliant report from Wookie
Hi, http://wiki.apache.org/incubator/February2012?action=diffrev1=17rev2=18 Perhaps a bit verbose to some tastes, but this contains all the information an external observer needs to get a good picture of the project status. Great level of introspection combined with ability identify concrete action items. Nice work, Wookie! BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
