geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: Formalising private builds of external libraries (was Re: M4 - QA Branch details)
Date Wed, 20 Jul 2005 13:27:14 GMT
Alarm Bells going off... G uses a few custom patched packages...

Bill

Geir Magnusson Jr. wrote:
> 
> On Jul 19, 2005, at 9:56 PM, sissonj@insession.com wrote:
> 
>> "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?
> 
> 
> Well, someone is *already* doing it, right?  The difference is that  I'm 
> suggesting we put in our SVN and change the name of the jar...
> 
>>
>> 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?
> 
> 
> I'd prefer not.  It doesn't sound like a lot of overhead and removes  
> another ambiguity in our process.
> 
> I'm happy to help here - just someone needs to help me out with the  
> stuff we've patched...
> 
> geir
> 
>>
>> 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.
>>
>>
> 



Mime
View raw message