Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
>>> for something 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
>


Back to the top