incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Factors for Graduation (Was Re: [discussion] Harmony podling to ask for vote for graduation)
Date Thu, 19 Oct 2006 09:58:45 GMT
I'm not dismissing the importance of Greg's concern, and am not trying 
to take the Harmony conversation down a rat-hole (or different rat-hole 
in this case...), so I changed the Subject line.


Let me take a brief side trip here about [Unwritten] Incubator 
Graduation Requirements....

Isn't this a bit open ended, in that you can always choose some 
important and common aspect of Apache project life and ask if the 
podling has done it?

1) Has the podling shown they can deal with technical dissent on a commit?

2) Has the podling shown they can deal with two competing solutions to a 

3) Has the podling shown they can deal with an emergency security patch 
to a release?

4) Has the podling shown they can deal with a troll on the user list?

5) Has the podling shown they can deal with resignation from the PMC?

6) Has the podling shown they can deal with a downstream consumer 
abusing the podling name/trademark?

7) Has the podling shown they can deal with a "revolutionary" fork 
inside the podling?

8) Has the podling shown they can deal with mistakes in accepting 
contributions or including 3rd party dependencies?

9) Has the podling been able to work with outside communities in a 
productive manner that shines a positive light on the ASF?

10) has the podling been able to police itself in terms of ensuring 
civil and non-personal (other than friendly) discourse among the 

11) has the podling been able to demonstrate the ability to work closely 
  and productively with other Apache projects/podlings?

12) Does the podling have an established and well-understood pattern for 
voting on issues?

13) Has the podling had to deal with legitimate/illegitimate 
interruption of that standard voting pattern?

14) Has the podling added committers?

15) Has the podling grown the PPMC?

FWIW, Harmony has dealt peacefully and successfully with 1, 2 (two math 
and two RMI impls, we chose based on technical merit), 4, 7-ish 
(committer had to prove a concept to internal skeptics), 8 (j.u.c went 
to wrong place in our SVN - it doesn't have cleanroom provenance), 9 
(our interaction with MX4J, SableVM), 10, 11 (our engagement with Yoko 
to provide our CORBA impl - in fact, a Harmony committer also earned 
commit on Yoko), 12 (in spades) 13 (legit), 14, 15

I think it would be absurd to require a podling to have to check all of 
these boxes, but they are important things, just as important as a 
release, and arguably happens far more often than a release.  And the 
skills that help a podling navigate the above list, are the same skills 
that come into play in a release.

What I look for in podlings is a sense of "Do I reasonably believe that 
the community be able to independently deal with things like this 
(including releases) in their future life as a TLP?"

And yes, I have and will again make mistakes - it's a judgment call - 
which is why there are more than one set of eyes on these things...


Greg Stein wrote:
> Without question, Harmony knows how to manage its legal bits. Can the
> community navigate through all those hurdles and processes and other
> shtuff to actually produce a release? Is this community set up to
> produce releases, or is it set up to check off legal paperwork?
> I know there are many individuals participating in Harmony who have
> done *dozens* of releases of various products here at Apache. But can
> they get the community to produce a (developer) release of Harmony?
> For example, I think about all the hell the Tomcat community went
> through with the whole v3 versus v4 versus v5 debates. Or Geronimo
> trying to figure out what v1.2 meant. Or Avalon trying to get a
> release out. Or httpd finding it
> On 10/19/06, Leo Simons <> wrote:
>> On Oct 17, 2006, at 4:30 PM, Daniel Kulp wrote:
>> > I don't have a binding vote, but my thought is Harmony has the
>> > same "issue" as Felix: namely they haven't done a release or provided
>> > even a "test release" to the IPMC so the IPMC can be sure the podling
>> > knows the proper way to do a release and understands and can
>> > correct all
>> > the issues such as proper apache licensing, etc...    Basically, make
>> > sure the podling can get all their "Apache Legal Ducks in a Row."
>> This is a good point, and thanks for raising it. I'll now try and
>> take away your concern, and everyone elses, on this point.
>> As one of harmony's mentors, I'm confident that harmony has more
>> legal ducks than most apache projects, and has them more precisely in
>> row that most, and that this is only the case because of a community
>> with outstanding "legal awareness".
>> Harmony started with precisely 0 committers, and 6 months of legal
>> talks. Its processes and policies are, IMHO, more "secure" and
>> "safe" (paranoid!) than those of any other project at apache. They
>> were like that before we seriously started adding committters. Each
>> committer was added only after a vote on the PPMC. Each person on the
>> PPMC was only added after a vote by the PPMC. Each big outside
>> contribution was internally vetted and discussed on the development
>> list extensively, and then explicitly voted in by the PPMC, with the
>> PPMC demonstrating time and time again to be fully aware of all the
>> legal gotcha's.
>> I haven't bothered counting, but I'm confident that the harmony PPMC
>> as well as its development community have done over 30 "important"
>> votes on issues with potential legal implications (at harmony, almost
>> anything besides a simple patch has potential legal implications, but
>> accepting 500,000 lines of source code and merging it into the
>> repository certainly does).
>> Harmony even had an issue at some point (which I'm sure the incubator
>> PMC can remember, since it was kept up-to-date on private@) where an
>> external contribution we received (by an individual not associated
>> with any of the "big companies" that have salaried people
>> contributing to harmony) could possibly be a licensing infringement
>> on an existing third party open source project, and managed to
>> resolve that in what I would argue is very much the best way possible
>> (not only resolving any potential licensing mess, but building what
>> seem to be becoming healthy and permanent ties with the third party
>> open source project). So harmony even has a legal duck in its row
>> that most apache projects have never ever had to deal with.
>> I'm expecting harmony will have to deal with more issues like this
>> before (and after) it issues a 1.0 final release, and I'm also
>> expecting harmony to be able to deal with it.
>> > Looking at the latest snapshot downloaded from the website, there
>> > definitely are some things missing.  (mainly, stuff missing from the
>> > META-INF of all the jars)
>> LICENSE and NOTICE files should go into all files that one would
>> consider distributing seperately. Harmony is not going to be
>> distributed in pieces, with individual jars ending up at ibiblio,
>> harmony is going to be distributed as a JDK (and as a HDK, but that's
>> a detail). Just like, for example, the Sun JDK, the license file
>> therefore doesn't end up inside the JDK-provided jars, but at the top
>> level of the JDK distribution.
>> > Anyway, I think Harmony should first go through the process of
>> > preparing a
>> > release and get it OK'd by the IPMC.   There is a LOT a podling can
>> > learn
>> > while going through that process.    Since Felix was "asked" to
>> > create a
>> > sample release, I would expect Harmony should do the same.
>> This is normally true. As a mentor (being well aware of the "do a
>> release before graduation" incubator guideline, even if
>> undocumented), I made the assertion that the harmony community
>> wouldn't learn anything significant from it. Since harmony also has
>> other concerns when it comes to release management (like purposefully
>> staying under the radar and not generating much press noise), its
>> actually much healthier for harmony not to go through the release
>> motions right now.
>> When harmony later on, as a TLP, will have to do a proper release,
>> rest assured that such an effort will be subject to a lot more
>> scrutiny than is typical for apache projects, by virtue of having to
>> pass a TCK, having to dance around known patents, etc.
>> cheers,
>> LSD
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message