You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Xavier Hanin <xa...@gmail.com> on 2007/06/07 08:29:26 UTC

Steps toward graduation (was Re: Report this month)

On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> [...]
>
I also would like to see where we should do better,  what do we need
> to enhance, what is still missing to be graduated.  I have 2 ideas
> (having a wider community, having a roadmap), but I guess a mentor
> could say more about that.


I think it's a good time to start a discussion about what remains to do
before graduation. If we look at the graduation guide [1] and exit policies
[2], it seems we are on a good way.

If I take the whole list from the exit policies document, here is what I
consider ok:

   - *Legal *
   -
      - All code ASL'ed
      - The code base must contain only ASL or ASL-compatible
      dependencies
      - License grant complete
      - CLAs on file.


   - *Meritocracy / Community*
   - ASF style voting has been adopted and is standard practice


   - *Alignment / Synergy *
   -
      - Use of other ASF subprojects
      - Develop synergistic relationship with other ASF subprojects


   - *Infrastructure *
   -
      - SVN module has been created
      - Mailing list(s) have been created
      - Mailing lists are being archived
      - Issue tracker has been created
      - Project website has been created
      - Project is integrated with GUMP if appropriate
      - Releases are PGP signed by a member of the community
      - Developers tied into ASF PGP web of trust

---------------------------------------------------------------------------------
Here is what I consider we still need to do:

   - *Legal *
   -
      - Check of project name for trademark issues [A]


   - *Meritocracy / Community *
   -
      - Release plans are developed and excuted in public by the
      community. [B]
      -
         - (requirement on minimum number of such releases?)
         - Note: incubator projects are not permitted to issue an
         official Release. Test snapshots (however good the quality)
and Release
         *plans *are OK.
      - Incubator PMC has voted for graduation [C]
      - Destination PMC, or ASF Board for a TLP, has voted for final
      acceptance [D]

[A] I don't know how this can be checked. Any idea?

[B] We have done one release in the incubator, but we have no current
release plan. This is something that we need to discuss in a separate
thread.

[C] and [D] this will be done only when all other points will be addressed.
One point we will have to discuss before these votes is the destination:
should we try to graduate as a top level project or as a sub project of Ant
(our sponsor). This is also something that deserves its own thread for
discussion.

---------------------------------------------------------------------------------
And here is what I don't clearly know what to think:

   - *Meritocracy / Community *
   -
      - Demonstrate an active and diverse development community [A]
      - The project is not highly dependent on any single contributor
      (there are at least 3 legally independent committers and there
is no single
      company or entity that is vital to the success of the project) [B]
      - The above implies that new committers are admitted according
      to ASF practices [C]
      - Demonstrate ability to tolerate and resolve conflict within
      the community. [D]
      - Engagement by the incubated community with the other ASF
      communities, particularly infrastructure@ (this reflects my personal bias
      that projects should pay an nfrastructure "tax"). [E]

[A] From my point of view we demonstrate an active and diverse development
community. We have 3 committers from 3 different companies, 170+ mails
exchanged on the dev mailing list per month since March [3], and 11
contributors since our entry in incubation. But it's difficult to know what
is an active and diverse development community, if we compare to wicket we
are still far away.

[B] This point is difficult to evaluate for me. As the creator of the
project, I have some knowledge of the code base and history of the project
that is not easy to catch up with. But we've seen several contributions and
fixes dealing with some difficult part of the code base (like the dependency
resolution engine), and work has been done to make the code base cleaner and
easier to understand. So my IMHO the project is not highly dependent on any
single contributor, but I'd like to ear from other voices.

[C] I think this point doesn't really need discussion, Gilles was admitted
according to ASF practices.

[D] This point is not easy to address. I propose we start a flaming war in
the coming days and agree after a few days :-) Joke apart, I don't think we
have had any conflict so far in the community. Does it mean that we will
have troubles to resolve them, or simply that we are all tolerant enough to
avoid conflicts. It's difficult to say, but I don't think this is a major
drawback for our community.

