Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Revisiting blanket and test/build CQs
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:
  1. 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.
  2. 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

Back to the top