Re: [rt-pmc] Revisiting blanket and test/build CQs

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

When jetty was going through the review process we had the
understanding that test dependencies were no different then anything
else in terms of the code being checked into svn.  If it was required
to build and/or run at all it had to have a CQ and go through the
proper channels.  That being said we still use the artifacts from the
maven central repo for the actual testing but we have solid IPLog
representation for everything (case by case) and we purposefully left
code of jetty on The Codehaus because it would have been problematic
to pass dependencies through the CQ process or the code implementing
it through the IP Validation/Verification process.  When we move to
distribute anything from eclipse.org it uses everything from Orbit
like it should.

One case I would like to add for clarification is an artifact that is
never going to be downloaded from eclipse.org, like for example a
maven plugin.  It has firm dependencies on things like the maven
plugin api and stuff like that but since its never going to be
download from eclipse.org, much less will its dependencies see the
light of orbit....are we still banned from having that in our svn @
eclipse?  We would release it into the maven central repository same
as everything else we release to maven central...

Anyway, I am encouraged to seem further light shown on the issues.

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Tue, May 11, 2010 at 14:13, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
> 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
>
> For reference the policy is:
> http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>