[E] I think we have some kind of engagement, it's difficult to know if this
is enough. We participate to some discussions on the ant, incubator and
repository mailing lists. I think we have also some contacts with the
commons-vfs project, and the maven project too. On the infrastructure, it
was more asking for things (like the migration of JIRA) than contributing,
but it's difficult to actively contribute without any karma. So, can we
consider this point adressed?

So it seems we are on a pretty good way toward graduation. I'll start two
thread about release plan and  destination.
Any input on the points above are welcome from the whole community, so feel
free to give feedback even if you are not a committer or mentor.

Xavier

[1] http://incubator.apache.org/guides/graduation.html
[2]
http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
[3] http://mail-archives.apache.org/mod_mbox/incubator-ivy-dev/

RE: Steps toward graduation

Posted by Gilles Scokart <gs...@gmail.com>.
I like how the menu expands (the sublevel appears progressively).
I didn't test the doc generation (I don't have a jdk 1.6 on my machine :-().
I notice a problem when I click on "tutorial" (the page, not the arrow), the
menu is not expandable anymore.


By the way:
- Do we still need to generate the doc? (I guess yes, for google.  But there
is maybe other solutions)
- Do you really want to publish the new site.  I'm not sure, but it can
contain doc of things that will only be released in 2.0-alpha-2.

Gilles


> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: mardi 19 juin 2007 9:39
> To: ivy-dev@incubator.apache.org
> Subject: Re: Steps toward graduation
> 
> On 6/12/07, Stefan Bodewig <bo...@apache.org> wrote:
> >
> > On Mon, 11 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
> > > On 6/11/07, Stefan Bodewig <bo...@apache.org> wrote:
> > >>
> > >> On Thu, 7 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
> > >>
> > >> >      - The code base must contain only ASL or ASL-compatible
> > >> >      dependencies
> > >>
> > >> In the case of the non-ASLed JavaScript stuff I'd like to see a
> > >> solution other than "we don't ship it" since legally having
> > >> something in svn means distributing it.
> > >
> > >
> > > I can replace the dependency on ddtree by another js tree
> > > component. We can use jquery [1] and the tree view plugin [2] for
> > > instance. Both are released under a dual GPL and MIT license [3],
> > > and MIT license seems to be compatible with ASL [4]. So, may I go
> > > this way?
> >
> > Yes, the MIT license is compatible with the AL, so which one you
> > choose is a purely technical decision and that I leave up to those
> > who'll have to work with whatever is chosen 8-)
> 
> 
> I've just checked in an upgraded version of xooki which does not rely any
> more on ddtree: I've actually removed the dependency on a tree component,
> recent tree components are usually able to deal with simple ul / li. So in
> our case I've set up a jquery tree (MIT licensed) to manage our tree menu.
> The modification is in svn, could someone try it before I upgrade the web
> site?
> 
> Xavier
> 
> Stefan
> >
> > > [1] http://jquery.com/
> > > [2] http://bassistance.de/jquery-plugins/jquery-plugin-treeview/
> > > [3] http://docs.jquery.com/License
> > > [4] http://wiki.apache.org/jakarta/LicenceIssues
> >
> 
> 
> 
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/


Re: Steps toward graduation

Posted by Xavier Hanin <xa...@gmail.com>.
On 6/12/07, Stefan Bodewig <bo...@apache.org> wrote:
>
> On Mon, 11 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
> > On 6/11/07, Stefan Bodewig <bo...@apache.org> wrote:
> >>
> >> On Thu, 7 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
> >>
> >> >      - The code base must contain only ASL or ASL-compatible
> >> >      dependencies
> >>
> >> In the case of the non-ASLed JavaScript stuff I'd like to see a
> >> solution other than "we don't ship it" since legally having
> >> something in svn means distributing it.
> >
> >
> > I can replace the dependency on ddtree by another js tree
> > component. We can use jquery [1] and the tree view plugin [2] for
> > instance. Both are released under a dual GPL and MIT license [3],
> > and MIT license seems to be compatible with ASL [4]. So, may I go
> > this way?
>
> Yes, the MIT license is compatible with the AL, so which one you
> choose is a purely technical decision and that I leave up to those
> who'll have to work with whatever is chosen 8-)


