Just a reminder that the topic of this thread is not a complete
re-evaluation of the role of PMCs in decision making. The topic at
hand is whether we should eliminate the need for piggyback CQs.
If the Architecture Council would like to re-evaluate the role of
the PMCs in these decisions, that would be great. But let's do it
in a separate thread please.
On 31/03/2015 10:22 AM, Doug Schaefer wrote:
I’m with Christian. As a Tools PMC member, I never reject the
use of a third party library by one of our projects. I can’t
imagine a good reason why I would. If the project needs that
functionality and the legal team approves it, I’m not about to
throw in a random opinion. Tools isn’t a releasable product
where such things matter. We’re more like the Canadian senate, a
place for sober second thought, but with little real power. That
power really resides in the lower projects who are doing the
real work.
Other projects may vary. Maybe Modelling has a more vested
interested interest in its dependencies. I’m sure Eclipse does.
I guess my point is, finding a more light weight process
where the projects have more control and the PMC doesn’t need to
approve anything and hold up the process, but is allowed
visibility into the requests to make sure projects aren’t going
rogue, might be a better approach.
Doug.
Christian,
Comments below.
On 31/03/2015 3:54 PM,
Christian Campo wrote:
Hi,
As a PMC member I would vote in favor for removing
any action from my shoulder where I really dont or
would NEVER say NO. :-)
Piggybacks are one of them.
IMHO another case is that if library xxx 1.5. Is
approved by the PMC why is another approval needed for
1.5.1 and 1..6 and 1.7 ?
Well of course a new library must be approved by the IP
team for use, so a non-piggyback CQ is definitely needed.
Such a library/bundle is hosted in some project, hopefully
Orbit, so the PMC would need to approve that non-piggyback
CQ. I think you're suggesting that such delta changes
shouldn't need PMC approval either, right? At least these
non-piggyback CQs are few and far between compared to the
flood of piggyback CQs...
Do I really as a PMC member look into every version
and check whether that CQ is valid if a previous
version was approved ?
No, the IP team does the due diligence. I think it will
be harder to argue that "library update" CQs don't need
approval than it will be to try to reduce the overall
volume... I wonder would anyone object to that...
A CQ is needed ok, but couldnt that be approved by
the IP Team without the PMC ?
I will raise this question too. Please speak up if
anyone disagrees!
This is really not about me being lazy but rather
about involving multiple parties in a process which as
a consequence only takes longer, I believe.
Personally I try to +1 CQs that come my way as quickly as
possible, usually in a few minutes, so I don't think I'm
generally the bottleneck. Of course sometimes I overlook
things in my email flood.
So PRO removing Piggybacks from my side…
:-)
Cheers
christian
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
|