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

[Glyn Normington <gnormington@xxxxxxxxxx>]

I like that but I guess we should probably include "if you check it in" to that rule to be clear.

Glyn
On May 14, 2010, at 7: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