[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] Who Needs Piggyback CQs?
|
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
