Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
To: dev@geronimo.apache.org
Subject: Formalising private builds of external libraries (was Re: M4 - QA
 Branch
 details)
MIME-Version: 1.0
From: sissonj@insession.com
Message-ID: 
 <OF4680B189.4FCFD6B0-ONCA257044.0008ADD4-CA257044.000AA15A@tsainc.com>
Date: Wed, 20 Jul 2005 12:56:07 +1100
Content-Type: text/plain; charset="US-ASCII"

"Geir Magnusson Jr." <geirm@apache.org> wrote on 12/07/2005 10:57:34 PM:

> 
> On Jul 11, 2005, at 11:07 PM, sissonj@insession.com wrote:
> >
> >
> > It appears we have already been building defacto releases of external
> > libraries, e.g. the cglib library in our repo:
> > http://cvs.apache.org/repository/cglib/jars/
> 
> You're right - there is a problem we have to deal with, but I'd 
> rather see us try another approach to make things very clear and 
> accountable.
> 
> For any code that we must do this to we could adopt a strategery :
> 
> 1) Make a copy in Apache SVN.  This code must be appropriately 
> licensed (the Apache License) and there should be a very clear NOTICE 
> about the source, what we're doing, that it's not a fork, etc, etc....
> 
> 2) Produce a jar :
> 
>         geronimo-private-cglib-20050711.jar
> 
> 3) put that in
> 
>        geronimo/jars
> 
> So it's very clear that it's not a release by CGLib, but rather code 
> from us, by us, from our repo.

Are planning on formalising the privately built jars using the above 
strategy proposed by Geir for M4 or would our time be better spent 
starting in M5?

For example, the patched version of xmlbeans and wsdl4j (GERONIMO-751) in 
M4?

If we have people reporting bugs in M4 that involve these custom built 
libraries, it won't be easy for developers to debug if they don't have the 
source for these custom builds.  Are we happy to take that risk in M4?

How do people feel about adopting the above approach and release 
documentation discussed below, moving forward?

Thanks,

John
> 
> >
> > Maybe a compromise is to properly document in the release notes any
> > special versions of code we have with the following information:
> >
> > * Have a disclaimer stating that a special version of the library 
> > is being
> > used temporarily and we plan on moving to the a formal release of the
> > library as soon as possible.  Maybe mention there could be a 
> > 'chance' of
> > compatibility issues when we move to the formal version?
> > * A description of why a special version of a library is needed and 
> > what
> > the library is used by
> > * The version of the code that was patched
> > * A link/reference to the bug/issue tracking records for the 
> > problem with
> > the library and the patch(s) that were submitted to the external 
> > project.
> 
> Yes - all good, in that NOTICE in SVN, and also in the distribution 
> release notes.

This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.