incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Sub-projects - when are they acceptable? (was Re: [VOTE] Graduate Nuvem as a sub-project under Apache Tuscany)
Date Wed, 21 Nov 2012 17:19:58 GMT
On Wed, Nov 21, 2012 at 9:07 AM, Franklin, Matthew B.
<> wrote:
> On 11/21/12 7:26 AM, "Benson Margulies" <> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message