Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[soa-pmc] FW: [eclipse.org-architecture-council] Who Needs Piggyback CQs?
Hi guys,

Thought I’d forward this email from Ed as it may concern you.

Cheers,
Adrian.

From: Ed Merks <Ed.Merks@xxxxxxxxx>
Reply-To: "eclipse. org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date: Tuesday 31 March 2015 14:19
To: "eclipse. org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Subject: [eclipse.org-architecture-council] Who Needs Piggyback CQs?

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:
  1. Giving each PMC the chance to approve or reject the use of libraries by their managed projects.
  2. 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
 
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top