Is trinidad ready for graduation ?

[Martin van den Bemt <ml...@mvdb.net>]

In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to
see that at least the plugins get a release before we start a vote on dev (and I expressed below
that you are targetting to have a release of core before leaving the incubator,  although that could
be a misunderstanding)

If everyone agrees on dev, we start a vote on the incubator general list and after that on the
MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like
mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not
yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces
list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC
or have a binding vote there).


The very long version :

To determine if Trinidad is ready to leave the incubator I took
http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to
answer all the questions. The first 3 on that page are actually the last ones, since I am treating
them more as general conclusions.


Legal

* All code ASL'ed
Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that
before the release everything is ok, so that check needs to be done before a release (eg by using
RAT, mojo.codehaus.org is working on a maven2 plugin atm).

* No non ASL or ASL compatbile dependencies in the code base
Don't see any problems here (just checked the deps in the poms).

* License grant complete
Yep

* CLAs on file.
Yep. Even people who submitted patches were asked to file a CLA.

* Check of project name for trademark issues
Was tried, but since no one as access to the trademark database, it has hard to determine.


Meritocracy / Community

* Demonstrate an active and diverse development community
The community is very active, people send in patches that get applied, user community is a bit
behind, but that should grow ones Trinidad is released.

* The project is not highly dependent on any single contributor (there's at least 3 legally
independent committers and there is no single company or entity that is vital to the success of the
project)

The main contributors are all employed by Oracle (based on the *commits* since end of December).
These are matzew, jwaldman and awiner.
gcrawford   - Oracle
jfallows    - Not oracle anymore
mmarinschek - Irian (?)
slessard    - DMR Consulting Inc (?)
baranda     - ?
Mentors / champions
craigmcc    - Sun
mvdb        - Ordina (I don't count myself as a committer though)
mgeiler     - ? (not oracle afaik)

Looking at the above list, it could mean a worry, which will be a lot less worry looking at the rest
of the exit list.

* The above implies that new committers are admitted according to ASF practices

Absolutely. There were 3 committers added during incubation, one not Oracle and 2 Oracle people.
From my perspective all 3 deserved to be committer (with that amount of activity, people should be
voted in as a committer to be honest), so no favours were made just because someone is from Oracle.
Currently some other people are on the radar to become committer (non Oracle).

* ASF style voting has been adopted and is standard practice

In every way.

* Demonstrate ability to tolerate and resolve conflict within the community.

Haven't noted much conflicts to be honest, but I am happy with the oversight that is done and how
commits that get feedback get resolved quickly. I use the word feedback, since I haven't noticed any
strong -1 on a commit, since there is respect for each others knowledge, ego's don't tend to play
up, which is a good thing.

* Release plans are developed and excuted in public by the community.

This is done and currently the project is making it easier to do release (cut down the manual work
of the release). The project has some problems getting a release out the door, which is partially
solved by adding another mentor, so the project actually can get 3 binding votes on a release. The
goal is to release the plugins and the core before leaving incubation. Currently there is
http://wiki.apache.org/myfaces/TrinidadReleaseProcedure on the wiki, which after the releases are
done can be formalised as a permanent part of the website.

* Engagement by the incubated community with the other ASF communities, particularly infrastructure@
(this reflects my personal bias that projects should pay an nfrastructure "tax").

This is the case, since there is my synergy with the MyFaces community and most people from Trinidad
are also actively involved there. So infrastructure is less of a problem, since that is handled (in
the future) by the MyFaces PMC.

* Incubator PMC has voted for graduation
* Destination PMC, or ASF Board for a TLP, has voted for final acceptance

The goal of this mail to get those votes :)

Alignment / Synergy

* Use of other ASF subprojects

Not specifically, since the goals is to be JSR compliant.

* Develop synergistic relationship with other ASF subprojects

MyFaces is the sponsoring PMC.

Infrastructure

* SVN module has been created

Yep, but it will move to MyFaces.

* Mailing list(s) have been created
* Mailing lists are being archived

Do we keep the trinidad lists ?

* Issue tracker has been created
* Project website has been created

Yep.

* Project ready to comply with ASF mirroring guidlines

The maven plugins don't need a seperate download and are therefor mirrored to the maven
repositories. The Trinidad core still needs a release and will setup a download page according to
the mirroring guidelines.

