On Nov 17, 2011, at 5:52 AM, Trygve Sanne Hardersen wrote:

> Thanks for the feedback Kevan!
> 
> We understand from your comments that you are positive with regards to having 
> the changes integrated with Geronimo, but that they are too significant to be 
> applied without further discussion. We have no problem understanding this.
> 
> Our goals with the project has been to 1. add some new features (i.e. spec 
> changes), 2. upgrade to supported versions of 3rd party libraries (for 
> instance CXF), 3. upgrade to latest version of 3rd party libraries (SLF4J, 
> Plexus and so on) and 4. better understand the inner workings of Geronimo. We 
> have not concerned ourselves with TCK compliance, though this is obviously 
> important from the community perspective.
> 
> We have done the project on the 2.2 branch because 3.0 was too unstable (as 
> in changed too fast) for us to work with. Some of the changes are backports 
> of your work on 3.0, others should in our opinion be applied to 3.0 as well 
> (ActiveMQ, CXF), and some are 2.2-specific (GShell).
> 
> For the community to better understand the implications of the changes, we 
> suggest the following approach:
> 
> 1. We try to split the changes into smaller parts with specific areas of 
> concern, and create JIRA issues for each of them.
> 2. The community decides whether or not to accept the issues.
> 3. We commit and support the accepted issues.
> 
> There will be quite a bit of work involved in splitting the patch, and some 
> changes are dependent on others. Before starting this we should come to 
> agreement on which specs upgrades are wanted. This will in most cases decide 
> which major 3rd party frameworks should be upgraded. We should also decide if 
> the "latest and greatest" approach to minor 3rd party libraries (typically 
> commons-libraries) is feasible for Geronimo. There might not be a single 
> answer to this.

Yes. I don't think you should start doing any work splitting things apart. 
Let's only start that, when we feel it's necessary... Hopefully avoid any 
unnecessary work...

The biggest issue is likely to be -- can 2.2 pass the TCK with your changes? 
We'll probably need to level-set our 2.2.1-SNAPSHOT testing -- get an accurate 
count of tests currently passing, etc. Prior to incorporating any changes. 
There are some potential alternatives to consider -- e.g. build Plugins that 
can replace server functionality, rather than integrate all function into the 
server functionality. Much like the old OpenJPA plugin that added JPA 2.0 
support, replacing the old JPA function. 

> 
> Trygve
> 
> (we'll email the corporate CLA to [email protected])

To simplify the software grant portions of the CLA, it will probably be easiest 
to attach your two patch files to a Jira. Select the "donate to the ASF" 
button. Then reference these files in the CLA.

It will also be useful, if you (and any other participants) submit an ICLA to 
secretary@.

Grants need to be cleared via the Apache Incubator. This is a process that we 
need to worry about (not you).

Once we're cleared through the Incubator (it won't be long). We can start 
dividing up the patches (if needed).

--kevan

Reply via email to