[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Revisiting blanket and test/build CQs
|
Ok. Then we're set.
Thanks to everyone who contributed to the discussion.
Glyn
On 20 May 2010, at 14:11, Mike Milinkovich wrote:
> 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
>
