[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [rt-pmc] Revisiting blanket and test/build CQs
|
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
> >