RE: [orbit-dev] Modifying source of a 3rd party library

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

Thanks Martin,

That does help. In my case I have a bug to reference but alas the patch although small is not backwards compatible so we'll likely have to roll our own. I'll talk to Janet about how best to approach this.
I'm wondering if we can formalize the process a bit so the next time this happens there's a little guidance.

Here's a few pieces of the puzzle:
1) What you state about a non-api / implementation only patch is very important. I don't think we should consider any other patching.
2) Some traceability back to a bug at the source (even if this means we open the bug)
3) If backporting an existing patch CQs are needed.
4) Add a note in the bundle.
5) Update the source
6) Recompile with extreme caution paying special attention to the existing compiled codes class format.

Any thoughts?

"Oberhuber, Martin" ---02/10/2009 10:43:54 AM---Hi Simon,

From:	"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To:	"Orbit Developer discussion" <orbit-dev@xxxxxxxxxxx>
Date:	02/10/2009 10:43 AM
Subject:	RE: [orbit-dev] Modifying source of a 3rd party library

---

Hi Simon,
 
I've had a similar situation with Apache Commons Net. What I did at that time, was file CQ's for the two bugs to be fixed (I.e. patches to the code), and apply them to the Orbit version of the lib. Since it was only bugs in the implementation with respect to reliability / deadlock avoidance, I did not change the version of the lib (it remained 1.4.1 -- only the qualifier changed). The CQ's for the patches were:
 
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1752
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1753
 
By referencing the Apache JIRA bug, there was some track of records that the patches would eventually be integrated into the next Commons Net release. On the CQ's, we also clarified provenience and legal status of the two patches, and thanks to the CQ's they were always documented on our IP log. 
 
http://www.eclipse.org/projects/ip_log.php?projectid=dsdp.tm
 
I'm not saying that this was the ideal process to follow, but it worked well for us and I'm glad we had the fixes in our products based off Eclipse.
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

---

From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Kaegi
Sent: Montag, 09. Februar 2009 18:08
To: Orbit Developer discussion
Subject: [orbit-dev] Modifying source of a 3rd party library

I've run into a situation with -- https://bugs.eclipse.org/bugs/show_bug.cgi?id=262641

One of the 3rd party libraries we use (and is no longer the active stream) has a bug in it that is likely not to be fixed.
It is fixed in a future release however due to JRE requirements we're unlikely to adopt it until the whole platform requires Java 5.

The fix is easy enough to make and I'm wondering if we have or perhaps should have any process around this sort of thing.
Any thoughts?

-Simon_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev