Doug,
Comments below.
On 31/03/2015 4:22 PM, 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.
Yes, I imagine the platform team is concerned about all the bundles
it ships, and for EMF itself I'm also very very concerned about
dependencies. But for Modeling I don't feel my role it so second
guess the people, who as you say, "are doing the real work". So I
think this highlights the fact that the team leads already take
responsibility for their projects...
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.
Yes, less process and less "second guessing" the team leads. So I
count that as another voice if favor of reducing the PMC's role in
approving CQs, even beyond piggyback CQs.
If summary gathering is fully automated, it's likely possible to
automatically send an email when the dependencies grow/change from
one day/week/month to the next; this was Mike's idea.
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
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxxhttps://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.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.
|