* Project is integrated with GUMP if appropriate

It is appropiate, but no gump integration afaik (since I am on the Gump PMC, I like to see this
happening).

* Releases are PGP signed by a member of the community

Yep. Key signing is part of the standard release process.

* Developers tied into ASF PGP web of trust

Don't have a clue. Everyone coming to Apachecon however can join the Key Signing session to be
trusted even more :).

Conclusions :

* it is a worthy and healthy project

It is definitely a worthy and healthy project. Even though there can be concerns about the number of
Oracle people involved, I think they have proven that they treat this project as an Apache project
and not as an Oracle project. I think a complement is even in order, since it could be very tempting
to do it the wrong way.

* it truly fits within the ASF framework
+1

* it "gets" the Apache Way.

It definitely gets the Apache Way. They are open for feedback, act promptly when something slipped
through the cracks and they really *want* to do the right thing. I even never heard a complaint on
having to do things the Apache way.

Mvgr,
Martin

Re: Is trinidad ready for graduation ?

[Matthias Wessendorf <ma...@apache.org>]

Hi Martin,

see inline for some comment

On 2/10/07, Martin van den Bemt <ml...@mvdb.net> wrote:
> In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to
> see that at least the plugins get a release before we start a vote on dev (and I expressed below
> that you are targetting to have a release of core before leaving the incubator,  although that could
> be a misunderstanding)

the plugins release is now available for a vote on the trinidad_dev.
I figured out how to do that with the maven stuff (learned the hard
way, like Manfred in the MyFaces Core camp ;)). I'd like to see a
quick followed "Trinidad Core" after we get the plugins approved.
Should be more easy, since we have figured out what exactly to do and
I also documented the procedure.


>
> If everyone agrees on dev, we start a vote on the incubator general list and after that on the
> MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like
> mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not
> yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces
> list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC
> or have a binding vote there).

yes, as a member you can easily subscribe to the private list. That's
fine. Also +1 on having a discussion started on the MyFaces Private
one regarding the exiting strategy.


>
>
> The very long version :
>
> To determine if Trinidad is ready to leave the incubator I took
> http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to
> answer all the questions. The first 3 on that page are actually the last ones, since I am treating
> them more as general conclusions.
>
>
> Legal
>
> * All code ASL'ed
> Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that
> before the release everything is ok, so that check needs to be done before a release (eg by using
> RAT, mojo.codehaus.org is working on a maven2 plugin atm).

A plugin for RAT would be sweet. Can you keep me posted ? Can you do
the RAT thing on the plugins release thing ?


>
> * No non ASL or ASL compatbile dependencies in the code base
> Don't see any problems here (just checked the deps in the poms).
>
> * License grant complete
> Yep
>
> * CLAs on file.
> Yep. Even people who submitted patches were asked to file a CLA.
>
> * Check of project name for trademark issues
> Was tried, but since no one as access to the trademark database, it has hard to determine.

More, I filled an issue against the Incubator, since the "mentioned"
database is not accessible without paying the big box.


> Meritocracy / Community
>
> * Demonstrate an active and diverse development community
> The community is very active, people send in patches that get applied, user community is a bit
> behind, but that should grow ones Trinidad is released.
>
> * The project is not highly dependent on any single contributor (there's at least 3 legally
> independent committers and there is no single company or entity that is vital to the success of the
> project)
>
> The main contributors are all employed by Oracle (based on the *commits* since end of December).
> These are matzew, jwaldman and awiner.
> gcrawford   - Oracle
> jfallows    - Not oracle anymore
> mmarinschek - Irian (?)
> slessard    - DMR Consulting Inc (?)
> baranda     - ?
> Mentors / champions
> craigmcc    - Sun
> mvdb        - Ordina (I don't count myself as a committer though)
> mgeiler     - ? (not oracle afaik)

jfallows    => brane inc
mmarinschek => irian
slessard    = >DMR Consulting Inc
baranda     => somewhere in England, working at a biology institute.
mgeiler => irian as well :)


>
> Looking at the above list, it could mean a worry, which will be a lot less worry looking at the rest
> of the exit list.

well, Simon and Bruno also did their part ... :)


-Matthias



