Improve our description of what needs to be taken through the IP Due Diligence Process.
From the incubation mailing list:
in the IoT PMC we often review CQs by projects for components which the project relies on during runtime (not optionally but as a full pre-req). Some of these components themselves rely on many other components. We are often asked, whether the project needs to create CQs for all of these transitive dependencies as well (given that they are not optional but required during runtime). The project handbook [1] states that "All third-party libraries required by project code will have to be checked and approved by the IP Team."
Following is a list of cases which constitute a "library required by the project". That list is described as "non-exhaustive" and in fact does not explicitly mention transitive dependencies. My understanding is that transitive deps definitely need to be checked/approved, but I would like to get some feedback e.g. frmo Wayne whether this is actually the case.
The use of "non-exhaustive" is intended to refer to the list of examples. Let's check the language to ensure that this intended usage is clear. We should make it clear that the policy applies to the transitive closure of all dependencies.
There may be some useful words in my response:
All content must be taken through the Eclipse IP Due Diligence Process. This includes all dependencies, dependencies of dependencies, etc. [recursive].
FWIW, the operating system and virtual machine are technically dependencies, but we classify them "exempt pre-reqs" per the Guidelines for the Review of Third Party Dependencies (implied, because we don't bother with actual CQs).
This is easy to think about in the context of a monolithic packaged deliverable. Basically anything that's in that hypothetical monolithic package must be taken through the Eclipse IP Due Diligence Process.
It's a little harder to think about when you distribute, say, a Maven JAR. Strictly speaking, you are only distributing that one JAR. But in the process of resolving that JAR, the consumer will need all sorts of other third party content; this content is all "pre-req dependencies" that we need the Eclipse IP Team to review.
Perhaps the most general way of thinking about it is that you need a CQ for all third party content related to your project code that will end up in a product built using your project's technology. It's on this basis that we can, for example, categorize build and test dependencies as "works with". I suspect, however, that I'm venturing off topic...
Activity
(In reply to Wayne Beaton from comment 0)
There may be some useful words in my response:
There definitely are.
-- All content must be taken through the Eclipse IP Due Diligence Process. This includes all dependencies, dependencies of dependencies, etc. [recursive].
FMPOV it would be particularly helpful if the handbook would explicitly mention the "transitive closure" of all dependencies and that this means "all transitive dependencies as well"
FWIW, the operating system and virtual machine are technically dependencies, but we classify them "exempt pre-reqs" per the Guidelines for the Review of Third Party Dependencies (implied, because we don't bother with actual CQs).
This is easy to think about in the context of a monolithic packaged deliverable. Basically anything that's in that hypothetical monolithic package must be taken through the Eclipse IP Due Diligence Process.
It's a little harder to think about when you distribute, say, a Maven JAR. Strictly speaking, you are only distributing that one JAR. But in the process of resolving that JAR, the consumer will need all sorts of other third party content; this content is all "pre-req dependencies" that we need the Eclipse IP Team to review.
Perhaps the most general way of thinking about it is that you need a CQ for all third party content related to your project code that will end up in a product built using your project's technology. It's on this basis that we can, for example, categorize build and test dependencies as "works with". I suspect, however, that I'm venturing off topic...
@geniesaid:This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.
If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
-- The automated Eclipse Genie.
assigned to @wbeaton
