Great topic Doug. Thanks for the context. I agree with the overall concern around blanket CQs. I am also interested in people's thoughts on the position of test code in the IP landscape.
There has been an increase in the number of libs needed only for testing. In the past we have not drawn much of a distinction between coded needed for testing and other dependencies. Things like EasyMock are somewhat obvious and unproblematic but, what about, *for example*, using Hibernate for testing? Raises questions like: - What are you testing and won't users have to get hibernate too? - If hibernate is just one of the options, can we pick one that would be less problematic? - how does testing code relate to incubating code in the eyes of the IP system?
As with much of the IP policy, I am quite open to different positions but feel strongly that we have a clear and simple set of guidelines so we can stop having this kind of discussion :-)
Jeff
On 2010-05-11, at 2:38 PM, Douglas Clarke wrote:
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
_______________________________________________ rt-pmc mailing list rt-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/rt-pmc
|