I've just checked in an upgraded version of xooki which does not rely any
more on ddtree: I've actually removed the dependency on a tree component,
recent tree components are usually able to deal with simple ul / li. So in
our case I've set up a jquery tree (MIT licensed) to manage our tree menu.
The modification is in svn, could someone try it before I upgrade the web
site?

Xavier

Stefan
>
> > [1] http://jquery.com/
> > [2] http://bassistance.de/jquery-plugins/jquery-plugin-treeview/
> > [3] http://docs.jquery.com/License
> > [4] http://wiki.apache.org/jakarta/LicenceIssues
>



-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: Steps toward graduation

Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 11 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
> On 6/11/07, Stefan Bodewig <bo...@apache.org> wrote:
>>
>> On Thu, 7 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
>>
>> >      - The code base must contain only ASL or ASL-compatible
>> >      dependencies
>>
>> In the case of the non-ASLed JavaScript stuff I'd like to see a
>> solution other than "we don't ship it" since legally having
>> something in svn means distributing it.
> 
> 
> I can replace the dependency on ddtree by another js tree
> component. We can use jquery [1] and the tree view plugin [2] for
> instance. Both are released under a dual GPL and MIT license [3],
> and MIT license seems to be compatible with ASL [4]. So, may I go
> this way?

Yes, the MIT license is compatible with the AL, so which one you
choose is a purely technical decision and that I leave up to those
who'll have to work with whatever is chosen 8-)

Stefan

> [1] http://jquery.com/
> [2] http://bassistance.de/jquery-plugins/jquery-plugin-treeview/
> [3] http://docs.jquery.com/License
> [4] http://wiki.apache.org/jakarta/LicenceIssues

Re: Steps toward graduation

Posted by Xavier Hanin <xa...@gmail.com>.
On 6/11/07, Stefan Bodewig <bo...@apache.org> wrote:
>
> On Thu, 7 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:
>
> >      - The code base must contain only ASL or ASL-compatible
> >      dependencies
>
> In the case of the non-ASLed JavaScript stuff I'd like to see a
> solution other than "we don't ship it" since legally having something
> in svn means distributing it.


 I can replace the dependency on ddtree by another js tree component. We can
use jquery [1] and the tree view plugin [2]  for instance. Both are released
under a dual GPL and MIT license [3], and MIT license seems to be compatible
with ASL [4]. So, may I go this way?

[1] http://jquery.com/
[2] http://bassistance.de/jquery-plugins/jquery-plugin-treeview/
[3] http://docs.jquery.com/License
[4] http://wiki.apache.org/jakarta/LicenceIssues

> Here is what I consider we still need to do:
> >
> >   - *Legal *
> >      - Check of project name for trademark issues [A]
> >
> >
> >   - *Meritocracy / Community *
> >      - Release plans are developed and excuted in public by the
> >      community. [B]
>
> > [A] I don't know how this can be checked. Any idea?
>
> If you use a search engine for "trademark search" you'll find several
> national authorities.  Most of the time people seem content with
> uspto.gov which only searches the US trademarks AFAICT.
>
> For Ivy I find a "Ivy Graphics, Inc." in Massachusets.  Can't say
> whether that would pose a problem or not.  You might be better servied
> with asking on general since there are people more experienced with
> trademark questions.


OK, I'll ask on general@i.a.o.

