Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Sat, Mar 2, 2013 at 2:08 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: ...I suppose if a new product + its community want to become part of a PMC, coding could happen under that PMC (so for example: in a branch of their repository, releases require 3 +1's by that PMC), but with IPMC or comdev watching from the sidelines and helping if needed As Greg says, neither IPMC or comdev have staff, so watching from the sidelines is a very vague concept. OTOH, a PMC could very well ask individuals to sign up as community mentors temporarily (and probably recruit them here) to keep an eye on such things. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
I suppose if a new product + its community want to become part of a PMC, coding could happen under that PMC (so for example: in a branch of their repository, releases require 3 +1's by that PMC), but with IPMC or comdev watching from the sidelines and helping if needed. Over at Subversion we once solicited comdev input on a community issue surrounding a potential GSoC volunteer. That's the same pattern: coding parts handled by the TLP and advice on community issues by comdev|incubator. Mattmann, Chris A (388J) wrote on Sat, Mar 02, 2013 at 05:02:37 +: Hi Niall, and Greg, Just to echo Greg, +1, yes would have preferred it to have happened in the existing community then. Also, agree with Greg -- exceptions can be permitted from time to time, but I don't think graduation into existing TLP should be an accepted norm. Cheers, Chris On 3/1/13 8:55 PM, Greg Stein gst...@gmail.com wrote: On Mar 1, 2013 8:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Yup. The Incubator doesn't have staff. It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Wed, Feb 27, 2013 at 1:21 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Dave, On 2/26/13 4:18 PM, Dave Fisher dave2w...@comcast.net wrote: This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. Please name me a specific example scenario in which #1 has happened at the ASF without pre stated intent to join that TLP. Sanselan graduated to Apache Commons is an example of this. Niall I would be very surprised to see it happen b/c it would imply graduation into an existing TLP wasn't premeditated. That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Niall I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns. Cheers, -g On Feb 26, 2013 4:19 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Luciano, On 2/26/13 12:03 PM, Luciano Resende luckbr1...@gmail.com wrote: +1, We don't need to discuss exit criteria before entering incubation. Actually we do and I can. Else I'm pretty useless on the IPMC. I just went through an experience where my objection/VOTE didn't really mean anything in a situation that I didn't think was correct (see HCatalog/Hive). I will be darned sure to discuss exit criteria now as I wish I would have paid attention and done so then, would have saved hassle all around. And if the Zookeeper PMC wants to adopt Curator as part of the Zookeeper project (see distinction from sub-project language, which is what the Board does not favor), they can work with the community and do it Define working with the community. My definition of that doesn't include entering the Incubator. My definition of that means, Pat or someone else on the ZK PMC starts getting Curator patches and/or committing them and Jordan or Jay become Committers/PMC members on ZK because of those contributions (and have their ICLAs on file, etc.) Having said that, the exit criteria should really be an option instead of being dictated. I'm questioning graduation to an existing TLP (and not as a new one) as a valid exit criteria of the Incubator. I don't think it makes sense. Cheers, Chris - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Mar 1, 2013 8:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Yup. The Incubator doesn't have staff. It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Niall, and Greg, Just to echo Greg, +1, yes would have preferred it to have happened in the existing community then. Also, agree with Greg -- exceptions can be permitted from time to time, but I don't think graduation into existing TLP should be an accepted norm. Cheers, Chris On 3/1/13 8:55 PM, Greg Stein gst...@gmail.com wrote: On Mar 1, 2013 8:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Yup. The Incubator doesn't have staff. It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Feb 26, 2013, at 5:21 PM, Mattmann, Chris A (388J) wrote: Hi Dave, On 2/26/13 4:18 PM, Dave Fisher dave2w...@comcast.net wrote: This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. Please name me a specific example scenario in which #1 has happened at the ASF without pre stated intent to join that TLP. I'll give you a possible - If ODFToolkit fails to have a large enough community then two possible TLPs might be willing to assimilate the community - either OpenOffice or POI. It was specifically intended not to be part of OpenOffice, and two of the podling mentors are POI PMC members. I would be very surprised to see it happen b/c it would imply graduation into an existing TLP wasn't premeditated. Premeditated by the whole of the Initial Committers? No. A thought by one or two people as a Plan B? Yes. A prod to the podling, yes. Each case differs. I can agree that we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP, but I don't think we should exclude a future case should it be strong enough to convince the IPMC. Put another way, we should not decide all policy based only on the latest worst case - Hive/HCatalog. Regards, Dave That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Dave, On 2/27/13 9:44 AM, Dave Fisher dave2w...@comcast.net wrote: [..snip..] Thanks for the examples. Each case differs. I can agree that we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP, but I don't think we should exclude a future case should it be strong enough to convince the IPMC. TL;DR here -- your point above is the one that I am trying to make/echo/make strong (minus the excluding part for me which I'll get to in a sec). Point: we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP That's my entire point, and I think Greg's +1, and Bertrand's +1, etc. Anyone can moan and groan to go even further than that. I've been around the Foundation long enough to know that may take time/effort, etc. YMMV. That said, if another future situation comes up I don't think at least in my current POV that I would be convinced that that's ever good and that's based on my experience first hand being in many situations recently that involved this (Lucene, Hadoop, Nutch, Tika, etc.) The rest of the scenarios are dealt with at a time that there is an actual concrete example by the parties involved that need to be. Until then, we are making conjecture. The outcome I'd like to see is to echo and promote what I've labeled Point: above. Seems I'm not alone. We'll see what happens and you're welcome to your opinion, as I am to mine. Cheers, Chris That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Just trying to understand what is being suggested... Is it that, should a podling decide it can't go for TLP, and that another TLP is prepared to accept them, then effectively the responsibility that the incubator PMC has is transferred to that TLP. *They* need to incubate the new community into its own. The process of creating a new community and integrating one into another are completely different tasks that require differing approaches. Have I got it right? Upayavira On Wed, Feb 27, 2013, at 05:52 PM, Mattmann, Chris A (388J) wrote: Hi Dave, On 2/27/13 9:44 AM, Dave Fisher dave2w...@comcast.net wrote: [..snip..] Thanks for the examples. Each case differs. I can agree that we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP, but I don't think we should exclude a future case should it be strong enough to convince the IPMC. TL;DR here -- your point above is the one that I am trying to make/echo/make strong (minus the excluding part for me which I'll get to in a sec). Point: we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP That's my entire point, and I think Greg's +1, and Bertrand's +1, etc. Anyone can moan and groan to go even further than that. I've been around the Foundation long enough to know that may take time/effort, etc. YMMV. That said, if another future situation comes up I don't think at least in my current POV that I would be convinced that that's ever good and that's based on my experience first hand being in many situations recently that involved this (Lucene, Hadoop, Nutch, Tika, etc.) The rest of the scenarios are dealt with at a time that there is an actual concrete example by the parties involved that need to be. Until then, we are making conjecture. The outcome I'd like to see is to echo and promote what I've labeled Point: above. Seems I'm not alone. We'll see what happens and you're welcome to your opinion, as I am to mine. Cheers, Chris That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? Here is the comment I made in response to your question. Several other board members noted their assent with this statement and none dissented. My understanding is that when a podling wishes to merge into an existing PMC, the decision is up to the recieving PMC, much like any other large contribution. The board provides oversight for this, as with all activity at the ASF. That said, the IPMC provides valuable, relevant and desired input to the board's oversight. Like a podling graduation, the IPMC can recommend action or caution to the board. To my thinking, whether the IPMC wishes to get involved in projects that might join existing PMCs is largely up to the IPMC, not the board. That said, it's sometimes hard to know at the outset whether something will develop into a sufficiently large, independent community or whether its developers might instead end up join an existing, closely related community. I don't see why the IPMC would would want to forbid prospective podlings from mentioning this possibility. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Feb 27, 2013, at 10:42 AM, Upayavira wrote: Just trying to understand what is being suggested... Is it that, should a podling decide it can't go for TLP, and that another TLP is prepared to accept them, then effectively the responsibility that the incubator PMC has is transferred to that TLP. *They* need to incubate the new community into its own. The process of creating a new community and integrating one into another are completely different tasks that require differing approaches. Have I got it right? That seems to be the case. The current BeanShell proposal is sponsored by Commons. If consensus forms around this new rule then Commons needs to be informed that either BeanShell needs to be assimilated directly or it needs to enter incubation with the clear intent of becoming a TLP. Correct? Regards, Dave Upayavira On Wed, Feb 27, 2013, at 05:52 PM, Mattmann, Chris A (388J) wrote: Hi Dave, On 2/27/13 9:44 AM, Dave Fisher dave2w...@comcast.net wrote: [..snip..] Thanks for the examples. Each case differs. I can agree that we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP, but I don't think we should exclude a future case should it be strong enough to convince the IPMC. TL;DR here -- your point above is the one that I am trying to make/echo/make strong (minus the excluding part for me which I'll get to in a sec). Point: we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP That's my entire point, and I think Greg's +1, and Bertrand's +1, etc. Anyone can moan and groan to go even further than that. I've been around the Foundation long enough to know that may take time/effort, etc. YMMV. That said, if another future situation comes up I don't think at least in my current POV that I would be convinced that that's ever good and that's based on my experience first hand being in many situations recently that involved this (Lucene, Hadoop, Nutch, Tika, etc.) The rest of the scenarios are dealt with at a time that there is an actual concrete example by the parties involved that need to be. Until then, we are making conjecture. The outcome I'd like to see is to echo and promote what I've labeled Point: above. Seems I'm not alone. We'll see what happens and you're welcome to your opinion, as I am to mine. Cheers, Chris That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns. Cheers, -g On Feb 26, 2013 4:19 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Luciano, On 2/26/13 12:03 PM, Luciano Resende luckbr1...@gmail.com wrote: +1, We don't need to discuss exit criteria before entering incubation. Actually we do and I can. Else I'm pretty useless on the IPMC. I just went through an experience where my objection/VOTE didn't really mean anything in a situation that I didn't think was correct (see HCatalog/Hive). I will be darned sure to discuss exit criteria now as I wish I would have paid attention and done so then, would have saved hassle all around. And if the Zookeeper PMC wants to adopt Curator as part of the Zookeeper project (see distinction from sub-project language, which is what the Board does not favor), they can work with the community and do it Define working with the community. My definition of that doesn't include entering the Incubator. My definition of that means, Pat or someone else on the ZK PMC starts getting Curator patches and/or committing them and Jordan or Jay become Committers/PMC members on ZK because of those contributions (and have their ICLAs on file, etc.) Having said that, the exit criteria should really be an option instead of being dictated. I'm questioning graduation to an existing TLP (and not as a new one) as a valid exit criteria of the Incubator. I don't think it makes sense. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. 2. If an existing TLP wants to incorporate an existing non-Apache community, the incubator _might_ might serve a useful role. Or, not. I'm also perfectly happy to tell that TLP to make a branch and grant some commit access and vote status as appropriate as things proceed, which is how I'd restate your views. 3. We do have a group of people with some minimal, observed, willingness to pay some attention to IP clearance. Legal affairs, well, is more of a talking-shop. So I'd expect Sam to want some helpers before he'd accept this. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Benson, On 2/26/13 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? And it was my point during the whole HCatalog thing too. And Greg's when it was discussed during the board meeting. So yes, I think that's what we're discussing here. I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). 2. If an existing TLP wants to incorporate an existing non-Apache community, the incubator _might_ might serve a useful role. Or, not. I'm also perfectly happy to tell that TLP to make a branch and grant some commit access and vote status as appropriate as things proceed, which is how I'd restate your views. Right, not sure the views need restating. I think they've been stated fairly clearly so far. 3. We do have a group of people with some minimal, observed, willingness to pay some attention to IP clearance. Legal affairs, well, is more of a talking-shop. So I'd expect Sam to want some helpers before he'd accept this. How about we start letting people talk for themselves? I sense an inclination at least in this email to not do that :) Cheers, Chris -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, On 2/26/13 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? And it was my point during the whole HCatalog thing too. And Greg's when it was discussed during the board meeting. So yes, I think that's what we're discussing here. I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). Chris, I am now confused. If a podling bogs down, and then finds that there is a congenial home for the code in an existing project, what's your desire? My suggestion that the existing project just adopt them with no formal graduation? Something else? 2. If an existing TLP wants to incorporate an existing non-Apache community, the incubator _might_ might serve a useful role. Or, not. I'm also perfectly happy to tell that TLP to make a branch and grant some commit access and vote status as appropriate as things proceed, which is how I'd restate your views. Right, not sure the views need restating. I think they've been stated fairly clearly so far. 3. We do have a group of people with some minimal, observed, willingness to pay some attention to IP clearance. Legal affairs, well, is more of a talking-shop. So I'd expect Sam to want some helpers before he'd accept this. How about we start letting people talk for themselves? I sense an inclination at least in this email to not do that :) Sorry. Point taken. Cheers, Chris -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ... +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here?... I missed the last board meeting, dunno if this was discussed - I was just expressing my personal opinion here. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 2:58 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, On 2/26/13 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? And it was my point during the whole HCatalog thing too. And Greg's when it was discussed during the board meeting. So yes, I think that's what we're discussing here. I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). Chris, I am now confused. If a podling bogs down, and then finds that there is a congenial home for the code in an existing project, what's your desire? My suggestion that the existing project just adopt them with no formal graduation? Something else? This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. 2. If an existing TLP wants to incorporate an existing non-Apache community, the incubator _might_ might serve a useful role. Or, not. I'm also perfectly happy to tell that TLP to make a branch and grant some commit access and vote status as appropriate as things proceed, which is how I'd restate your views. Right, not sure the views need restating. I think they've been stated fairly clearly so far. 3. We do have a group of people with some minimal, observed, willingness to pay some attention to IP clearance. Legal affairs, well, is more of a talking-shop. So I'd expect Sam to want some helpers before he'd accept this. How about we start letting people talk for themselves? I sense an inclination at least in this email to not do that :) Sorry. Point taken. Cheers, Chris -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - 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 -- 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Feb 26, 2013, at 3:18 PM, Luciano Resende wrote: On Tue, Feb 26, 2013 at 2:58 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:22 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, On 2/26/13 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? And it was my point during the whole HCatalog thing too. And Greg's when it was discussed during the board meeting. So yes, I think that's what we're discussing here. I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). Chris, I am now confused. If a podling bogs down, and then finds that there is a congenial home for the code in an existing project, what's your desire? My suggestion that the existing project just adopt them with no formal graduation? Something else? This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. (3) Receiving PMC votes on each podling Committer and PMC separately (or in a group if no objections.) (4) IPMC says thanks! (5) Podling is now a product within a TLP. Regards, Dave 2. If an existing TLP wants to incorporate an existing non-Apache community, the incubator _might_ might serve a useful role. Or, not. I'm also perfectly happy to tell that TLP to make a branch and grant some commit access and vote status as appropriate as things proceed, which is how I'd restate your views. Right, not sure the views need restating. I think they've been stated fairly clearly so far. 3. We do have a group of people with some minimal, observed, willingness to pay some attention to IP clearance. Legal affairs, well, is more of a talking-shop. So I'd expect Sam to want some helpers before he'd accept this. How about we start letting people talk for themselves? I sense an inclination at least in this email to not do that :) Sorry. Point taken. Cheers, Chris -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - 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 -- 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
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Benson, On 2/26/13 2:58 PM, Benson Margulies bimargul...@gmail.com wrote: [..snip..] I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). Chris, I am now confused. If a podling bogs down, and then finds that there is a congenial home for the code in an existing project, what's your desire? My suggestion that the existing project just adopt them with no formal graduation? Something else? If a podling bogs down, and then finds there is a congenial home in an existing project, I would have the following questions: To the TLP and to the Incubator community: 0. What does bogged down mean? Needs specific definition. 1. Did the podling propose to assimilate into TLP? a. If so, why did it have to bog down before getting TLP interested? b. If not, then why show up as a TLP when the podling bogged down and then assimilate? I would hope it's not for skirting IP issues, or something else like that? Also, to borrow from Sam Ruby, I prefer not to speak in hypotheticals, but to speak from actual examples, so can you point to a situation when this has happened either recently or at all? (I'll use a specific one below) To the TLP 1. Do you care about the size of the podling? If it's a fairly substantial contribution, I would wonder how the TLP could assimilate the codebase, and would worry about putting that type of burden on the PMCs. We don't ask our PMCS to take on code clearing, and IP. And to be honest, if we are asking our PMCs to do that, why do we have the meta committee of the Incubator again? To the podling 1. Why choose the TLP now? I would imagine if a podling got bogged down then the act of choosing a TLP to accept it would have been premeditated and not out of the blue. So, yes, with those questions above, I still don't think that Incubator-existing TLP is a valid exit. Let's take HCatalog as an example. I don't support that for many of the reasons previously stated. I see that not as them getting bogged down, but simply that's what they had planned from the beginning. However, what I questioned (and still question to this day) was the means of executing that plans. They didn't intersect (or union) the PMC of Hive and the PPMC of HCatalog. They induced bylaws to deal with it in Hive, and then went their separate way into Hive. Greg and the board discussed this on the last board call. I don't think that this specific example is a good one to set -- I was on the board call for the first 30 mins, but I missed this part of the discussion. So, I'm not going to speak for those on the board call RE: this subject. My personal opinion is that that specific example should *not* be allowed to happen anymore and that the Hive/HCatalog integration should also be watched to make sure those PMCs are unioned (or intersected) very soon. Let's take Curator as an example now. Put simply if the intention of Curator is to form a *new* TLP, I'm +1 on its entry into the Incubator. If there is some contingent that thinks Curator can become part of the ZK project as a product or some other form of the community, then I am -1 on Incubation for Curator. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Dave, On 2/26/13 4:18 PM, Dave Fisher dave2w...@comcast.net wrote: This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. Please name me a specific example scenario in which #1 has happened at the ASF without pre stated intent to join that TLP. I would be very surprised to see it happen b/c it would imply graduation into an existing TLP wasn't premeditated. That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Feb 26, 2013, at 5:21 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Dave, On 2/26/13 4:18 PM, Dave Fisher dave2w...@comcast.net wrote: This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. Please name me a specific example scenario in which #1 has happened at the ASF without pre stated intent to join that TLP. I'm going to date myself an make myself feel old, but: Yoko Originally, Yoko was planning to be a TLP. However, the entire CORBA space kind of died and the original company involved with donating the code more or less withdrew support. However, by then Geronimo had taken it as an important dependency and a few of the Geronimo folks had started contributing fixes and stuff to it.Some CXF users were using the web service parts of it. However, the community itself really couldn't get enough traction. (partially because it was a split community between the ORB folks and the WS folks). Thus, instead of graduating to TLP, it kind of split with the ORB going to Geromino and the WS bits being assimilated into CXF's main build. So, it the community didn't completely die. Incubation wasn't really a failure. The incubation efforts really showed that it should have been parts of the existing TLPs. Dan I would be very surprised to see it happen b/c it would imply graduation into an existing TLP wasn't premeditated. That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
0. What does bogged down mean? Needs specific definition. Chris, This is the point in the conversation where I hear the voice of Ross calling me justly to account for wasting people's time by writing too quickly. So I will try to atone by clarification. I think that we are all starting from the observation that umbrellas are no more, and so we never, ever, should be planning on a subproject. From that starting point I see two topics of conversation here. Topic 1: Should the IPMC have a role in a planned process in which an existing TLP absorbs an external community? On other words, should we ever accept a podling with the _intention_ that it will graduate by absorption into an existing TLP? You and Greg are strongly opposed to this. I'm +0. Which means that I see no harm in accepting this Curator process now, and continuing discussion. Topic 2: What should the incubator flow chart have to say about 'stalled' podlings? So, let me define the terms of this discussion as I see them. We do not want to see podlings that malinger in the incubator indefinitely. If a podling is too small to be a viable TLP, and has little prospect of growth, we want to see some sort of exit. Obviously, retirement is an option. The argument, if any, is about a retirement alternative of 'absorption by another TLP.' We've been known to send email to podlings suggesting that they shop around for this possibility. I suggest that this option is _formally_ equivalent to the following three steps: a: the podling retires (source RO, issues RO, mailing lists RO) b: a TLP does 'svn cp' to absorb the source code c: a TLP, sooner or later, votes to grant members of the defunct podling committer status So, the question is: are we helping anyone or anything by describing this as a normative part of the process, albeit probably a rare one? So, now that I've written all this, I find myself, again, +0. If any combo of the board and my fellow PMC members prefer to represent the flow as a simple choice between graduation and retirement, and manage this as per my steps above, that's really OK with me. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