>
> * The above implies that new committers are admitted according to ASF practices
>
> Absolutely. There were 3 committers added during incubation, one not Oracle and 2 Oracle people.
> From my perspective all 3 deserved to be committer (with that amount of activity, people should be
> voted in as a committer to be honest), so no favours were made just because someone is from Oracle.
> Currently some other people are on the radar to become committer (non Oracle).
>
> * ASF style voting has been adopted and is standard practice
>
> In every way.
>
> * Demonstrate ability to tolerate and resolve conflict within the community.
>
> Haven't noted much conflicts to be honest, but I am happy with the oversight that is done and how
> commits that get feedback get resolved quickly. I use the word feedback, since I haven't noticed any
> strong -1 on a commit, since there is respect for each others knowledge, ego's don't tend to play
> up, which is a good thing.
>
> * Release plans are developed and excuted in public by the community.
>
> This is done and currently the project is making it easier to do release (cut down the manual work
> of the release). The project has some problems getting a release out the door, which is partially
> solved by adding another mentor, so the project actually can get 3 binding votes on a release. The
> goal is to release the plugins and the core before leaving incubation. Currently there is
> http://wiki.apache.org/myfaces/TrinidadReleaseProcedure on the wiki, which after the releases are
> done can be formalised as a permanent part of the website.
>
> * Engagement by the incubated community with the other ASF communities, particularly infrastructure@
> (this reflects my personal bias that projects should pay an nfrastructure "tax").
>
> This is the case, since there is my synergy with the MyFaces community and most people from Trinidad
> are also actively involved there. So infrastructure is less of a problem, since that is handled (in
> the future) by the MyFaces PMC.
>
> * Incubator PMC has voted for graduation
> * Destination PMC, or ASF Board for a TLP, has voted for final acceptance
>
> The goal of this mail to get those votes :)
>
> Alignment / Synergy
>
> * Use of other ASF subprojects
>
> Not specifically, since the goals is to be JSR compliant.
>
> * Develop synergistic relationship with other ASF subprojects
>
> MyFaces is the sponsoring PMC.
>
> Infrastructure
>
> * SVN module has been created
>
> Yep, but it will move to MyFaces.
>
> * Mailing list(s) have been created
> * Mailing lists are being archived
>
> Do we keep the trinidad lists ?
>
> * Issue tracker has been created
> * Project website has been created
>
> Yep.
>
> * Project ready to comply with ASF mirroring guidlines
>
> The maven plugins don't need a seperate download and are therefor mirrored to the maven
> repositories. The Trinidad core still needs a release and will setup a download page according to
> the mirroring guidelines.
>
> * Project is integrated with GUMP if appropriate
>
> It is appropiate, but no gump integration afaik (since I am on the Gump PMC, I like to see this
> happening).
>
> * Releases are PGP signed by a member of the community
>
> Yep. Key signing is part of the standard release process.
>
> * Developers tied into ASF PGP web of trust
>
> Don't have a clue. Everyone coming to Apachecon however can join the Key Signing session to be
> trusted even more :).
>
> Conclusions :
>
> * it is a worthy and healthy project
>
> It is definitely a worthy and healthy project. Even though there can be concerns about the number of
> Oracle people involved, I think they have proven that they treat this project as an Apache project
> and not as an Oracle project. I think a complement is even in order, since it could be very tempting
> to do it the wrong way.
>
> * it truly fits within the ASF framework
> +1
>
> * it "gets" the Apache Way.
>
> It definitely gets the Apache Way. They are open for feedback, act promptly when something slipped
> through the cracks and they really *want* to do the right thing. I even never heard a complaint on
> having to do things the Apache way.
>
> Mvgr,
> Martin
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: [Skinning] FileSystemStyleCache code - ok to delete?

[Jeanne Waldman <je...@oracle.com>]

thanks. I'll kill it right now.

