Re: [eclipse.org-architecture-council] Who Needs Piggyback CQs?

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Ed,

Here are my thoughts on this:

+1 on removing the need to _manually_ manage PB CQs
-1 on removing PB CQs in general without replacing them with a suitable reporting/tracking mechanism


I'd like to see a few changes in the IP process area, though.

(1) Every project should be allowed to consume and redistribute IP-approved libraries without causing administrative work for PMCs (and ideally project committers too).
(2) I prefer to keep the IP Log for listing such usage as per (1).
(3) The IP process should change to an "opt-in" model for projects on a "per-release" base.

The key to (1) and (2) is likely automation. Your scanner is a good idea, Wayne also has a downloads scanner. But we also need to capture "compile" and/or "test-only" dependencies. Java code can be analyzed for package imports. But there is also a growing generation of projects in different languages and not using p2.

Point (3) is probably the most controversial one. Why do we need to bother with CQs at all if a project doesn't care? I believe that we are putting too much work onto the IP team without ever asking ourselves if that is all really necessary. There is probably a significant number of projects which don't need the full IP program. This may be just guessing, though. But a logo-/branding-program could help here. IP-approved releases would qualify for the "IP-approved" logo. The PMI can make it easy to list/verify if a specific release is IP approved.


-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/






> Am 31.03.2015 um 14:19 schrieb Ed Merks <ed.merks@xxxxxxxxx>:
> 
> 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
> _______________________________________________
> 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.