incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Schmidt <>
Subject Re: JDO2 Snapshots
Date Tue, 09 Aug 2005 01:21:18 GMT
On 8/7/05, Jochen Wiedmann <> wrote:
> On 8/7/05, Noel J. Bergman <> wrote:
> > Please note that although we have attempted to establish a balanced policy,
> > it is not our goal to have widespread adoption of projects that are still in
> > the Incubator.  We want projects to be making a focused effort to get out of
> > the Incubator.
> To me, that's a contradiction. "Widespread adoption" will help
> building a community. Which is clearly a primary goal of most projects
> in incubation.

I agree with Jochen on this.  I hesitate to bring this subject up yet
again, but since it has been one of my pet concerns in the past:

There have been times when the Incubator PMC has defined the bar for
graduation to include (in addition to the legal check, the logistics,
and the general Apache-style community) strong user adoption and a
very diverse set of committers.  The "diverse set of committers" has
sometimes been defined as not only the three independent committers,
but also the requirement that no single committer (or single employer
of many committers) is critical to the project.  Obviously it is much
easier to get to this state if the project isn't being limited in what
it can release.  In addition, this requirement for graduation could
take quite a while for some large project, during which time they
might want to actually do an official v 1.0 or 2.0 release.

I have proposed in the past (and gotten consensus) that incubating
projects can do full official releases, as long as they follow the
incubating brand guidelines, which include labeling the download
filenames with the word "incubating" and inserting the disclaimer
statement in the README.  However, many on the PMC would rather not
see formal releases while in incubation; instead, they would rather
see the project graduate sooner without the hard-line requirement for
a strong/diverse user/dev community.

So, here's what it appears we are telling new projects (roughly
sequential phases):
1. ensure there are no legal issues as soon as you enter incubation

2. figure out the logistics of mailing lists, bug tracking, source
repositories, etc at the same time

3. release only snapshot-style distributions as needed, as long as
they follow the incubator branding guidelines.  No official releases
are allowed.  Nothing that resembles a normal Apache product release.

4. bring on enough committers to ensure there are at least three
working for independent interests (the releases described in 3. should
be enough to get this point done)

5. ensure you've built a healthy user and developer community. 
Healthy user community = some user interest manifesting itself on a
mailing list.  Healthy developer community = evidence of following a
consensus-based, meritocratic development style and responding to the
user community, but no requirement that one committer (or many
committers working for one employer) can't be doing 95% of the

6. after making sure any remaining issues on the incubation checklist
are complete, request graduation.

Note that 1-6 must happen before the project's user/dev community
feels it's time to put out an official release.  IMO, if the Incubator
PMC intends for step 5 to be defined in stronger terms, we need to be
a little more flexible with projects that want to do releases.


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

View raw message