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
|