Re: PPMCs [was Re: what are required for contributing to release management]
On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote: On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. http://incubator.apache.org/guides/ppmc.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Hi Jim, Jim Jagielski wrote: On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote: On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. http://incubator.apache.org/guides/ppmc.html I assume you're referring to this sentence: "Initially, it is composed of the Podling's mentors and initial committers." I have also found some threads which indicate that all committers should be added [1][2]. I want to know here - who is wrong? The documentation? Or the previous incubated projects who didn't add all the initial committers? There is also the following sentence which adds some doubt that the above is the official policy: "The PPMC is directly responsible for the oversight of the podling and it also decides who to add as a PPMC member." While this could be referrering to post PPMC formation, it isn't clear. I will happily make a patch for the documentation to make things more clear if there is consensus. I am pretty philosophically against making every committer PPMC members. Apache is meritocracy based and IMO it makes much more sense to start with the mentors on the PPMC and have committers voted on based on their leadership. There may be many people on the incubation proposal or who have committed code to a project in the past, but an additional level of leadership is needed [3]. Not everyone may have the necessary leadership skills, and to presuppose they do because they have contributed good code, is IMO, a mistake. Cheerz, - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/200312.mbox/[EMAIL PROTECTED] 2. http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/[EMAIL PROTECTED] 3. See Project Management Committee section here http://www.apache.org/foundation/how-it-works.html#structure -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
+1 to Dan's opinion. --steve On Oct 1, 2006, at 11:36 AM, Dan Diephouse wrote: Hi Jim, Jim Jagielski wrote: On Sep 30, 2006, at 11:51 AM, Jason van Zyl wrote: On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. http://incubator.apache.org/guides/ppmc.html I assume you're referring to this sentence: "Initially, it is composed of the Podling's mentors and initial committers." I have also found some threads which indicate that all committers should be added [1][2]. I want to know here - who is wrong? The documentation? Or the previous incubated projects who didn't add all the initial committers? There is also the following sentence which adds some doubt that the above is the official policy: "The PPMC is directly responsible for the oversight of the podling and it also decides who to add as a PPMC member." While this could be referrering to post PPMC formation, it isn't clear. I will happily make a patch for the documentation to make things more clear if there is consensus. I am pretty philosophically against making every committer PPMC members. Apache is meritocracy based and IMO it makes much more sense to start with the mentors on the PPMC and have committers voted on based on their leadership. There may be many people on the incubation proposal or who have committed code to a project in the past, but an additional level of leadership is needed [3]. Not everyone may have the necessary leadership skills, and to presuppose they do because they have contributed good code, is IMO, a mistake. Cheerz, - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/ 200312.mbox/[EMAIL PROTECTED] 2. http://mail-archives.apache.org/mod_mbox/incubator-general/ 200603.mbox/[EMAIL PROTECTED] 3. See Project Management Committee section here http:// www.apache.org/foundation/how-it-works.html#structure -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 2.0.1 release of Cayenne
On 9/30/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: Cayenne community has voted and approved 2.0.1 release of Cayenne. This release marks a major milestone in Cayenne incubation as we've fully resolved all IP issues and got rid of incompatible license dependencies. Now we would like to request the approval of the Incubator PMC to perform the release. a RAT run turned up a few issues: *IMPORTANT* not under open source license: http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/Introduction/Guide%20to%201.1%20Features/cayenne-data-map-1_2.dtd http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/Introduction/Guide%20to%201.1%20Features/cayenne-driver-1_1.dtd http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/Introduction/Guide%20to%201.1%20Features/cayenne-project-1_1.dtd missing license headers: http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-other/wiki-docs/style.css http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/Introduction/Guide%20to%201.1%20Features/cayenne-data-view-1_1.dtd http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-other/javadoc/apache-javadoc.css http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-java/src/modeler/resources/pref/ModelerPreferences.map.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-java/src/modeler/resources/pref/Preferences.map.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-java/src/modeler/resources/pref/cayenne.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/UntitledDomainMap.map.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/cayenne.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/UntitledDomainNode.driver.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/cayenne/tutorial/Artist.java http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start-rop/cayenne-tutorial/src/UntitledDomainMap.map.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start-rop/cayenne-tutorial/src/cayenne.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start-rop/cayenne-tutorial/src/UntitledDomainNode.driver.xml http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start-rop/cayenne-tutorial/src/cayenne/tutorial/Artist.java http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start-rop/cayenne-tutorial-client/src/cayenne/tutorial/client/Artist.java [can't locate source]cayenne-2.0.1-incubating/doc/grammar/ExpressionParser.html looks to be generated to me. if it is then no license header is needed. notes: interesting that this is a(nother) binary-with-source distribution. this looks like it's been constructed by a build process rather than a direct svn snapshot. i hope that cayenne will also be made available as a source distribution. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 2.0.1 release of Cayenne
On 9/30/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: Cayenne community has voted and approved 2.0.1 release of Cayenne. This release marks a major milestone in Cayenne incubation as we've fully resolved all IP issues and got rid of incompatible license dependencies. Now we would like to request the approval of the Incubator PMC to perform the release. oh yes: the LICENSE and NOTICE files are ok but the LICENSE file could be improved by including an indication about to which artifact or source file the particular license applies. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with commit rights on Celtixfire
Robert, > setting aside the particulars, this worries me from a process perspective. > the initial list of committers was elected by the incubator PMC as > part of the approval process. IMO the incubator PMC cannot provide > oversight if we delegate power to the PPMCs to change their terms of > reference without a binding decision. The Incubator PMC, as a general rule, is probably not in the best position to determine whom should be on the Committers list initially, and we certainly have rarely if ever taken the time in most cases to review each one. That's part of the problem. Sometimes there is piling on, and sometimes there are good reasons for including someone. I heard both sides of that from the same people involved in CeltiXFire (as in "THOSE people are piling on, but THESE people we want", and we've certainly heard it from other projects. This is why I keep pushing back with the idea that we bootstrap in a defined manner: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This is simple and human driven, delegating decisions in the normal ASF manner. And so long as we meet the standard criteria (at least 3 +1 from Incubator PMC members -- again, this is why each project SHOULD have at least 3 Mentors -- and proper notice to the PMC throughout the voting process), it should work well. > i would expect any decision made about varying the initial comitters > list to appear in the private list of the podling together with at > least 3 +1's binding on apache (from incubator PMC members). i've > searched the lists and cannot find such a VOTE nor even any > discussion. As above. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 2.0.1 release of Cayenne
Hi Robert, On Oct 1, 2006, at 12:57 PM, robert burrell donkin wrote: oh yes: the LICENSE and NOTICE files are ok but the LICENSE file could be improved by including an indication about to which artifact or source file the particular license applies. I guess then it would duplicate NOTICE file (not that it is bad, just more chance for the two to get out of sync in the future). NOTICE does it in a way already, so I think of it as an "index" for the more verbose LICENSE. On Oct 1, 2006, at 12:35 PM, robert burrell donkin wrote: a RAT run turned up a few issues: *IMPORTANT* not under open source license: http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/ cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/ Introduction/Guide%20to%201.1%20Features/cayenne-data-map-1_2.dtd Everything except for DTD's are generated files. We'll will fix the DTD's shortly. interesting that this is a(nother) binary-with-source distribution. this looks like it's been constructed by a build process rather than a direct svn snapshot. True - this was a conscious decision made a few years ago with the goal to make the release artifacts user-friendly. Looking at some projects that post releases as SVN snapshots can be a nightmare - it is organized for development, not for end-user consumption. It will be a nightmare for Cayenne too, as Cayenne trunk (targeting 3.0 release) is switched to Maven, and there is no one-to- one correspondence between final release jars and Maven artifacts because of multiple JDK versions support, lightweight stripped down jars for remote clients, etc. i hope that cayenne will also be made available as a source distribution. I'd like to hear arguments why this would be a good thing? I can think of two: * Smaller download. IMO this is addressed by clean SVN tagging (users can always build a given version if they want); widespread use of broadband (not only in the West); and much more user-friendly release (you get binaries, source and tools in one place and in place where you expect to find it). * Binaries are not cross-platform. Aside from the tool launchers, everything is Java. Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On Sun, Oct 01, 2006 at 01:05:37PM -0400, Noel J. Bergman wrote: > - The Incubator PMC sets the Mentors, who form the initial PPMC > - The PPMC (Mentors) elects additional PPMC members > - The PPMC elects Committers > +1 a step in the right direction. vh Mads Toftum -- http://soulfood.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On 10/1/06, Mads Toftum <[EMAIL PROTECTED]> wrote: On Sun, Oct 01, 2006 at 01:05:37PM -0400, Noel J. Bergman wrote: > - The Incubator PMC sets the Mentors, who form the initial PPMC > - The PPMC (Mentors) elects additional PPMC members > - The PPMC elects Committers > +1 a step in the right direction. +1 provided we take the list of interested committers out of the proposal. We shouldn't be indicating that we are in favour of a proposal if we're not going to make the committers listed committers. My suggestion is that we would have a wiki page on which interested committers list themselves and it would be up to the mentors to get them onto the project, by investigating the merit they've shown in previous incarnations of the project and the subsequent merit they show. It could be the same wiki page as the proposal is drafted on, provided there's a nice separation. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PPMCs [was Re: what are required for contributing to release management]
Jason van Zyl wrote: > I think starting with the mentors is the wisest choice as at that > point any committers can be brought aboard if deemed fit. My view of that should be quite clear by now. :-) > I was also confused about this as I heard one thing from Noel and > one thing from Jim Can you elaborate so that we can clarify and make sure that we have a consensus? > the mentors deciding seems sensible as projects can be dealt with on a > case by case basis. Agreed. The Mentors are PMC members. And the rest of the PMC can be as involved as any PMC member wants to be involved. > I don't believe committers should automatically be made (P)PMC members > as to me it's a different level of understanding and commitment. Yes, although there are benefits to making people PPMC members as soon as you feel that they can be trusted with confidentiality. After all, they do NOT gain binding votes in the PPMC, since those are exclusively held by PMC members. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
+1 from me on the process. FWIW, that's what we followed in Harmony and then ODE. FWIW, As a mentor for a specific project, I'd like to see some activity (patches/bugs) from a proposed committer. Not just say a couple of one line emails before i vote them in as a committer. thanks, dims On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: Robert, > setting aside the particulars, this worries me from a process perspective. > the initial list of committers was elected by the incubator PMC as > part of the approval process. IMO the incubator PMC cannot provide > oversight if we delegate power to the PPMCs to change their terms of > reference without a binding decision. The Incubator PMC, as a general rule, is probably not in the best position to determine whom should be on the Committers list initially, and we certainly have rarely if ever taken the time in most cases to review each one. That's part of the problem. Sometimes there is piling on, and sometimes there are good reasons for including someone. I heard both sides of that from the same people involved in CeltiXFire (as in "THOSE people are piling on, but THESE people we want", and we've certainly heard it from other projects. This is why I keep pushing back with the idea that we bootstrap in a defined manner: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This is simple and human driven, delegating decisions in the normal ASF manner. And so long as we meet the standard criteria (at least 3 +1 from Incubator PMC members -- again, this is why each project SHOULD have at least 3 Mentors -- and proper notice to the PMC throughout the voting process), it should work well. > i would expect any decision made about varying the initial comitters > list to appear in the private list of the podling together with at > least 3 +1's binding on apache (from incubator PMC members). i've > searched the lists and cannot find such a VOTE nor even any > discussion. As above. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On 1 Oct 06, at 1:05 PM 1 Oct 06, Noel J. Bergman wrote: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Dan Diephouse <[EMAIL PROTECTED]> wrote: I am pretty philosophically against making every committer PPMC members. Apache is meritocracy based and IMO it makes much more sense to start with the mentors on the PPMC and have committers voted on based on their leadership. There may be many people on the incubation proposal or who have committed code to a project in the past, but an additional level of leadership is needed [3]. Not everyone may have the necessary leadership skills, and to presuppose they do because they have contributed good code, is IMO, a mistake. I don't agree at all. If they contribute code, they merit a say in the direction of the project. To do otherwise is to exclude them from the community. Remember that only folks on the PPMC have a vote: a committer does not have any say or vote in the project at all. The critical aim of the PPMC is to create a self-managing project. By excluding everyone from that process except for mentors, you will not be teaching the new people how the project should be managed. In the early days of the podlngs, the mentors should have proportionally more say in how things proceed; but in order to graduate to TLP status, the PPMC must be able to demonstrate the ability to manage itself - and probably the contributions from the mentors should be excluded from that determination - i.e. is the PPMC without the mentor able to govern itself. -- justin
Re: Problem with commit rights on Celtixfire
On 10/1/06, Henri Yandell <[EMAIL PROTECTED]> wrote: +1 provided we take the list of interested committers out of the proposal. We shouldn't be indicating that we are in favour of a proposal if we're not going to make the committers listed committers. This works for some proposals but not for others. Take Wicket for example: we would require all of the people who already had commit access to Wicket re-prove themselves? That's incredibly dismissive of their past contributions. -- justin
RE: PPMCs [was Re: what are required for contributing to release management]
Dan Diephouse wrote: > I assume you're referring to this sentence: > "Initially, it is composed of the Podling's mentors and initial committers." > I have also found some threads which indicate that all committers should > be added [1][2]. I want to know here - who is wrong? The documentation? Neither. Both. I'm probably the one who is quoted in that documentation. And the idea of the PPMC and Incubator oversight has evolved. Taken at face value, the sentence says that the PPMC is bootstrapped from the PMC members acting as Mentors and the initial people involved in the project. At the time, it probably made sense, since we had few problems with the initial commit lists. Then things started to change, with accusations both of piling on and exclusionary behavior. At the moment, there is a proposal being mooted to remove the list of initial committers from the proposal (there would be a list of interested participants), and have the whole thing bootstrapped by the Mentors after the PMC has voted to accept. > "The PPMC is directly responsible for the oversight of the podling and > it also decides who to add as a PPMC member." That is correct. > I am pretty philosophically against making every committer PPMC members. Personally, I agree, but there are benefits to biasing the process towards making people PPMC members in short course. I'd have a lower bar on that than on a PMC member, since only PMC members have binding votes, anyway. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On 10/1/06, Henri Yandell <[EMAIL PROTECTED]> wrote: On 10/1/06, Mads Toftum <[EMAIL PROTECTED]> wrote: > On Sun, Oct 01, 2006 at 01:05:37PM -0400, Noel J. Bergman wrote: > > - The Incubator PMC sets the Mentors, who form the initial PPMC > > - The PPMC (Mentors) elects additional PPMC members > > - The PPMC elects Committers > > > +1 a step in the right direction. +1 +1 provided we take the list of interested committers out of the proposal. We shouldn't be indicating that we are in favour of a proposal if we're not going to make the committers listed committers. +1 (note that this is definitely a process change so we'll need to draw up a patch for the process document and vote on that) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On 10/1/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: On 10/1/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > +1 provided we take the list of interested committers out of the > proposal. We shouldn't be indicating that we are in favour of a > proposal if we're not going to make the committers listed committers. This works for some proposals but not for others. Take Wicket for example: we would require all of the people who already had commit access to Wicket re-prove themselves? That's incredibly dismissive of their past contributions. delegation to the PPMC means that the Mentors have it within their power to solve this one themselves. IMHO it would be right (in the case of a project like Wicket) for the Mentors to elect all those who had commit access already as committers right away. i would also see nothing wrong in moving quickly to drafting all existing Wicket committers onto the PPMC. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with commit rights on Celtixfire
Henri Yandell wrote: > Mads Toftum wrote: > > Noel J. Bergman wrote: > > > - The Incubator PMC sets the Mentors, who form the initial PPMC > > > - The PPMC (Mentors) elects additional PPMC members > > > - The PPMC elects Committers > > +1 a step in the right direction. > +1 provided we take the list of interested committers out of the > proposal. We shouldn't be indicating that we are in favour of a > proposal if we're not going to make the committers listed committers. Agreed. The list of initial committers can be morphed to a list of people interested in being committers of the new project. Else, if we really do want to say that when the Incubator PMC votes to accept a project that it is accepting the list of initial committers, then we would have to defer voting on the project until after the PMC decided on each comitter, which means voting on the individuals before we vote on the project. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PPMCs [was Re: what are required for contributing to release management]
Justin Erenkrantz wrote: > Dan Diephouse wrote: > > I am pretty philosophically against making every committer PPMC members. > I don't agree at all. If they contribute code, they merit a say in the > direction of the project. To do otherwise is to exclude them from the > community. Remember that only folks on the PPMC have a vote: a committer > does not have any say or vote in the project at all. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with commit rights on Celtixfire
Justin Erenkrantz wrote: > Henri Yandell wrote: > > +1 provided we take the list of interested committers out of the > > proposal. > This works for some proposals but not for others. Take Wicket for example: > we would require all of the people who already had commit access to Wicket > re-prove themselves? Where in: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers you see that requirement? I don't see anything excluding the PPMC from voting in all of the existing and active wicket committers. Seems like a reasonable criteria. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Problem with commit rights on Celtixfire
On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: Where in: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers you see that requirement? I don't see anything excluding the PPMC from voting in all of the existing and active wicket committers. Seems like a reasonable criteria. The problem is that this is not explicitly clear from the policy. All the policy states, and the feeling people get from reading this list is that 'Worthiness' needs to be proven before anyone can be part of the project. This is what kept me and a lot of our committers away from entering the incubator. The policy doesn't instigate a feeling of trust with regards to the current members of pre-podling projects. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
*** REMINDER: Incubator Board Reports
Please note. Today is October 1. Time to start getting the Board reports posted. We will no longer hold the report pending late arrivals, at the Board's insistence. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Policy on Initial Committership
Taken from the "Problem with commit rights on Celtixfire" thread: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This also implies changing the proposal's initial committers list to something suggestive not binding, allowing the the Mentors review and vote on comitters. So far, as responses we have: +1: Noel J. Bergman Mads Toftum Henri Yandell Davanum Srinivas Jason Van Zyl Robert Burrell Donkin Justin has raised a concern that we not create an unfair or insulting barrier existing, active. committers on communities joining the ASF. Robert and I have independently expressed our views that this won't do so. Since we've discussed almost this exact proposal in the past, I'll try to get some time Monday or Tuesday to dig up any past objections, unless someone beats me to it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers you see that requirement? I don't see anything excluding the PPMC from voting in all of the existing and active wicket committers. Seems like a reasonable criteria. The implicit criteria I'm interpreting from this thread is that it would be forbidden: only activity within the podling (while it is here) would be considered as to whether someone should be granted committership or PMC status. This is certainly how I read what Dan and others are advocating. IMHO, mentors should be encouraged to cast the net as wide as possible. In fact, podlings that do not permit active contributors being on the PPMC should be dealt with accordingly (i.e. swift application of cluebats). -- justin
Policy on Initial Committership
Martijn Dashorst wrote: > Noel J. Bergman wrote: > > Where in: > > - The Incubator PMC sets the Mentors, who form the initial PPMC > > - The PPMC (Mentors) elects additional PPMC members > > - The PPMC elects Committers > > you see that requirement? I don't see anything excluding the PPMC from > > voting in all of the existing and active wicket committers. Seems like a > > reasonable criteria. > The problem is that this is not explicitly clear from the policy. All > the policy states, and the feeling people get from reading this list > is that 'Worthiness' needs to be proven before anyone can be part of > the project. Ah, the line between law and jurisprudence. To be specific: jurisprudence, n: the branch of philosophy concerned with the law and the principles that lead courts to make the decisions they do The process says: - The PPMC elects Committers which is a simple statement of process, but you're tacitly assuming criteria. > This is what kept me and a lot of our committers away from > entering the incubator. The policy doesn't instigate a > feeling of trust with regards to the current members of > pre-podling projects. Would it help if the process document illustrated the process and had FAQs? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: Taken from the "Problem with commit rights on Celtixfire" thread: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This also implies changing the proposal's initial committers list to something suggestive not binding, allowing the the Mentors review and vote on comitters. So far, as responses we have: +1: Noel J. Bergman Mads Toftum Henri Yandell Davanum Srinivas Jason Van Zyl Robert Burrell Donkin Justin has raised a concern that we not create an unfair or insulting barrier existing, active. committers on communities joining the ASF. Robert and I have independently expressed our views that this won't do so. -1. I think your response is extremely misguided. In this situation, we would accept code without allowing the people who contributed it further access: that is completely unfair. If we do not accept the people, we don't accept the code. -- justin
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > I am pretty philosophically against making every committer PPMC members. > I don't agree at all. If they contribute code, they merit a say in the > direction of the project. To do otherwise is to exclude them from the > community. Remember that only folks on the PPMC have a vote: a committer > does not have any say or vote in the project at all. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. My comment was in reply to the entirety of Dan's comment (which you snipped). But, as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. Placing qualities besides what they contribute as qualifications to PMC status is to miss the point - if you contribute to the project, you get a vote. -- justin
Re: [VOTE] Approve the 2.0.1 release of Cayenne
On 10/1/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: Hi Robert, On Oct 1, 2006, at 12:57 PM, robert burrell donkin wrote: > oh yes: the LICENSE and NOTICE files are ok but the LICENSE file could > be improved by including an indication about to which artifact or > source file the particular license applies. I guess then it would duplicate NOTICE file (not that it is bad, just more chance for the two to get out of sync in the future). NOTICE does it in a way already, so I think of it as an "index" for the more verbose LICENSE. i like the way httpd does things: http://incubator.apache.org/guides/examples/LICENSE but i can see the cayenne approach working ok provided that there a small note somewhere telling people to look in the NOTICE file On Oct 1, 2006, at 12:35 PM, robert burrell donkin wrote: > a RAT run turned up a few issues: > > *IMPORTANT* not under open source license: > http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/ > cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/ > Introduction/Guide%20to%201.1%20Features/cayenne-data-map-1_2.dtd Everything except for DTD's are generated files. We'll will fix the DTD's shortly. interesting. there were a number of files which were clearly generated that i ignored. these had notices in noting that they were generated. the ones i highlighted didn't look like they were hand crafted to me and lacked notices that they were generated. for example http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/cayenne/tutorial/Artist.java looked to me like an example of a hand-crafted subclass. the preferences files didn't look like it was generated to me either: http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-java/src/modeler/resources/pref/ModelerPreferences.map.xml. though perhaps i was fooled... one good practice often adopted by projects which make extensive use of generated source is to ensure that it's clear (either by including notes in the documents or by creating them in directories with clear names) which documents are generated and which are not. it would make it a lot easier and quicker to audit cayenne releases if this practice were adopted. > interesting that this is a(nother) binary-with-source distribution. > this looks like it's been constructed by a build process rather than a > direct svn snapshot. True - this was a conscious decision made a few years ago with the goal to make the release artifacts user-friendly. nothing wrong with that :-) Looking at some projects that post releases as SVN snapshots can be a nightmare - it is organized for development, not for end-user consumption. It will be a nightmare for Cayenne too, as Cayenne trunk (targeting 3.0 release) is switched to Maven, and there is no one-to- one correspondence between final release jars and Maven artifacts because of multiple JDK versions support, lightweight stripped down jars for remote clients, etc. it's not a case of either a user-friendly binary release or a developer-friendly source release: most projects release a source distribution and various user friendly binary distributions. (a binary distribution is anything which isn't a straight export from the source.) > i hope that cayenne will also be made available as a source > distribution. I'd like to hear arguments why this would be a good thing? I can think of two: * Smaller download. IMO this is addressed by clean SVN tagging (users can always build a given version if they want); widespread use of broadband (not only in the West); and much more user-friendly release (you get binaries, source and tools in one place and in place where you expect to find it). * Binaries are not cross-platform. Aside from the tool launchers, everything is Java. my list: philosophical - it's open source: releases should include a source distribution social - apache projects need to recruit new developers to retain their health and vigour. it therefore makes sense to ship source distributions aimed at developers as well as binaries aimed at users practical - a source distribution future proofs the release (this is important at apache where release are preserved indefinitely). from a source distribution, a binary can be rebuilt even if subversion is not available (or is suspect or corrupt). so this is a useful perspective from an archival perspective. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 2.0.1 release of Cayenne
On Oct 1, 2006, at 2:42 PM, robert burrell donkin wrote: for example http://svn.apache.org/repos/asf/incubator/cayenne/main/ tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/ cayenne/tutorial/Artist.java looked to me like an example of a hand-crafted subclass. This one was generated, but then customized by hand. We do need a license on it - I will clean this up. preferences files didn't look like it was generated to me either: http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/ cayenne/cayenne-java/src/modeler/resources/pref/ ModelerPreferences.map.xml. though perhaps i was fooled... This one is generated by the Modeler tool to map preferences database for itself. one good practice often adopted by projects which make extensive use of generated source is to ensure that it's clear (either by including notes in the documents or by creating them in directories with clear names) which documents are generated and which are not. it would make it a lot easier and quicker to audit cayenne releases if this practice were adopted. Good point - I am +1. In the future releases we'll need to make our templates more explicit in this respect. Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 2.0.1 release of Cayenne
On 10/1/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: On Oct 1, 2006, at 2:42 PM, robert burrell donkin wrote: > for example http://svn.apache.org/repos/asf/incubator/cayenne/main/ > tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/ > cayenne/tutorial/Artist.java > looked to me like an example of a hand-crafted subclass. This one was generated, but then customized by hand. We do need a license on it - I will clean this up. there are a few other similar ones in those directories which might also need the same treatment > preferences files didn't look like it was generated to me either: > http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/ > cayenne/cayenne-java/src/modeler/resources/pref/ > ModelerPreferences.map.xml. > though perhaps i was fooled... This one is generated by the Modeler tool to map preferences database for itself. yes: makes sense now > one good practice often adopted by projects which make extensive use > of generated source is to ensure that it's clear (either by including > notes in the documents or by creating them in directories with clear > names) which documents are generated and which are not. it would make > it a lot easier and quicker to audit cayenne releases if this practice > were adopted. Good point - I am +1. In the future releases we'll need to make our templates more explicit in this respect. thanks - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Policy on Initial Committership
Justin Erenkrantz wrote: > Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > - The Incubator PMC sets the Mentors, who form the initial PPMC > > - The PPMC (Mentors) elects additional PPMC members > > - The PPMC elects Committers > > you see that requirement? I don't see anything excluding the PPMC from > > voting in all of the existing and active wicket committers. Seems like a > > reasonable criteria. > The implicit criteria I'm interpreting from this thread is that it would be > forbidden: only activity within the podling (while it is here) would be > considered as to whether someone should be granted committership or PMC > status. I don't see anyone on the Incubator PMC advocating that position. I don't see why that would generally be a desirable or recommended criteria for Incubator projects. > IMHO, mentors should be encouraged to cast the net as wide as possible. Sure. > podlings that do not permit active contributors being on the PPMC > should be dealt with accordingly Separate issue, but otherwise agreed. So what's the problem? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Policy on Initial Committership
Justin Erenkrantz wrote: > Noel J. Bergman wrote: > > - The Incubator PMC sets the Mentors, who form the initial PPMC > > - The PPMC (Mentors) elects additional PPMC members > > - The PPMC elects Committers > -1. I think your response is extremely misguided. In this situation, we > would accept code without allowing the people who contributed it further > access: that is completely unfair. I disagree. You're conflating process with application of process, and then stating as assured a case when your fellow PMC Members would act in a manner you find offensive. Why would the PMC not elect "the people who contributed it further access"? > If we do not accept the people, we don't accept the code. So every Committer on every outside project must be accepted as an ASF Commiter without any consideration whatsoever? Just how polar do you want to cast the issue? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PPMCs [was Re: what are required for contributing to release management]
Justin Erenkrantz wrote: > Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > > > I am pretty philosophically against making every committer PPMC > > > > > members. > > > I don't agree at all. If they contribute code, they merit a say in the > > > direction of the project. > > Are you reading Dan's statement as independent or dependent upon time? I > > read it as an objection to mandated concurrency. Over time, your view > > should be the dominant one, as each Committer becomes a (P)PMC member. > as for the one line that you retained: I view Dan's perspective as > being independent of time - that is, committers should never equal > the PMC - I view that as extremely unhealthy. If I had read it as you do, I would agree with you. I read it as suggestive of a process over time, and that at any snapshot in time, the body of Committers might not be entirely present in the PPMC. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: I disagree. You're conflating process with application of process, and then stating as assured a case when your fellow PMC Members would act in a manner you find offensive. Why would the PMC not elect "the people who contributed it further access"? We've seen an example of this with Celtixfire. So far, we're waiting for an explanation (as those discussions did not occur in a place where the Incubator PMC could provide any oversight), but the aggrieved parties believe they have been barred access to a project they felt they contributed to. So, I don't believe this situation isn't a hypothetical at all. -- justin
Re: [VOTE] Policy on Initial Committership
On Sun, Oct 01, 2006 at 11:32:44AM -0700, Justin Erenkrantz wrote: > -1. I think your response is extremely misguided. In this situation, we > would accept code without allowing the people who contributed it further > access: that is completely unfair. > > If we do not accept the people, we don't accept the code. -- justin So are you suggesting we boot out a project like xxx? or are you happy with incubator projects being fully open for companies stacking their employees in to "own" a project? I for one find it quite worrying that it is entirely possible to list something like 10 or 15 of your employees on a proposal and sidestep the whole meritocracy issue. vh Mads Toftum -- http://soulfood.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
Justin Erenkrantz wrote: On 10/1/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: I disagree. You're conflating process with application of process, and then stating as assured a case when your fellow PMC Members would act in a manner you find offensive. Why would the PMC not elect "the people who contributed it further access"? We've seen an example of this with Celtixfire. So far, we're waiting for an explanation (as those discussions did not occur in a place where the Incubator PMC could provide any oversight), but the aggrieved parties believe they have been barred access to a project they felt they contributed to. So, I don't believe this situation isn't a hypothetical at all. -- justin It seems to me that this is the reverse actually - committers were approved, and then the PMC revoked their rights. However, this is just inference on my part so far. - Dan -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On 10/1/06, Mads Toftum <[EMAIL PROTECTED]> wrote: On Sun, Oct 01, 2006 at 11:32:44AM -0700, Justin Erenkrantz wrote: > -1. I think your response is extremely misguided. In this situation, we > would accept code without allowing the people who contributed it further > access: that is completely unfair. > > If we do not accept the people, we don't accept the code. -- justin So are you suggesting we boot out a project like xxx? or are you happy with incubator projects being fully open for companies stacking their employees in to "own" a project? I for one find it quite worrying that it is entirely possible to list something like 10 or 15 of your employees on a proposal and sidestep the whole meritocracy issue. I do too. And with the number of projects coming in with sizeable numbers of committers these days, I wonder how long it will be before the committers coming in this way will outnumber those whose committership is based on (ASF earned) merit. It seems to me that this could change the fundamental nature of the ASF. -- Martin Cooper vh Mads Toftum -- http://soulfood.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] Policy on Initial Committership
Isn't there a rule that the community should be diverse, i.e. not dependent on one company? How doesn't this affect the proposal's initial list of committers/ppmc members? Martijn On 10/1/06, Martin Cooper <[EMAIL PROTECTED]> wrote: On 10/1/06, Mads Toftum <[EMAIL PROTECTED]> wrote: > > On Sun, Oct 01, 2006 at 11:32:44AM -0700, Justin Erenkrantz wrote: > > -1. I think your response is extremely misguided. In this situation, > we > > would accept code without allowing the people who contributed it further > > access: that is completely unfair. > > > > If we do not accept the people, we don't accept the code. -- justin > > So are you suggesting we boot out a project like xxx? or are > you happy with incubator projects being fully open for companies > stacking their employees in to "own" a project? > I for one find it quite worrying that it is entirely possible to list > something like 10 or 15 of your employees on a proposal and sidestep the > whole meritocracy issue. I do too. And with the number of projects coming in with sizeable numbers of committers these days, I wonder how long it will be before the committers coming in this way will outnumber those whose committership is based on (ASF earned) merit. It seems to me that this could change the fundamental nature of the ASF. -- Martin Cooper vh > > Mads Toftum > -- > http://soulfood.dk > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Noel J. Bergman wrote: Justin Erenkrantz wrote: Noel J. Bergman <[EMAIL PROTECTED]> wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. If I had read it as you do, I would agree with you. I read it as suggestive of a process over time, and that at any snapshot in time, the body of Committers might not be entirely present in the PPMC. I did in fact mean it as dependent on time. And specifically I meant at the beginning of incubation. I don't think every committer should be on the PPMC from the outset. Every committer may be on the PPMC at graduation, and this is encouraged, but only after they are explicitly voted on by the existing PPMC members. Now the PPMC may just chose to vote on specific individuals or everyone at once, its up to them. I would however encourage only voting people in after they an appropriate level of committment and involvement with the project. - Dan -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
Dan Diephouse wrote: Noel J. Bergman wrote: Justin Erenkrantz wrote: Noel J. Bergman <[EMAIL PROTECTED]> wrote: I am pretty philosophically against making every committer PPMC members. I don't agree at all. If they contribute code, they merit a say in the direction of the project. Are you reading Dan's statement as independent or dependent upon time? I read it as an objection to mandated concurrency. Over time, your view should be the dominant one, as each Committer becomes a (P)PMC member. as for the one line that you retained: I view Dan's perspective as being independent of time - that is, committers should never equal the PMC - I view that as extremely unhealthy. If I had read it as you do, I would agree with you. I read it as suggestive of a process over time, and that at any snapshot in time, the body of Committers might not be entirely present in the PPMC. I did in fact mean it as dependent on time. And specifically I meant at the beginning of incubation. I don't think every committer should be on the PPMC from the outset. Every committer may be on the PPMC at graduation, and this is encouraged, but only after they are explicitly voted on by the existing PPMC members. Now the PPMC may just chose to vote on specific individuals or everyone at once, its up to them. I would however encourage only voting people in after they an appropriate level of committment and involvement with the project. One reason I feel this way is that I think protect's Apache's interests. Lets say that hypothetically, more people are put on a proposal than should be. If the PPMC members are elected after showing their committment to the long term health of the project, as opposed to all committers being added at the outset of the project, I believe this gives a better chance for correction. If I end up on the CXF (P)PMC I have every intention of starting a vote which removes any committers who have not contributed anything during incubation or significantly in the past. I hope I don't have to do that, but it doesn't seem fair that they would graduate as part of the project and have as much say as those who have shown their committment. If someone wants to get involved later, they can always contribute and get voted back in. I think this gives people a slightly lower barrier to get involved, which seems befitting to incubation and starting of a project, but also provides corrective measures in case there are problems. Cheers, - Dan -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
Justin, On Sunday October 01 2006 3:22 pm, Justin Erenkrantz wrote: > We've seen an example of this with Celtixfire. So far, we're waiting for > an explanation (as those discussions did not occur in a place where the > Incubator PMC could provide any oversight), but the aggrieved parties > believe they have been barred access to a project they felt they > contributed to. That's not it. The issue is they have been barred access to a project they have only expressed interest in contributed to. They have not yet contributed anything (no code, no patches, little to no communication on the dev list, etc...). That is why the CXF mentors decided it was in-appropriate to give them commit access. There name was on the initial proposal, but after two months, there was still no contributions. Those individuals are basically stating that since there name was on the proposal, that is enough to get the commit rights. Basically, Jason and the other mentors thought the initial commiters should actually be those who contribute/commit stuff. Those who don't meet that barrier haven't earned the commit rights, so why should they have commit rights? -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Approve the 2.0.1 release of Cayenne
I just posted the new release snapshots here: http://people.apache.org/~aadamchik/release/2.0.1/ The changes from the first attempt are: * Added license headers to the .dtd and .css files in the documentation. * Added license headers to the tutorial Java files that are changeable by users. * Added a note in the LICENSE file referring readers to the NOTICE file for explanation on third-party licenses. Many thanks to Robert for helping to straighten this up. Andrus On Sep 30, 2006, at 12:09 PM, Andrus Adamchik wrote: Cayenne community has voted and approved 2.0.1 release of Cayenne. This release marks a major milestone in Cayenne incubation as we've fully resolved all IP issues and got rid of incompatible license dependencies. Now we would like to request the approval of the Incubator PMC to perform the release. There were 6 "+1" votes (including 3 from PPMC members) and no other votes: Andrus Adamchik +1 Michael Gentry +1 Tore Halset +1 Mike Kienenberger +1 Kevin Menard +1 Jim Jagielski +1 (cast on the PPMC list) Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-cayenne-dev/ 200609.mbox/[EMAIL PROTECTED] Release artifacts can be found here: http://people.apache.org/~aadamchik/release/2.0.1/ And here is my +1 (non-binding) Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On 10/1/06, Mads Toftum <[EMAIL PROTECTED]> wrote: > If we do not accept the people, we don't accept the code. -- justin So are you suggesting we boot out a project like xxx? or are you happy with incubator projects being fully open for companies stacking their employees in to "own" a project? I for one find it quite worrying that it is entirely possible to list something like 10 or 15 of your employees on a proposal and sidestep the whole meritocracy issue. Yes, we do not accept a project if we're not prepared to grant commit access to those who have worked on the code. Again, the perception we are on the verge of fostering is that the meritocracy only happens here and for communities (like Wicket) where people have earned their access elsewhere, we are saying that we do not respect that as we will let the mentors by fiat decide who is worthy or not. I don't care much about the sidestepping of meritocracy: the community will not be able to graduate until they are diverse - hence the problem is self-correcting. If they can't gather a diverse collection of people, then no dice. I am concerned that we may permit PPMCs who view it as their right to refuse access to people who have actively contributed in the past and want to continue contributing because they don't like them personally or their employer or feel that they are not leadership material. Those aren't grounds for barring access. -- justin
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Dan Diephouse <[EMAIL PROTECTED]> wrote: would however encourage only voting people in after they an appropriate level of committment and involvement with the project. This creates a dividing line by omitting past contributions from the discussion which I feel is inappropriate. For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? -- justin
Re: [VOTE] Policy on Initial Committership
Justin Erenkrantz wrote: >> >> Justin has raised a concern that we not create an unfair or insulting >> barrier existing, active. committers on communities joining the >> ASF. Robert and I have independently expressed our views that this >> won't do so. > > -1. I think your response is extremely misguided. In this situation, we > would accept code without allowing the people who contributed it further > access: that is completely unfair. I entirely agree With Justin's perspective. Any stakeholder of incoming, existing code/docs etc, or any contributor at inception or during incubation should become (if they desire) 1. a committer, and 2. a stakeholder in the PPMC, which is generally morphed 1:1 into the PMC at graduation. If this discourages forks at the ASF, then politically that's exactly where the ASF should stand on forks. > If we do not accept the people, we don't accept the code. -- justin Exactly, ++1. This is why an initial list of committers, and initial code deposit must be precisely defined at the time of considering the proposal for incubation. One problem is that we have a list of initial participants in the initial incubation vote that passed, and I'm totally unclear how anyone believes those aren't the participants that the Incubator PMC voted to compose the submitted project. A participant who has neither PPMC nor Commit access is a non-participant. There are two solutions; 1. don't submit a list of participants beyond the initial PPMC list, or perhaps 2. always add a category of interested individuals, so we approve a PPMC, initial committers, and others interested. Initial committers should correspond to incoming code and collaborators by mutual agreement. Additional committers can evolve by contributions during incubation. Perhaps the policy failing here is that only the initial PPMC/incubation submission author is the only one who should be modifying the list of initial participants. But if this PMC voted on a list of initial participants, Noel, I'm confused why the PMC's directive would be ignored. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs [was Re: what are required for contributing to release management]
On 10/1/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: For example, if I were to work on a project for many months at Google Code and then propose it to come here, why shouldn't I continue to have a say in what the project does? Why do I need to justify myself all over again? Why aren't my past contributions enough to merit a seat on the PPMC? What gives the mentors the power to 'reset' the community and block me from participating until I jump through their vague and ill-defined hoops? Personally, I think the bar on commit to incoming projects should be simple, if you've made a contribution (code, docs, whatever) that's significant enough that it would justify commit access here, you should get it. For projects that are coming from the open source world, that just means "If you've got commit on it before it's at the ASF, you still do when it moves to the ASF", if it's corporate then obviously some due diligence needs to be done, but I think that's probably important in order to prevent the problem of providing a backdoor that avoids the whole meritocracy thing. Specifically though, I'd like to be clear that I don't think you should have to be an active participant in the project at the time it moves to the ASF in order to get commit/PPMC membership. As long as you're paying attention enough to sign the paperwork, the fact that you at one point qualified for this sort of access should be enough IMO. I know personally, when I have earned commit access to a project I expect that to still be there in the future, even if I fall off the planet for a while and don't have time to work on it. If the project had moved to the ASF in the meantime and all of a sudden I had to fight my way back to the same level of access I had in the past, I'd be pissed. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Oct 1, 2006, at 11:26 AM, Noel J. Bergman wrote: Taken from the "Problem with commit rights on Celtixfire" thread: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This also implies changing the proposal's initial committers list to something suggestive not binding, allowing the the Mentors review and vote on comitters. -1. Of the people participating in a new project, the Mentors are the least capable of selecting a PPMC. They generally know nothing about the code or the community, but rather know how to get things done at Apache. The Incubator PMC is even less able than that when it comes to selecting Mentors in the first place. The people listed in the proposal as committers are the PPMC. If some project allows too many people to jump on the proposal at the beginning in order to make the proposal look better to Apache, then they are stuck with the results. Don't like that answer? Then dissolve the podling and start over. Have committers that haven't bothered to contribute? Then vote them off the island, just like a real PMC. Truth in advertising demands that you follow the process as described in the proposal and use the Apache mailing lists for all project discussions. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Sun, Oct 01, 2006 at 02:01:31PM -0700, Justin Erenkrantz wrote: > Yes, we do not accept a project if we're not prepared to grant commit access > to those who have worked on the code. Again, the perception we are on the > verge of fostering is that the meritocracy only happens here and for > communities (like Wicket) where people have earned their access elsewhere, > we are saying that we do not respect that as we will let the mentors by fiat > decide who is worthy or not. Oh, this is something slightly different - you're talking of a project where development was done in the open and it is easy to figure out who contributed before. In that case, I think that the ppmc should pretty much automatically accept anyone who has been committers before if they _personally_ ask for it. This just isn't as clear when something comes out of a company ... it has shown itself as a bit too easy to be "creative" in those cases - and that's what I support putting a stop to. > > I don't care much about the sidestepping of meritocracy: the community will > not be able to graduate until they are diverse - hence the problem is > self-correcting. If they can't gather a diverse collection of people, then > no dice. > You're putting an awful lot of trust in that final review - it has slipped before and it will slip more often in the future. I'm sorry, but I just don't share your plans for world domination^W carefree attitude towards letting all sorts of potential nightmares into the incubator. There's always talk about one company or the other controlling the ASF - and with people getting paid to mentor, people putting their names on a project as mentors without even bothering to vote for it and with companies dumping code and a very large number of "committers" on us, who's to blame people for speculating like that? > I am concerned that we may permit PPMCs who view it as their right to refuse > access to people who have actively contributed in the past and want to > continue contributing because they don't like them personally or their > employer or feel that they are not leadership material. Those aren't > grounds for barring access. -- justin No more or no less than it would be in a non-incubating project. If you see any hints of that, that should be fixed by hitting the mentor with a very large cluestick, not by leaving the doors open for everyone else to abuse as they see fit. just my $.02 vh Mads Toftum -- http://soulfood.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] accept UIMA as a podling - #2
[X] +1 Accept UIMA as an Incubator podling (binding) - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
