|[soa-pmc] FW: [eclipse.org-architecture-council] Who Needs Piggyback CQs?|
Thought I’d forward this email from Ed as it may concern you.
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?
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:
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.
_______________________________________________ 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