[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Revisiting blanket and test/build CQs
|
It turns out we are not set after all! See http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4040, http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4041, and http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4042.
I am clear in my own mind about which test dependencies need CQs. Essentially, I am planning to raise "works with" CQs to cover all necessary test dependencies, i.e. where the library in question could not easily be switched out and replaced by an alternative.
On that basis, EasyMock, JUnit, and various libraries necessarily depended on by tests will need "works with" CQs.
If anyone finds that insufficiently clear, please say so now so we can re-open the discussion. Otherwise, let's get on and approve the above CQs and reassure the legal team that we have an agreed position.
Thanks,
Glyn
On 20 May 2010, at 14:20, Glyn Normington wrote:
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<mailto: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<http://foundation.eclipse.org>
[mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
Sent: May-19-10 3:34 PM
To: mike.milinkovich@xxxxxxxxxxx<mailto: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<mailto:jesse.mcconnell@xxxxxxxxx>
On Wed, May 19, 2010 at 14:19, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxx<mailto: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<http://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<mailto: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<mailto:jesse.mcconnell@xxxxxxxxx>
On Fri, May 14, 2010 at 15:11, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx<mailto: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<http://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<mailto: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<http://eclipse.org>
defeats some of the purpose of the whole process through I suspect
:/
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx<mailto:jesse.mcconnell@xxxxxxxxx>
On Fri, May 14, 2010 at 13:24, Jeff McAffer
<jeff@xxxxxxxxxxxxxxxxx<mailto:jeff@xxxxxxxxxxxxxxxxx>>
wrote:
Sure. We do need a definition then for "distribute". If that
means
"have
it in your zip on downloads.eclipse.org<http://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> [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<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx<mailto:rt-pmc@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/rt-pmc