Adam Winer wrote:
> Die die die. :)
>
> Unused code should almost always go.  It can always
> be revived from source control, and if it's unused, the
> odds that it works steadily decreases as time goes on.
>
> -- Adam
>
>
> On 2/12/07, Jeanne Waldman <je...@oracle.com> wrote:
>>
>> I'm trying to figure out what's going on in FileSystemStyleCache
>> regarding the caching code.
>>
>> I noticed that this code is not called by anyone. Does anyone object to
>> my deleting it? Or is there
>> some use for it so I should keep it around.
>>
>>
>>   /**
>>    * Returns a shared ImageProvider instance for the specified
>>    * XSS document and target cache directory.
>>    *
>>    * @param source The path of the source XSS document.  The
>>    *   specified file must be a valid XSS document.  If the specified
>>    *   file does not exists, an IllegalArgumentException is thrown.
>>    * @param target The path of the target directory.  Generated
>>    *   CSS files are stored in this directory.  If the directory
>>    *   does not exist and can not be created, an 
>> IllegalArgumentException
>>    *   is thrown.
>>    */
>>   public static StyleProvider getSharedCache(
>>     String source,
>>     String target
>>     )
>>   {
>>     // Make sure we have some source/target.
>>     if (source == null)
>>       throw new IllegalArgumentException("No source specified.");
>>     if (target == null)
>>       throw new IllegalArgumentException("No target specified.");
>>
>>     // First, get the key to use to look up the cache
>>     String key = _getSharedCacheKey(source, target);
>>
>>     // See if we've got a shared cache
>>     StyleProvider cache = _sSharedCaches.get(key);
>>
>>     // If we didn't find a shared cache, create a new cache
>>     // and cache it in the shared cache cache.  :-)
>>     if (cache == null)
>>     {
>>       // Create the new cache
>>       cache = new FileSystemStyleCache(source, target);
>>
>>       // Before we save the new cache, make sure another thread hasn't
>>       // already cached a different instance.  Synchronize to lock up
>>       // _sSharedCaches.
>>       synchronized (_sSharedCaches)
>>       {
>>         StyleProvider tmp = _sSharedCaches.get(key);
>>         if (tmp != null)
>>         {
>>           // Stick with tmp
>>           cache = tmp;
>>         }
>>         else
>>         {
>>           _sSharedCaches.put(key, cache);
>>         }
>>       }
>>     }
>>
>>     return cache;
>>   }
>>
>>
>

Re: [Skinning] FileSystemStyleCache code - ok to delete?

[Adam Winer <aw...@gmail.com>]

Die die die. :)

Unused code should almost always go.  It can always
be revived from source control, and if it's unused, the
odds that it works steadily decreases as time goes on.

-- Adam


On 2/12/07, Jeanne Waldman <je...@oracle.com> wrote:
>
> I'm trying to figure out what's going on in FileSystemStyleCache
> regarding the caching code.
>
> I noticed that this code is not called by anyone. Does anyone object to
> my deleting it? Or is there
> some use for it so I should keep it around.
>
>
>   /**
>    * Returns a shared ImageProvider instance for the specified
>    * XSS document and target cache directory.
>    *
>    * @param source The path of the source XSS document.  The
>    *   specified file must be a valid XSS document.  If the specified
>    *   file does not exists, an IllegalArgumentException is thrown.
>    * @param target The path of the target directory.  Generated
>    *   CSS files are stored in this directory.  If the directory
>    *   does not exist and can not be created, an IllegalArgumentException
>    *   is thrown.
>    */
>   public static StyleProvider getSharedCache(
>     String source,
>     String target
>     )
>   {
>     // Make sure we have some source/target.
>     if (source == null)
>       throw new IllegalArgumentException("No source specified.");
>     if (target == null)
>       throw new IllegalArgumentException("No target specified.");
>
>     // First, get the key to use to look up the cache
>     String key = _getSharedCacheKey(source, target);
>
>     // See if we've got a shared cache
>     StyleProvider cache = _sSharedCaches.get(key);
>
>     // If we didn't find a shared cache, create a new cache
>     // and cache it in the shared cache cache.  :-)
>     if (cache == null)
>     {
>       // Create the new cache
>       cache = new FileSystemStyleCache(source, target);
>
>       // Before we save the new cache, make sure another thread hasn't
>       // already cached a different instance.  Synchronize to lock up
>       // _sSharedCaches.
>       synchronized (_sSharedCaches)
>       {
>         StyleProvider tmp = _sSharedCaches.get(key);
>         if (tmp != null)
>         {
>           // Stick with tmp
>           cache = tmp;
>         }
>         else
>         {
>           _sSharedCaches.put(key, cache);
>         }
>       }
>     }
>
>     return cache;
>   }
>
>

