On Wed, Nov 21, 2012 at 9:07 AM, Franklin, Matthew B. <mfrank...@mitre.org> wrote: > On 11/21/12 7:26 AM, "Benson Margulies" <bimargul...@gmail.com> wrote: >... >>So, permit me to ask another, related, question. It seems to me that >>the IPMC is concerned with the fact that a project is ready to leave, >>but not so much which where it is going. A proposal to form a new TLP >>is, I think, a straightforward question to the board, and the IPMC's >>action is to make a recommendation to the board. >> >>A proposal to be integrated into an existing project is, I think, >>within the authority of the existing product's PMC. If Project A >>wishes to invite the members of Podling B to join and integrate their >>code, then this looks to me like it could just happen without any >>approval in advance from the board or even the IPMC. Voting in >>committers is a PMC task, voting in PMC members is a PMC task with >>board lazy approval, and copying (ip-cleared) code from one place in >>ASF source control to another is a PMC task. >> >>I think that IPMC graduation votes in this case are a nice thing, but >>it seems by this logic that they are not necessary. >> >>Does this make sense? > > I think your statement makes sense, but I see the votes as a way for IPMC > members to assert that they believe all due diligence in IP clearance has > been performed and that a sanity check has been done as to whether or not > the podling is to be fully integrated into the PMC of the target project. > From this perspective the Incubator serves to provide a convenience to the > target PMC in regards to releasability of code they are assuming and as a > foundation preventative measure for ensuring we don't end up with massive, > disconnected umbrellas comprised of former incubator podlings.
I'm with Matt: the vote is still needed to state "this community/code can be moved into the ASF". And if the code is moving to an existing community, then the Board does not need to be involved. However, I will state the recipient PMC better issue a Board report *that month*, whether it is on their normal reporting schedule or not. Activities like that is something that needs to be very visible. (the Board would see it in the Incubator report, but it should also hear from the recipient PMC) On the general sub-project thing: I agree with the thread's seeming consensus: one community managing several projects is fine. Separate communities (as Arun laments about Hadoop) is a problem. On a minor technical note: I don't believe PMCs should be slicing up their svn access control lists. Every committer/PMC-member should be able to change all the code under that PMC's responsibility. Cheers, -g --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
