[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[rt-pmc] Revisiting blanket and test/build CQs
|
RT
PMC,
I would like to
revisit the discussion on blanket CQs for test/build such as CQ 4083 recently
approved for Virgo. I apologize that I was unable to participate in the earlier
discussion but after looking at this CQ I believe we need to revisit the issue
to ensure we are all clear on how we handle these
situations.
My concerns
include:
- The distinction
between build/test and code that is contained in the Eclipse code repositories
and the code/binaries that are distributed from the projects.
I
firmly believe that all code that is included in the distribution/release from
a project that has a 3rd party dependency either explicitly (i.e. import) or
implicitly (functionality requires the library must be on classpath to use)
should have a separate CQ listing the individual dependency and explaining how
it meets the works-with requirements and that CQ be backed up with approval on
the PMC mailing list.
Additionally there are some who believe that all
code in the repository, including test cases, are part of the project's
'release' even if not distributed in bundles/zip. We should discuss where we
draw the line between build/test/release and how these CQs for 3rd party
dependencies are handled.
- I am concerned that
a blanket CQ is too broad and does not offer much value from an IP due
diligence perspective. I would prefer to see individual CQs or at a minimum a
list of projects and versions and possibly jar files that the CQ applies to.
In the case of 4083 I believe the intent was for testing utilities only and
not to any Virgo code that would be shipped but the broad nature of the CQ
makes it unclear what it applies to and could lead to committers inadvertently
assuming they can include LGPL dependencies without the proper
CQs.
I am happy to get
the discussion started here and then continue on next week's PMC
call.
Cheers,
Doug