> [B] We have done one release in the incubator, but we have no
> > current release plan.
>
> I'm not sure this really is required since you had a plan before you
> released alpha1.
>
> > And here is what I don't clearly know what to think:
> >
> >   - *Meritocracy / Community *
> >      - Demonstrate an active and diverse development community [A]
> >      - The project is not highly dependent on any single contributor
> >      (there are at least 3 legally independent committers and there
> > is no single
> >      company or entity that is vital to the success of the project)
> >      [B]
> >      - The above implies that new committers are admitted according
> >      to ASF practices [C]
> >      - Demonstrate ability to tolerate and resolve conflict within
> >      the community. [D]
> >      - Engagement by the incubated community with the other ASF
> >      communities, particularly infrastructure@ (this reflects my
> >      personal bias that projects should pay an nfrastructure
> >      "tax"). [E]
> >
> > [A] From my point of view we demonstrate an active and diverse
> > development community.
>
> You do.
>
> > [B] This point is difficult to evaluate for me. As the creator of
> > the project, I have some knowledge of the code base and history of
> > the project that is not easy to catch up with.
>
> I wouldn't worry too much.  You are certainly trying your best to
> tranfer your knowledge and it works.
>
> > [C] I think this point doesn't really need discussion, Gilles was
> > admitted according to ASF practices.
>
> Yep.
>
> > [D] This point is not easy to address. I propose we start a flaming
> > war in the coming days and agree after a few days :-) Joke apart, I
> > don't think we have had any conflict so far in the community.
>
> You've had reasonable discussions and nobody pulled back because
> Xavier's view was different.  I don't think anybody would stop your
> graduation because you lack conflicts.
>
> > [E] I think we have some kind of engagement, it's difficult to know
> > if this is enough.
>
> I can attest you took care of Ivy in Gump.  There certainly is
> interaction with Ant and some with Maven.
>
> Infrastructure is hard to do since this is an ASF members only area
> but you did your best to help infra when the svn and JIRA migrations
> were done.
>
> You're doing fine here, I think.


Thanks!

Xavier

Stefan
>



-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: Steps toward graduation

Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 7 Jun 2007, Xavier Hanin <xa...@gmail.com> wrote:

>      - The code base must contain only ASL or ASL-compatible
>      dependencies

In the case of the non-ASLed JavaScript stuff I'd like to see a
solution other than "we don't ship it" since legally having something
in svn means distributing it.

> Here is what I consider we still need to do:
> 
>   - *Legal *
>      - Check of project name for trademark issues [A]
> 
> 
>   - *Meritocracy / Community *
>      - Release plans are developed and excuted in public by the
>      community. [B]

> [A] I don't know how this can be checked. Any idea?

If you use a search engine for "trademark search" you'll find several
national authorities.  Most of the time people seem content with
uspto.gov which only searches the US trademarks AFAICT.

For Ivy I find a "Ivy Graphics, Inc." in Massachusets.  Can't say
whether that would pose a problem or not.  You might be better servied
with asking on general since there are people more experienced with
trademark questions.

> [B] We have done one release in the incubator, but we have no
> current release plan.

I'm not sure this really is required since you had a plan before you
released alpha1.

> And here is what I don't clearly know what to think:
> 
>   - *Meritocracy / Community *
>      - Demonstrate an active and diverse development community [A]
>      - The project is not highly dependent on any single contributor
>      (there are at least 3 legally independent committers and there
> is no single
>      company or entity that is vital to the success of the project)
>      [B]
>      - The above implies that new committers are admitted according
>      to ASF practices [C]
>      - Demonstrate ability to tolerate and resolve conflict within
>      the community. [D]
>      - Engagement by the incubated community with the other ASF
>      communities, particularly infrastructure@ (this reflects my
>      personal bias that projects should pay an nfrastructure
>      "tax"). [E]
> 
> [A] From my point of view we demonstrate an active and diverse
> development community.

You do.

> [B] This point is difficult to evaluate for me. As the creator of
> the project, I have some knowledge of the code base and history of
> the project that is not easy to catch up with.

I wouldn't worry too much.  You are certainly trying your best to
tranfer your knowledge and it works.

> [C] I think this point doesn't really need discussion, Gilles was
> admitted according to ASF practices.

Yep.

> [D] This point is not easy to address. I propose we start a flaming
> war in the coming days and agree after a few days :-) Joke apart, I
> don't think we have had any conflict so far in the community.

You've had reasonable discussions and nobody pulled back because
Xavier's view was different.  I don't think anybody would stop your
graduation because you lack conflicts.

> [E] I think we have some kind of engagement, it's difficult to know
> if this is enough.

