Hi,
I wanted to prompt a discussion related to the current IP
process. In my role as elected committer representative on
the Eclipse Board I have been involved with the board's IP
Committee. I've raised an issue regard piggyback CQs with
the committee, i.e., I'd like to eliminate them entirely.
Currently piggyback CQs apparently serve two purposes:
- Giving each PMC the chance to approve or reject the
use of libraries by their managed projects.
- Tracking dependencies on "external libraries".
Both of these reasons are suspect, in my opinion. If a PMC
managed n projects and each of those n projects want to use
library x, the PMC must approve n piggyback CQs, all of
which piggyback off a CQ already approved by some PMC,
perhaps even the same PMC. When a new approved version of
library x becomes available, n new piggyback CQs are likely
to be file, or more likely still, everyone overlooks the
fact that they are suddenly resolving to a new version of
the library and hence forget to file new piggyback CQs (so
much for reason number two). It has been argued that the
reason for needing the tracking is so that if some problem
is later discovered for library x, all the affected projects
can easily be tracked down. This has never ever happened,
so that too seems questionable at best.
What I've proposed and prototyped is an automated tool that
analyzes a project's p2 repository (or even directly a
project's git repository; Oomph can induce a p2 repository
directly from a git clone). The analysis produces a summary
of the direct non-Eclipse dependencies of the
Eclipse-originated artifacts in a p2 repository. E.g.,
analyzing the Oomph p2 repository summarizes that bundle
org.eclipse.oomph.setup.core version 1.1.1 depends on the
bundle org.apache.httpcomponents.httpclient, any version
bigger than 4.0.0 and less than 5.0.0. That's Oomph's only
external dependency.
Assuming there exists a map from each bundle ID version pair
to the CQ approving its use, there would be enough
information to generate an IP log with references to the
original CQ, without need for a piggyback CQ. As such, the
logs themselves would provide the tracing information
without need for indirection via piggyback CQs. The primary
question that remains is do PMCs feel a need to approve the
use of libraries that have already been approved for use at
Eclipse? I've argued that because PMCs must approve
releases and releases must have an associated IP logs, the
PMCs don't need piggyback CQs at all. So no one needs them;
they're simply unnecessary overhead we should try to
eliminate.
Does anyone, particularly any PMC member, have concerns to
the contrary? Personally, as the Modeling PMC lead, I find
piggyback CQs a pointless nuisance. If anyone sees a flaw
in the above reasoning, please speak up.
Regards,
Ed
