[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] [Bug 336874] New: Third Party Library Policy

https://bugs.eclipse.org/bugs/show_bug.cgi?id=336874
Product/Component: Community / Architecture Council

           Summary: Third Party Library Policy
    Classification: Eclipse Foundation
           Product: Community
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Architecture Council
        AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx
        ReportedBy: caniszczyk@xxxxxxxxx


At today's architecture council meeting, I brought up the topic of implementing
a  third party library policy (based on some of Andrew Overholt's gripes). The
main motivator of this is the pain we feel at Fedora as we tend to ship the
latest version of a library and have had to patch Eclipse to use the latest
library. eclipse.org projects, especially the SDK has historically not been
good about moving to the latest version of libraries (e.g., Lucene).

There are many benefits in moving to the latest version of a library, from
security fixes to new features. On the call, we discussed some potential
downsides, from the time it takes to move to a new library via the Eclipse IP
process to the testing of the actual new library. Another topic that came up
was that Eclipse sometimes ends up in a situation where projects are using two
different versions of a library and we are in a case where three projects are
using three different versions of say log4j, instead of just the latest
version.

There was some discussion by Wayne Beaton on how to implement a tool using
iplog data that can notify projects if a newer version of a library is
available in Orbit (or elsewhere) and they aren't using it. Another strategy
could we make this part of the release review process, when you hand in your IP
log, the IP team could do a quick check to see if there are newer versions of
any of the libraries used... projects would have to justify their usage of the
older library. Another strategy could be to make a strong requirement for the
simultaneous release that you're on the latest version of a library available.

Those are my two cents.

So what are people's thoughts here?

-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.