I can attest you took care of Ivy in Gump.  There certainly is
interaction with Ant and some with Maven.

Infrastructure is hard to do since this is an ASF members only area
but you did your best to help infra when the svn and JIRA migrations
were done.

You're doing fine here, I think.

Stefan

Re: Steps toward graduation (was Re: Report this month)

Posted by Xavier Hanin <xa...@gmail.com>.
On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> I remimber some times ago that we had a lincense issue with the javascript
> code managing the tree in our documentation.  Is it fixed?


Good question. The license issue is not fixed, but it seems that as long as
we do not deliver this script (not packaged in any of our distribution),
this is not an issue. Could somebody else confirm?

Xavier

Gilles
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: jeudi 7 juin 2007 10:29
> > To: ivy-dev@incubator.apache.org
> > Subject: Steps toward graduation (was Re: Report this month)
> >
> > On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
> > >
> > > [...]
> > >
> > I also would like to see where we should do better,  what do we need
> > > to enhance, what is still missing to be graduated.  I have 2 ideas
> > > (having a wider community, having a roadmap), but I guess a mentor
> > > could say more about that.
> >
> >
> > I think it's a good time to start a discussion about what remains to do
> > before graduation. If we look at the graduation guide [1] and exit
> > policies
> > [2], it seems we are on a good way.
> >
> > If I take the whole list from the exit policies document, here is what I
> > consider ok:
> >
> >    - *Legal *
> >    -
> >       - All code ASL'ed
> >       - The code base must contain only ASL or ASL-compatible
> >       dependencies
> >       - License grant complete
> >       - CLAs on file.
> >
> >
> >    - *Meritocracy / Community*
> >    - ASF style voting has been adopted and is standard practice
> >
> >
> >    - *Alignment / Synergy *
> >    -
> >       - Use of other ASF subprojects
> >       - Develop synergistic relationship with other ASF subprojects
> >
> >
> >    - *Infrastructure *
> >    -
> >       - SVN module has been created
> >       - Mailing list(s) have been created
> >       - Mailing lists are being archived
> >       - Issue tracker has been created
> >       - Project website has been created
> >       - Project is integrated with GUMP if appropriate
> >       - Releases are PGP signed by a member of the community
> >       - Developers tied into ASF PGP web of trust
> >
> >
> --------------------------------------------------------------------------
> > -------
> > Here is what I consider we still need to do:
> >
> >    - *Legal *
> >    -
> >       - Check of project name for trademark issues [A]
> >
> >
> >    - *Meritocracy / Community *
> >    -
> >       - Release plans are developed and excuted in public by the
> >       community. [B]
> >       -
> >          - (requirement on minimum number of such releases?)
> >          - Note: incubator projects are not permitted to issue an
> >          official Release. Test snapshots (however good the quality)
> > and Release
> >          *plans *are OK.
> >       - Incubator PMC has voted for graduation [C]
> >       - Destination PMC, or ASF Board for a TLP, has voted for final
> >       acceptance [D]
> >
> > [A] I don't know how this can be checked. Any idea?
> >
> > [B] We have done one release in the incubator, but we have no current
> > release plan. This is something that we need to discuss in a separate
> > thread.
> >
> > [C] and [D] this will be done only when all other points will be
> > addressed.
> > One point we will have to discuss before these votes is the destination:
> > should we try to graduate as a top level project or as a sub project of
> > Ant
> > (our sponsor). This is also something that deserves its own thread for
> > discussion.
> >
> >
> --------------------------------------------------------------------------
> > -------
> > And here is what I don't clearly know what to think:
> >
> >    - *Meritocracy / Community *
> >    -
> >       - Demonstrate an active and diverse development community [A]
> >       - The project is not highly dependent on any single contributor
> >       (there are at least 3 legally independent committers and there
> > is no single
> >       company or entity that is vital to the success of the project) [B]
> >       - The above implies that new committers are admitted according
> >       to ASF practices [C]
> >       - Demonstrate ability to tolerate and resolve conflict within
> >       the community. [D]
> >       - Engagement by the incubated community with the other ASF
> >       communities, particularly infrastructure@ (this reflects my
> personal
> > bias
> >       that projects should pay an nfrastructure "tax"). [E]
> >
> > [A] From my point of view we demonstrate an active and diverse
> development
> > community. We have 3 committers from 3 different companies, 170+ mails
> > exchanged on the dev mailing list per month since March [3], and 11
> > contributors since our entry in incubation. But it's difficult to know
> > what
> > is an active and diverse development community, if we compare to wicket
> we
> > are still far away.
> >
> > [B] This point is difficult to evaluate for me. As the creator of the
> > project, I have some knowledge of the code base and history of the
> project
> > that is not easy to catch up with. But we've seen several contributions
> > and
> > fixes dealing with some difficult part of the code base (like the
> > dependency
> > resolution engine), and work has been done to make the code base cleaner
> > and
> > easier to understand. So my IMHO the project is not highly dependent on
> > any
> > single contributor, but I'd like to ear from other voices.
> >
> > [C] I think this point doesn't really need discussion, Gilles was
> admitted
> > according to ASF practices.
> >
> > [D] This point is not easy to address. I propose we start a flaming war
> in
> > the coming days and agree after a few days :-) Joke apart, I don't think
> > we
> > have had any conflict so far in the community. Does it mean that we will
> > have troubles to resolve them, or simply that we are all tolerant enough
> > to
> > avoid conflicts. It's difficult to say, but I don't think this is a
> major
> > drawback for our community.
> >
> > [E] I think we have some kind of engagement, it's difficult to know if
> > this
> > is enough. We participate to some discussions on the ant, incubator and
> > repository mailing lists. I think we have also some contacts with the
> > commons-vfs project, and the maven project too. On the infrastructure,
> it
> > was more asking for things (like the migration of JIRA) than
> contributing,
> > but it's difficult to actively contribute without any karma. So, can we
> > consider this point adressed?
> >
> > So it seems we are on a pretty good way toward graduation. I'll start
> two
> > thread about release plan and  destination.
> > Any input on the points above are welcome from the whole community, so
> > feel
> > free to give feedback even if you are not a committer or mentor.
> >
> > Xavier
> >
> > [1] http://incubator.apache.org/guides/graduation.html
> > [2]
> >
> http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+f
> > rom+the+Incubator
> > [3] http://mail-archives.apache.org/mod_mbox/incubator-ivy-dev/
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

