On Jul 20, 2005, at 9:27 AM, Bill Stoddard wrote:
Alarm Bells going off... G uses a few custom patched packages...
yes, and we're going to quiet those bells... :)
geir
Bill
Geir Magnusson Jr. wrote:
On Jul 19, 2005, at 9:56 PM, [EMAIL PROTECTED] wrote:
"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 12/07/2005
10:57:34 PM:
On Jul 11, 2005, at 11:07 PM, [EMAIL PROTECTED] 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.
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
