[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [rt-pmc] Revisiting blanket and test/build CQs
|
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; 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
> >> [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
> >>>>>
> >>>
> >>>
> >
> > _______________________________________________
> > rt-pmc mailing list
> > rt-pmc@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/rt-pmc