[Skinning] FileSystemStyleCache code - ok to delete?

[Jeanne Waldman <je...@oracle.com>]

I'm trying to figure out what's going on in FileSystemStyleCache 
regarding the caching code.

I noticed that this code is not called by anyone. Does anyone object to 
my deleting it? Or is there
some use for it so I should keep it around.


  /**
   * Returns a shared ImageProvider instance for the specified
   * XSS document and target cache directory.
   *
   * @param source The path of the source XSS document.  The
   *   specified file must be a valid XSS document.  If the specified
   *   file does not exists, an IllegalArgumentException is thrown.
   * @param target The path of the target directory.  Generated
   *   CSS files are stored in this directory.  If the directory
   *   does not exist and can not be created, an IllegalArgumentException
   *   is thrown.
   */
  public static StyleProvider getSharedCache(
    String source,
    String target
    )
  {
    // Make sure we have some source/target.
    if (source == null)
      throw new IllegalArgumentException("No source specified.");
    if (target == null)
      throw new IllegalArgumentException("No target specified.");

    // First, get the key to use to look up the cache
    String key = _getSharedCacheKey(source, target);

    // See if we've got a shared cache
    StyleProvider cache = _sSharedCaches.get(key);

    // If we didn't find a shared cache, create a new cache
    // and cache it in the shared cache cache.  :-)
    if (cache == null)
    {
      // Create the new cache
      cache = new FileSystemStyleCache(source, target);

      // Before we save the new cache, make sure another thread hasn't
      // already cached a different instance.  Synchronize to lock up
      // _sSharedCaches.
      synchronized (_sSharedCaches)
      {
        StyleProvider tmp = _sSharedCaches.get(key);
        if (tmp != null)
        {
          // Stick with tmp
          cache = tmp;
        }
        else
        {
          _sSharedCaches.put(key, cache);
        }
      }
    }

    return cache;
  }

Re: Is trinidad ready for graduation ?

[Matthias Wessendorf <ma...@apache.org>]

Hello Martin,

your email states that this group should at least manage to get the
release of the plugins out. I did. Currently this group is waiting for
an approval to release the CORE as well.

One item, we need to check is

"Project ready to comply with ASF mirroring guidlines"

I will look at MyFaces, how we do it there, shouldn't be that big deal.

@GUMP: we use(d) continuum (was reseted currently)
that should be ok?!


What is your current thinking about this group?
Start a vote? Fix the missing items? Wait for approval for CORE ?


Thanks!
Matthias


