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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

the only part I question is the previous usage of easymock of an
example of something that was totally a test dependency and what I
thought was the explicit decision that it did not need a CQ as it was
not being distributed in any way..

however given Mike's addition above that the definition of distribute
also includes a 'svn co' then I do agree with the definition as you
state

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Tue, May 25, 2010 at 11:22, Mike Keith <michael.keith@xxxxxxxxxx> wrote:
> As per my comments in the CQ referenced below this was my understanding as
> well, i.e., that a "works with" CQ is needed when the library in question
> could not be switched out without changing code (either project or project
> test code).
>
> Jesse, do you agree with this? Is nobody disagrees then we can call this
> issue resolved. (Silence means agreement :-).
>
> On 5/22/2010 3:03 AM, Glyn Normington wrote:
>>
>> It turns out we are not set after all! See
>> http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4040,
>> http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4041, and
>> http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4042.
>>
>> I am clear in my own mind about which test dependencies need CQs.
>> Essentially, I am planning to raise "works with" CQs to cover all necessary
>> test dependencies, i.e. where the library in question could not easily be
>> switched out and replaced by an alternative.
>>
>> On that basis, EasyMock, JUnit, and various libraries necessarily depended
>> on by tests will need "works with" CQs.
>>
>> If anyone finds that insufficiently clear, please say so now so we can
>> re-open the discussion. Otherwise, let's get on and approve the above CQs
>> and reassure the legal team that we have an agreed position.
>>
>> Thanks,
>> Glyn
>>
>> On 20 May 2010, at 14:20, Glyn Normington wrote:
>>
>> Ok. Then we're set.
>>
>> Thanks to everyone who contributed to the discussion.
>>
>> Glyn
>> On 20 May 2010, at 14:11, Mike Milinkovich wrote:
>>
>> I think that raising a "works-with" CQ for Hibernate in this case is a
>> low-cost way to document the usage. I would expect it to be approved
>> quickly.
>>
>>
>>
>> -----Original Message-----
>> From: Glyn Normington [mailto:gnormington@xxxxxxxxxx]
>> Sent: May-19-10 11:13 PM
>> To: mike.milinkovich@xxxxxxxxxxx<mailto:mike.milinkovich@xxxxxxxxxxx>;
>> Runtime Project PMC mailing list
>> Cc: Jesse McConnell
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>
>> Hi Mike
>>
>> To answer your question - Virgo only downloads hibernate and neither
>> distributes it nor checks it into version control.
>>
>> The conclusion of the PMC discussions does seem to be, however, that Virgo
>> needs to raise a "works with" CQ for hibernate because of the fact that we
>> have tests that validate the dependency chain Virgo->Spring-
>> (optionally)Hibernate and ensure Hibernate works correctly in Virgo.
>>
>> Do you concur with this outcome?
>>
>> Glyn
>> On 20 May 2010, at 02:51, Mike Milinkovich wrote:
>>
>>
>> The distinction is that if the code is in our SCM system then we are
>> distributing it. Whereas if we just download as needed into a build
>> process, or if it resides on a test/build server not generally accessible
>> we are not distributing it. From a legal perspective, that is an important
>> difference.
>>
>>
>> -----Original Message-----
>> From: Content-filter at
>> foundation.eclipse.org<http://foundation.eclipse.org>
>> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
>> Sent: May-19-10 3:34 PM
>> To: mike.milinkovich@xxxxxxxxxxx<mailto:mike.milinkovich@xxxxxxxxxxx>
>> Cc: Runtime Project PMC mailing list
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>
>> I suspect the answer to that would be yes, hibernate would only exist
>> on the test machine for that example...
>>
>> but I personally don't see the distinction because what is the
>> difference between something being in SCM vs being downloaded as
>> needed automatically by a build system, in essence that is a
>> technical/implementation point more then any anything..using ant you
>> mostly have jars checked into the scm but you move up to ant+ivy or
>> maven and your pulling them down automatically...i don't think see how
>> those conditions are/should be treated differently
>>
>> I would think (perhaps incorrectly) that the desire is to capture the
>> intent and purpose behind the dependency, in the case of a build/test
>> only dependency being is that dependency strictly a glob of test data
>> that given another option you would not have issue with switching to
>> vs the intent being to test specific compatibility with that specific
>> glob o' data.
>>
>> cheers,
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx<mailto:jesse.mcconnell@xxxxxxxxx>
>>
>>
>>
>> On Wed, May 19, 2010 at 14:19, Mike Milinkovich
>> <mike.milinkovich@xxxxxxxxxxx<mailto:mike.milinkovich@xxxxxxxxxxx>>
>>  wrote:
>> Jesse, et al,
>>
>> One of the key factors in our eyes is whether any of the code in
>> question
>> is going to be contained in the Eclipse SCM. In the example of "virgo
>> ->
>> spring ->  hibernate", will a copy of hibernate be contained in the
>> Eclipse
>> SCM? Or would Hibernate only be on some test machine somewhere?
>>
>> Thanks.
>>
>>
>> -----Original Message-----
>> From: Content-filter at
>> foundation.eclipse.org<http://foundation.eclipse.org>
>> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse
>> McConnell
>> Sent: May-18-10 12:36 PM
>> To: Runtime Project PMC mailing list
>> Cc: mike.milinkovich@xxxxxxxxxxx<mailto:mike.milinkovich@xxxxxxxxxxx>
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>
>> I talked with Jeff about this at length earlier and offered to take a
>> stab and writing up our discussion.  Jeff, feel free to chime in as
>> needed on it.
>>
>> Starting off simply...
>>
>> A project needs to declare a CQ for anything in use that is outwardly
>> facing to a user...be it a direct dependency (servlet-api) or a
>> transitive dependency that your specifically using (equinox http
>> service ->  jetty ->  servlet-api).
>>
>> The caveat that we spoke to directly here as being open to
>> interpretation was in the case of virgo (virgo ->  spring ->
>> hibernate).  There are two things going on here that I think give
>> form
>> to the intent of the process.
>>
>> * if the usage is purely for test (virgo ->  spring ->  using hibernate
>> as purely test data as it exercises a peculiar classloader issue)
>> then
>> you do not need a CQ
>> * if the usage is to test/validate interoperability (virgo ->  spring
>> ->  using hibernate as lots of clients use it and we validate it works
>> with it) then that is clearly a case for a Works With CQ
>>
>> The specific litmus test being that if someone came along and
>> implemented a couple of classes that exhibited the desired
>> classloader
>> issues would you switch over to those classes or would you still test
>> with hibernate.
>>
>> I think that example clearly defines the scoping in which a project
>> lead needs to think about things when asking themselves if they need
>> any sort of CQ for a given test or build dependency.
>>
>> If you can go through the rigor of examining any given test or build
>> dependency with that sort of litmus test then I suspect we are
>> adhering to the spirit of the law here, at least until such time as
>> it
>> is codified in process somewhere
>>
>> thoughts?
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx<mailto:jesse.mcconnell@xxxxxxxxx>
>>
>>
>>
>> On Fri, May 14, 2010 at 15:11, Jeff
>> McAffer<jeff@xxxxxxxxxxxxxxxxx<mailto:jeff@xxxxxxxxxxxxxxxxx>>
>> wrote:
>> Agreed and I absolutely want to limit burden and do not propose
>> super
>> detail defs or procedures. Keep it simple.
>>
>> My original query on the meaning of "distribute" was driven by the
>> fact
>> that I've seen all of the following uses of the word "distribute" by
>> perfectly sane, reasonable and rational comitters at Eclipse.
>> - putting code in CVS at eclipse
>> - compiling code (or not) and making it available as a convenience
>> zip
>> on
>> the project page without a release review
>> - whatever you put through the release review
>>
>> This is not unique to "tests" but comes up in that space because
>> different teams do different things with their tests.
>>
>> Which is it?  Enquiring minds want to know...
>>
>> Jeff
>>
>>
>> On 2010-05-14, at 3:57 PM, Mike Milinkovich wrote:
>>
>> Gimme a break.
>>
>> "Distribute" means distribute via any reasonable mechanism. Eclipse
>> downloads and update sites are obvious inclusions. But pushing
>> something
>> to
>> Maven Central is obviously distributing.
>>
>> Definitions and procedures detailed enough to prevent people from
>> doing
>> things which obviously break the spirit and intent of our community
>> is,
>> unfortunately, what leads to burdensome bureaucracy.
>>
>> -----Original Message-----
>> From: Content-filter at
>> foundation.eclipse.org<http://foundation.eclipse.org>
>> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse
>> McConnell
>> Sent: May-14-10 3:45 PM
>> To: Runtime Project PMC mailing list
>> Cc: mike.milinkovich@xxxxxxxxxxx<mailto:mike.milinkovich@xxxxxxxxxxx>
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>
>> i love this definition as it lets me freely develop maven plugins
>> in
>> eclipse svn and push them into maven central without a care in the
>> world since we would never put it up for direct download on
>> eclipse.org<http://eclipse.org>
>>
>> defeats some of the purpose of the whole process through I suspect
>> :/
>>
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx<mailto:jesse.mcconnell@xxxxxxxxx>
>>
>>
>>
>> On Fri, May 14, 2010 at 13:24, Jeff McAffer
>> <jeff@xxxxxxxxxxxxxxxxx<mailto:jeff@xxxxxxxxxxxxxxxxx>>
>> wrote:
>> Sure.  We do need a definition then for "distribute". If that
>> means
>> "have
>> it in your zip on downloads.eclipse.org<http://downloads.eclipse.org>"
>> then projects that do not
>> make
>> pre-built tests available can write test code checked into CVS
>> that
>> has
>> direct references to GPL code with no CQs. We can choose to not
>> care
>> about
>> this (I'm more than happy to stop entering CQs for the things we
>> use
>> in
>> our
>> tests) but there has to be a very clear definition.
>>
>> Related, do projects "release" their tests?  That is, do the IP
>> logs
>> submitted for release reviews need to cover the test related code?
>>
>> Jeff
>>
>> On 2010-05-14, at 2:08 PM, Mike Milinkovich wrote:
>>
>> At the risk of saying something stupid, shouldn't the rule be
>> more
>> along
>> the
>> lines of "if you distribute it or if the consumer must have it,
>> you
>> CQ
>> it" ?
>>
>>
>> -----Original Message-----
>> From: rt-pmc-bounces@xxxxxxxxxxx<mailto:rt-pmc-bounces@xxxxxxxxxxx>
>>  [mailto:rt-pmc-
>> bounces@xxxxxxxxxxx]
>> On
>> Behalf Of Glyn Normington
>> Sent: May-14-10 2:01 PM
>> To: Runtime Project PMC mailing list
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>
>> That "You reference it? You CQ it" rule would lead Virgo into
>> needing
>> detailed CQs for many more 3rd party libraries. Consider a
>> simple
>> test
>> of
>> thread context class loading. The test would most likely have a
>> dependency
>> on the library doing the thread context class loading, but only
>> because
>> the
>> test is specifically checking that library. So we would end up
>> raising
>> a
>> CQ
>> forsomething which has no dependency from the runtime Virgo
>> code.
>> I'm
>> not
>> sure of the value of this except to keep the rules simple,
>> which
>> admittedly
>> has some value in and of itself, but not much IMO.
>>
>> Glyn
>> On May 14, 2010, at 5:29 PM, Jeff McAffer wrote:
>>
>> I specifically put in that exception to match what other
>> projects I
>> know
>> of do. It is IMHO interesting to know and track what third
>> party
>> libs
>> are
>> being used explicitly and directly in tests. This also
>> simplifies
>> the
>> CQ
>> guidelines.  "You reference it? You CQ it"
>>
>> Jeff
>>
>> On 2010-05-14, at 12:07 PM, Mike Keith wrote:
>>
>> I agree with Adrian, and with Jeff, with the exception that
>> if
>> the
>> code
>> that explicitly references the lib is only test code and is not
>> shipped
>> with the project then I don't think a CQ should need to be
>> entered,
>> since
>> as Jeff put it, these kinds of test dependencies are only
>> "needed
>> to
>> complete the development process (i.e., build and test)."
>>
>> On 5/14/2010 11:45 AM, Jeff McAffer wrote:
>> I vote for not raising the CQs with the understanding that
>> the
>> libraries in question meet the criteria discussed in this
>> thread.
>> Under
>> that model they are just tools that are needed to complete the
>> development
>> process (i.e., build and test).
>>
>> The answer would change however if
>> - there is any code in the project (test or otherwise) that
>> explicitly
>> references the libs
>> - there is any indication that users will have to (or may
>> want
>> to)
>> get
>> these libs to make the *Virgo* supplied function go.
>>
>> I would rely on Virgo project leadership to monitor the
>> cases
>> in
>> which
>> these libs are being used and ensure that they meet the model
>> outlined.
>>
>> Jeff
>>
>> On 2010-05-14, at 11:11 AM, Glyn Normington wrote:
>>
>>
>> Virgo has a deadline of Friday 21 May for raising all
>> necessary
>> CQs.
>> I
>> would like the PMCs position on blanket test/build CQs by COB
>> on
>> Wednesday
>> 19 May otherwise I'll create more blanket CQs (for the licenses
>> other
>> than
>> LGPL) like CQ 4083.
>>
>> I have heard various opinions expressed ranging from "don't
>> raise
>> CQs
>> to these at all" (to avoid CQs like 4083 being accidentally
>> abused
>> by
>> piggy-backers) to statements implying that we ought to raise
>> one
>> CQ
>> per
>> separate build/test dependency (but without any clear
>> explanation
>> of
>> the
>> benefit of doing this).
>>
>> I don't want to rehash this thread as we can all look in
>> the
>> archives,
>> but perhaps someone on the PMC would care to propose a
>> direction
>> forward.
>>
>> My vote would be not to raise such CQs as this seems to be
>> the
>> practice in other projects (witness the discussion of allowing
>> the
>> second
>> Hudson build machine access to the internet in order to pull
>> down
>> dependencies at build time).
>>
>> Thanks,
>> Glyn
>> On 14 May 2010, at 03:56, Glyn Normington wrote:
>>
>>
>> Confirmed.
>>
>> Glyn
>> On 13 May 2010, at 17:49, Douglas Clarke wrote:
>>
>>
>> Glyn,
>>
>> Can you confirm then that:
>>
>> 1. there will be no shipped code from Virgo that imports
>> classes/interfaces from these LGL libraries?
>>
>> 2. that there is no functionality of Virgo that will ship
>> that
>> can
>> only be used when one of these LGPL libraries is on the
>> classpath?
>>
>> Doug
>> -----Original Message-----
>> From: Glyn Normington [mailto:gnormington@xxxxxxxxxx]
>> Sent: May 13, 2010 9:39 AM
>> To: Runtime Project PMC mailing list
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build
>> CQs
>>
>>
>> The generic thread context class loading support in Virgo
>> is
>> active
>> all the time.
>>
>> To use the support, the user places the relevant third
>> party
>> library
>> in the Virgo repository and then deploys an application that
>> used
>> the
>> third
>> party library.
>>
>> The user must ensure that their application bundles
>> export
>> packages
>> for any classes that need to be loaded via a thread context
>> class
>> loader.
>> The must also include their application bundles in a scoped
>> plan
>> if
>> the
>> application has more than one bundle.
>>
>> Virgo ensures that a suitable thread context class loader
>> is
>> set
>> when the third party library is invoked which the third party
>> library
>> can
>> then use to load application classes.
>>
>> I hope that's clear! :-)
>>
>> Glyn
>>
>> On 13 May 2010, at 14:13, Jesse McConnell wrote:
>>
>>
>> Glyn,
>>
>>
>> 2. There are no dependencies whatsoever from the Virgo
>> runtime
>> to
>> the 3rd party library. For example, a 3rd party library used by
>> Virgo
>> applications uses thread context class loading. We have tests
>> with
>> such
>> libraries to make sure Virgo's thread context class loading
>> support
>> works
>> correctly.
>>
>>
>> What does a user that wantsthis functionality have to do
>> to
>> make
>> that
>> sort of support active?  I suspect that will help clear
>> things
>> up
>> some
>>
>> cheers,
>> jesse
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>>
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>>
>>
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>
>>
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx<mailto: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
>>
>>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>