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

[David M Williams <david_williams@xxxxxxxxxx>]

My thoughts on this are in line with everyone
else. As a PMC member I don't see too much point, or need, to approve,
or even have "piggy back' CQs (for most cases). 

Especially, if the bundle "comes
from Orbit", I don't see any need for a piggy back CQ to re-use a
bundle from Orbit. 

If the bundle "come from"
another project, (that is, they are building/packaging) their own third
party bundles in their own Git repository, and not "going through
Orbit" then I do see a little merit in tracking those more carefully.
I think as a PMC member, I wouldn't mind asking "why not use the one
in Orbit" or "why not move it to Orbit".  And, there
could be good reason for it, but ... would be good to know those reasons
and have well documented. 

So, I'd propose the process be changed
at least for those "coming from Orbit".  

Not sure how to verify "it came
from Orbit" instead of elsewhere ... but ... in theory that could
be done with enough work. 

Plus, in Orbit, we do like to have to
a submission to Orbit piggy-back one Eclipse project that needs the bundle
-- and that's primarily to confirm that "at least one Eclipse project
needs it". I know some don't even like that rule, but I think that
"rule" is in place for a good reason ... we don't have the resources
(committers and especially IP staff) to become "OSGi repository for
the world", even if not used by an Eclipse project.  Just explaining
the reason for that one case. 

I hope this helps (and, hope I am not
distracting from original statement, which admit I've lost track of). 

Thanks, 





From:      
 Ed Merks <ed.merks@xxxxxxxxx>
To:      
 eclipse.org-architecture-council@xxxxxxxxxxx,

Date:      
 03/31/2015 12:24 PM
Subject:    
   Re: [eclipse.org-architecture-council]
Who Needs Piggyback CQs?
Sent by:    
   eclipse.org-architecture-council-bounces@xxxxxxxxxxx

---

Gunnar,

Comments below.


On 31/03/2015 5:08 PM, Gunnar Wagenknecht wrote:
> 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
An IP log is not suitable?  I think I'll have a hard time getting
a 
process in place where CQs don't require approval, except maybe for PB
CQs, so another approach is to automate their creation and approval.  
But as I say this I'm confused what automatically generated, 
automatically approve CQ buys you...
>
>
> 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).
Mike will not be happy that this thread becomes a "let's change 
everything" approach...
> (2) I prefer to keep the IP Log for listing such usage as per (1).
But you want them to refer to PB CQs, not directly to the original CQs?
> (3) The IP process should change to an "opt-in" model for
projects on a "per-release" base.
I expect this is a no go.   If you don't want to follow the IP process
you don't belong at Eclipse...
>
> The key to (1) and (2) is likely automation.
The focus of my question is the extent to which PMCs feel the need to 
see and approve PB CQs.  Personally I don't want to see them, I don't
want to have to approve them, and I don't want to create them...
> Your scanner is a good idea, Wayne also has a downloads scanner.
Yes, I've been talking with Wayne.  But it's very easy to depend on
something that's resolve in another p2 repository.  Analyzing the
dependencies (package and bundle requirements) reveals all this nicely.
>   But we also need to capture "compile" and/or "test-only"
dependencies.
As I mentioned, it's possible to analyze a git repository directly (but
only the bundles and features they contain).
>   Java code can be analyzed for package imports. But there is
also a growing generation of projects in different languages and not using
p2.
I certainly won't be doing that.  I'm sure the ocean will boil and
hell 
will have frozen over before that's done...
>
> Point (3) is probably the most controversial one. Why do we need to
bother with CQs at all if a project doesn't care?
Because Eclipse cares.  Because when you come to Eclipse you know
what 
you're getting, what the license is, and that it's all be reviewed and
put through the meat grinder.
>   I believe that we are putting too much work onto the IP team
without ever asking ourselves if that is all really necessary.
It's not necessary to be an Eclipse project.
> There is probably a significant number of projects which don't need
the full IP program.
The consumers are the ones who need it and can currently expect it...
> 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.
I can guarantee that I will never get such a thing past the committee.
 :-(
>
>
> -Gunnar
>

_______________________________________________
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.