Greg Stein wrote:
> Noel J. Bergman wrote:
> > I agree that when a project is expected to merge into an existing
> > TLP, we need a more collaborative and streamlined relationship
> > with the existing community.
> Sure. The PPMC thing is looking like that should help.
I agree. In fact, I think the PPMC makes this whole process work better,
and reduces substantially the various policies and procedures that we just
argued over some months ago.
The PPMC should be easy for everyone to understand with respect to projects
aiming for TLP status. The questions seem to be related to other
situations. And although the Board's intent seemed clear after reading the
mailing list archives, the resolution, itself, isn't as clear:
> establish a Project Management Committee charged with accepting new
> products into the Foundation, providing guidance and support to help
> each new product engender their own collaborative community
> [...]
> and proposing to the board the promotion of such products to
> independent PMC status once their community has reached maturity.
Some people are reading that last sentence to imply that the Incubator is
only for projects intended to have an independent PMC.
> Individual PMCs should be *very* wary about bringing in code to the ASF.
> There is a grey area between "a hunk of code" and a new "product" (that
> term was used to differentiate between "project" as in PMC).
The Incubator's role doesn't always seem obvious in some cases, and is
resisted in others, so if you don't mind, what are your thoughts on some
illustrative examples:
- HiveMind. Developed within the ASF CVS in Jakarta Commons. Off-line,
pending a software grant from the company that funded it. What should
happen, with respect to the Incubator, when the software grant is received?
- Wagon. As I understand it, developed by Jason van Zyl and others.
Possibly originally here, then later at codehaus, and now back here. All
people either were or now are Apache Committers. Now part of the Maven
project, as a separately developing entity.
- FtpServer. I could be wrong, but for the sake of argument, let's assume
I am correct. An ASF developed project with (currently) no home because its
previous PMC divested itself of non-essential code.
- Cornerstone. Not the Avalon code. A new codebase from CISCO that was
merged into the Jetspeed-2 module. Same mailing list and build process.
Not a new "subproject" (no new mailing list or community), but a substantial
codebase, which some people have suggested might be a future TLP. The
Jakarta PMC has asked Jetspeed to ask CISCO for a software grant.
- jUDDI. An externally developed codebase and community. Intended to be a
part of Web Services. They rightly want to integrate it into their
Community.
These are just representative of various situations.
Wherever the decision is made that the project belongs in the Incubator, I
think that we have a clear and simple approach: we establish a PPMC under
the auspices of the Incubator PMC, consisting of the Incubator PMC, the
destination PMC (if any) and the new committers. That is the effective PMC
for this project, which reports through the Incubator PMC to the Board
regarding the project's STATUS.
In the case of projects where the destination PMC says that it wants to do
its own Community Building, and integrate their newly enlarged membership,
they can just do it. They can do whatever they want, within ASF guidelines,
as part of the PPMC. However, adding code to the Foundation requires a
consensus vote. That implies two things in particular: (1) there cannot be
a release by an Incubator project without a consensus vote, and (2) a
project cannot leave the Incubator without a consensus vote.
The requirement that the Incubator clear the IP on behalf of the Foundation
was an important part of the Incubator discussion on the Board mailing list,
so I understand that the intent is there, but teasing it out of the
resolution is non-trivial, except perhaps to a lawyer ;-). As I understand
it, it is implied by the phrase "accepting projects into the Foundation";
that important clause may have been too subtle in its expression. Accepting
that the Incubator is exclusively chartered by the Board to clear the IP of
incoming projects, then I think that the PPMC still has us covered.
It seems to me that clearing IP need not be any more difficult than it takes
to record software grants, corporate and individual CLAs, eliminate
dependencies on non-compatible licenses, etc. We should prepare a form for
clearing IP, which can be filled in by the PPMC, and then signed off on with
a consensus vote. In many cases, that will be the major hurdle towards
leaving the Incubator.
In terms of resources, and considering existing projects to be
grandfathered, so that we don't have to argue over changing things, what
should be normative? I would not mind putting the mailing list (except for
the PPMC, which would always be in the Incubator) in the final location, so
that we don't have to relocate it (and especially the eyebrowse archives),
but the CVS module and the web address should be prefixed by the Incubator.
Once the project is promoted, those two resources are easy to adjust. The
PPMC can decide on any exception.
How does this sit, in terms of meeting the goals that Nicola Ken was trying
to meet, while preserving the mandate from the Board?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