On 2/10/07, Martin van den Bemt <ml...@mvdb.net> wrote:
> In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to
> see that at least the plugins get a release before we start a vote on dev (and I expressed below
> that you are targetting to have a release of core before leaving the incubator,  although that could
> be a misunderstanding)
>
> If everyone agrees on dev, we start a vote on the incubator general list and after that on the
> MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like
> mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not
> yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces
> list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC
> or have a binding vote there).
>
>
> The very long version :
>
> To determine if Trinidad is ready to leave the incubator I took
> http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to
> answer all the questions. The first 3 on that page are actually the last ones, since I am treating
> them more as general conclusions.
>
>
> Legal
>
> * All code ASL'ed
> Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that
> before the release everything is ok, so that check needs to be done before a release (eg by using
> RAT, mojo.codehaus.org is working on a maven2 plugin atm).
>
> * No non ASL or ASL compatbile dependencies in the code base
> Don't see any problems here (just checked the deps in the poms).
>
> * License grant complete
> Yep
>
> * CLAs on file.
> Yep. Even people who submitted patches were asked to file a CLA.
>
> * Check of project name for trademark issues
> Was tried, but since no one as access to the trademark database, it has hard to determine.
>
>
> Meritocracy / Community
>
> * Demonstrate an active and diverse development community
> The community is very active, people send in patches that get applied, user community is a bit
> behind, but that should grow ones Trinidad is released.
>
> * The project is not highly dependent on any single contributor (there's at least 3 legally
> independent committers and there is no single company or entity that is vital to the success of the
> project)
>
> The main contributors are all employed by Oracle (based on the *commits* since end of December).
> These are matzew, jwaldman and awiner.
> gcrawford   - Oracle
> jfallows    - Not oracle anymore
> mmarinschek - Irian (?)
> slessard    - DMR Consulting Inc (?)
> baranda     - ?
> Mentors / champions
> craigmcc    - Sun
> mvdb        - Ordina (I don't count myself as a committer though)
> mgeiler     - ? (not oracle afaik)
>
> Looking at the above list, it could mean a worry, which will be a lot less worry looking at the rest
> of the exit list.
>
> * The above implies that new committers are admitted according to ASF practices
>
> Absolutely. There were 3 committers added during incubation, one not Oracle and 2 Oracle people.
> From my perspective all 3 deserved to be committer (with that amount of activity, people should be
> voted in as a committer to be honest), so no favours were made just because someone is from Oracle.
> Currently some other people are on the radar to become committer (non Oracle).
>
> * ASF style voting has been adopted and is standard practice
>
> In every way.
>
> * Demonstrate ability to tolerate and resolve conflict within the community.
>
> Haven't noted much conflicts to be honest, but I am happy with the oversight that is done and how
> commits that get feedback get resolved quickly. I use the word feedback, since I haven't noticed any
> strong -1 on a commit, since there is respect for each others knowledge, ego's don't tend to play
> up, which is a good thing.
>
> * Release plans are developed and excuted in public by the community.
>
> This is done and currently the project is making it easier to do release (cut down the manual work
> of the release). The project has some problems getting a release out the door, which is partially
> solved by adding another mentor, so the project actually can get 3 binding votes on a release. The
> goal is to release the plugins and the core before leaving incubation. Currently there is
> http://wiki.apache.org/myfaces/TrinidadReleaseProcedure on the wiki, which after the releases are
> done can be formalised as a permanent part of the website.
>
> * Engagement by the incubated community with the other ASF communities, particularly infrastructure@
> (this reflects my personal bias that projects should pay an nfrastructure "tax").
>
> This is the case, since there is my synergy with the MyFaces community and most people from Trinidad
> are also actively involved there. So infrastructure is less of a problem, since that is handled (in
> the future) by the MyFaces PMC.
>
> * Incubator PMC has voted for graduation
> * Destination PMC, or ASF Board for a TLP, has voted for final acceptance
>
> The goal of this mail to get those votes :)
>
> Alignment / Synergy
>
> * Use of other ASF subprojects
>
> Not specifically, since the goals is to be JSR compliant.
>
> * Develop synergistic relationship with other ASF subprojects
>
> MyFaces is the sponsoring PMC.
>
> Infrastructure
>
> * SVN module has been created
>
> Yep, but it will move to MyFaces.
>
> * Mailing list(s) have been created
> * Mailing lists are being archived
>
> Do we keep the trinidad lists ?
>
> * Issue tracker has been created
> * Project website has been created
>
> Yep.
>
> * Project ready to comply with ASF mirroring guidlines
>
> The maven plugins don't need a seperate download and are therefor mirrored to the maven
> repositories. The Trinidad core still needs a release and will setup a download page according to
> the mirroring guidelines.
>
> * Project is integrated with GUMP if appropriate
>
> It is appropiate, but no gump integration afaik (since I am on the Gump PMC, I like to see this
> happening).
>
> * Releases are PGP signed by a member of the community
>
> Yep. Key signing is part of the standard release process.
>
> * Developers tied into ASF PGP web of trust
>
> Don't have a clue. Everyone coming to Apachecon however can join the Key Signing session to be
> trusted even more :).
>
> Conclusions :
>
> * it is a worthy and healthy project
>
> It is definitely a worthy and healthy project. Even though there can be concerns about the number of
> Oracle people involved, I think they have proven that they treat this project as an Apache project
> and not as an Oracle project. I think a complement is even in order, since it could be very tempting
> to do it the wrong way.
>
> * it truly fits within the ASF framework
> +1
>
> * it "gets" the Apache Way.
>
> It definitely gets the Apache Way. They are open for feedback, act promptly when something slipped
> through the cracks and they really *want* to do the right thing. I even never heard a complaint on
> having to do things the Apache way.
>
> Mvgr,
> Martin
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com