RE: Steps toward graduation (was Re: Report this month)

Posted by Gilles Scokart <gs...@gmail.com>.
I remimber some times ago that we had a lincense issue with the javascript
code managing the tree in our documentation.  Is it fixed?

Gilles

> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: jeudi 7 juin 2007 10:29
> To: ivy-dev@incubator.apache.org
> Subject: Steps toward graduation (was Re: Report this month)
> 
> On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
> >
> > [...]
> >
> I also would like to see where we should do better,  what do we need
> > to enhance, what is still missing to be graduated.  I have 2 ideas
> > (having a wider community, having a roadmap), but I guess a mentor
> > could say more about that.
> 
> 
> I think it's a good time to start a discussion about what remains to do
> before graduation. If we look at the graduation guide [1] and exit
> policies
> [2], it seems we are on a good way.
> 
> If I take the whole list from the exit policies document, here is what I
> consider ok:
> 
>    - *Legal *
>    -
>       - All code ASL'ed
>       - The code base must contain only ASL or ASL-compatible
>       dependencies
>       - License grant complete
>       - CLAs on file.
> 
> 
>    - *Meritocracy / Community*
>    - ASF style voting has been adopted and is standard practice
> 
> 
>    - *Alignment / Synergy *
>    -
>       - Use of other ASF subprojects
>       - Develop synergistic relationship with other ASF subprojects
> 
> 
>    - *Infrastructure *
>    -
>       - SVN module has been created
>       - Mailing list(s) have been created
>       - Mailing lists are being archived
>       - Issue tracker has been created
>       - Project website has been created
>       - Project is integrated with GUMP if appropriate
>       - Releases are PGP signed by a member of the community
>       - Developers tied into ASF PGP web of trust
> 
> --------------------------------------------------------------------------
> -------
> Here is what I consider we still need to do:
> 
>    - *Legal *
>    -
>       - Check of project name for trademark issues [A]
> 
> 
>    - *Meritocracy / Community *
>    -
>       - Release plans are developed and excuted in public by the
>       community. [B]
>       -
>          - (requirement on minimum number of such releases?)
>          - Note: incubator projects are not permitted to issue an
>          official Release. Test snapshots (however good the quality)
> and Release
>          *plans *are OK.
>       - Incubator PMC has voted for graduation [C]
>       - Destination PMC, or ASF Board for a TLP, has voted for final
>       acceptance [D]
> 
> [A] I don't know how this can be checked. Any idea?
> 
> [B] We have done one release in the incubator, but we have no current
> release plan. This is something that we need to discuss in a separate
> thread.
> 
> [C] and [D] this will be done only when all other points will be
> addressed.
> One point we will have to discuss before these votes is the destination:
> should we try to graduate as a top level project or as a sub project of
> Ant
> (our sponsor). This is also something that deserves its own thread for
> discussion.
> 
> --------------------------------------------------------------------------
> -------
> And here is what I don't clearly know what to think:
> 
>    - *Meritocracy / Community *
>    -
>       - Demonstrate an active and diverse development community [A]
>       - The project is not highly dependent on any single contributor
>       (there are at least 3 legally independent committers and there
> is no single
>       company or entity that is vital to the success of the project) [B]
>       - The above implies that new committers are admitted according
>       to ASF practices [C]
>       - Demonstrate ability to tolerate and resolve conflict within
>       the community. [D]
>       - Engagement by the incubated community with the other ASF
>       communities, particularly infrastructure@ (this reflects my personal
> bias
>       that projects should pay an nfrastructure "tax"). [E]
> 
> [A] From my point of view we demonstrate an active and diverse development
> community. We have 3 committers from 3 different companies, 170+ mails
> exchanged on the dev mailing list per month since March [3], and 11
> contributors since our entry in incubation. But it's difficult to know
> what
> is an active and diverse development community, if we compare to wicket we
> are still far away.
> 
> [B] This point is difficult to evaluate for me. As the creator of the
> project, I have some knowledge of the code base and history of the project
> that is not easy to catch up with. But we've seen several contributions
> and
> fixes dealing with some difficult part of the code base (like the
> dependency
> resolution engine), and work has been done to make the code base cleaner
> and
> easier to understand. So my IMHO the project is not highly dependent on
> any
> single contributor, but I'd like to ear from other voices.
> 
> [C] I think this point doesn't really need discussion, Gilles was admitted
> according to ASF practices.
> 
> [D] This point is not easy to address. I propose we start a flaming war in
> the coming days and agree after a few days :-) Joke apart, I don't think
> we
> have had any conflict so far in the community. Does it mean that we will
> have troubles to resolve them, or simply that we are all tolerant enough
> to
> avoid conflicts. It's difficult to say, but I don't think this is a major
> drawback for our community.
> 
> [E] I think we have some kind of engagement, it's difficult to know if
> this
> is enough. We participate to some discussions on the ant, incubator and
> repository mailing lists. I think we have also some contacts with the
> commons-vfs project, and the maven project too. On the infrastructure, it
> was more asking for things (like the migration of JIRA) than contributing,
> but it's difficult to actively contribute without any karma. So, can we
> consider this point adressed?
> 
> So it seems we are on a pretty good way toward graduation. I'll start two
> thread about release plan and  destination.
> Any input on the points above are welcome from the whole community, so
> feel
> free to give feedback even if you are not a committer or mentor.
> 
> Xavier
> 
> [1] http://incubator.apache.org/guides/graduation.html
> [2]
> http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+f
> rom+the+Incubator
> [3] http://mail-archives.apache.org/mod_mbox/incubator-ivy-dev/