[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [rt-pmc] Revisiting blanket and test/build CQs
|
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
> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
> Sent: May-19-10 3:34 PM
> To: 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
>
>
>
> On Wed, May 19, 2010 at 14:19, Mike Milinkovich
> <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
> >> [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
> >> 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
> >>
> >>
> >>
> >> On Fri, May 14, 2010 at 15:11, Jeff McAffer <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
> >> >>> [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
> >> >>> 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
> >> >>>
> >> >>> defeats some of the purpose of the whole process through I suspect
> :/
> >> >>>
> >> >>> jesse
> >> >>>
>>> >>> --
> >> >>> jesse mcconnell
> >> >>> jesse.mcconnell@xxxxxxxxx
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Fri, May 14, 2010 at 13:24, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
> >> wrote:
> >> >>>> Sure. We do need a definition then for "distribute". If that means
> >> "have
> >> >>> it in your zip on 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]
> >> 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
> >> >>>>>>>>>>>>> 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
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>> _______________________________________________
> >> >>>>>>>>>>> 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
> >> >>>>>>>>>>
> >> >>>>>>>>> _______________________________________________
> >> >>>>>>>>> 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
> >> >>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> 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
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> 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
> >> >
> >> > _______________________________________________
> >> > rt-pmc mailing list
> >> > rt-pmc@xxxxxxxxxxx
> >> > https://dev.eclipse.org/mailman/listinfo/rt-pmc
> >> >
> >
> >
