Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Fw: [eclipse.org-architecture-council] Who Needs Piggyback CQs?

Hi John

We discussed this in today's call, and we agree that it makes sense to get rid of those CQs. However, for our project we would still require PMC approval on the bug that wants to add a new dependency.

Can you forward this to the architecture council mailing list, which has a closed member list as per:

PLEASE NOTE: 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.

Thanks,
Dani



From:        John Arthorne <John_Arthorne@xxxxxxxxxx>
To:        eclipse-pmc@xxxxxxxxxxx
Date:        01.04.2015 13:19
Subject:        [eclipse-pmc] Fw: [eclipse.org-architecture-council] Who Needs        Piggyback CQs?
Sent by:        eclipse-pmc-bounces@xxxxxxxxxxx




It would be worth having a quick discussion about this in the PMC call today. Unfortunately I am traveling (again!) and won't be able to make it. From my perspective I think we can eliminate the PMC approval step for consuming Orbit libraries. I don't remember a case that we ever had to discuss before. They don't bother me too much as they give me some awareness of what libraries are being updated, but I can see for other PMC's with many unrelated sub-projects this must be a complete waste of PMC energy to respond to them.

John


----- Forwarded by John Arthorne/Ottawa/IBM on 04/01/2015 07:14 AM -----


From:        
Ed Merks <ed.merks@xxxxxxxxx>
To:        
eclipse.org-architecture-council@xxxxxxxxxxx
Date:        
03/31/2015 08:20 AM
Subject:        
[eclipse.org-architecture-council] Who Needs Piggyback CQs?
Sent by:        
eclipse.org-architecture-council-bounces@xxxxxxxxxxx




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._______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc

Back to the top