incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <brett.por...@gmail.com>
Subject Re: Is deciding the destination up front a mistake? (Was: Let's rewind!!!)
Date Sat, 04 Feb 2006 00:11:31 GMT
On 2/4/06, Sam Ruby <rubys@apache.org> wrote:
> This discussion would be a lot easier if it were of the form "here's
> code that I would like to see at the ASF, and I'd like to participate
> and make use of it in the following manner... independent of where the
> code ends up".
>
> But as it stands, the discussion to date gives the appearance that a
> number of people are more interested in where this code ends up than in
> the code itself.

These were my thoughts exactly reading the earlier threads. It's
amazing that everyone seems to accept that its a good idea and yet its
stalled on the destination. FWIW, I thought Bill's explanation of how
the destination was selected was great.

So, is selecting the destination up front a bad idea? I don't see how
it should ever matter unless the destination excludes someone (which
is a different problem!)

How about listing potential destinations, and reasons some aren't
potential destinations? Then those that want to be involved can say so
and the best destination can be selected on exit. It occurs to me that
its not entirely certain whether ServiceMix will be a part of
Geronimo, or a TLP anyway.

The governance becomes entirely the responsibility of the incubator
PMC until it graduates, or forms a PPMC as it decides to target
becoming a TLP. Collaboration starts on general@incubator until a dev
list is formed for the thing being incubated itself.

As a step by step process, this would be:
1. proposal for new code (no matter how big or small) sent to
general@incubator.
  * Discussion of potential destinations (existing or new TLP) and
reasons (discussion may have already occurred at other projects to
evaluate this, like the Agila example above).
  * At least one member/officer champion is required.
  * Should specify whether it attempts to build a community around
code (Mentors required), or send the code directly to a specified
project's existing community (recent examples are the Maven
subprojects, or commons-csv).

2. ASF-wide feedback on it, including appropriateness of destinations
and possible additions

3. Vote to accept it. (I'm not sure what the metric on acceptance is
here - is it three +1's from the PMC, vetoable, or majority?)

4. software grant sent, clas filed.

5. Once paperwork is confirmed by the champion, code can be imported.
Champion role ends

6. IP clearance needs to be worked through in parallel with other
work, and a top priority. If this is cleared and there was a known
destination and no need to build a new community, then "graduation" to
the project can proceed. I expect this should require a vote on
general@incubator again and require binding votes from both the
incubator and destination PMC. Last chance for people to oppose the
destination.

7. If agreed goal is to try to build a new community, setup a dev list
and move collaboration there. Everyone is welcome to come and take
part.

8. If at some point the community decides it will be a TLP (this may
have been at inception), a PPMC is established for governance.

9. At some point, there is sufficient stability in the project to
graduate. If this is already determined to be to a TLP, then the
normal resolution goes to the board. If the community decides there is
another TLP they are best suited to, then they vote to go there as in
step 6. If they don't agree, then they aren't ready :)

I don't think this is drastically different to now, but having
explicit steps with everyone having a chance to give feedback before
aligning too much to one group might help.

Feel free to pick holes in it :)

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message