[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Revisiting blanket and test/build CQs
|
So I suppose it comes down to whether people believe that test code is
part of the release or not, but if the test code is not shipped then
there might be a good argument for saying that it would be worthwhile to
add some allowances into the IP process for these kinds of testing
dependencies. It seems that this has been kind of murky territory for
many projects for some time, now.
On the other side, I guess one of the key points that has been made is
that any code that is being shipped that binds to a dependency (that is
not shipped) is a simple and regular works-with dependency and would not
fall under a simplified testing dependency category. Using the concrete
examples that have been brought up of EasyMock and Hibernate, for
example, assuming that there is no code in the shipped project that has
any reference to any EasyMock classes, but that the tests reference the
EasyMock APIs, the EasyMock could be considered a "test dependency". If
the project has any code that references or binds to a Hibernate API,
though, then it would require a normal works-with dependency CQ in order
to use that jar for testing, or ship any of the code that assumes the
hibernate jars in order to function.
Does this make sense?
On 5/12/2010 10:05 AM, Mike Milinkovich wrote:
Since I am lurking on this list, I might as well chime in.
I think that Doug's points on explicit and implicit dependencies are spot
on.
That said, the primary motivation for CQs and our due diligence process is
to capture information relevant to the use of code distributed from the
Eclipse Foundation. In particular, to provide information and mitigate risk
relevant to the adoption and use of Eclipse projects in commercial products.
There are certainly some ambiguities and corner cases, but let's not lose
sight of what drives our collective behaviour.
Given that, test-time or build-time dependencies that are simply an artifact
of our production processes likely require IP processes which vary somewhere
between minimal and none. I believe that the challenge for the PMC is to
make the determination as to whether something really is just a
test/build-time dependency or whether it really is an implicit dependency
relevant to a consumer of the technology. I recognize that upon occasion
those distinctions can be subtle.
-----Original Message-----
From: rt-pmc-bounces@xxxxxxxxxxx [mailto:rt-pmc-bounces@xxxxxxxxxxx] On
Behalf Of Glyn Normington
Sent: May-11-10 10:33 PM
To: Runtime Project PMC mailing list
Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
I agree it is good to nail this subject down while it is still unclear in
people's minds. Thanks for raising it Doug.
> From my perspective, CQ 4083 (in the case of LGPL) provides a formal
record that Virgo build/test dependencies which are neither checked in at,
nor distributed from, eclipse.org: (a) are agreed to be "works with"
dependencies, and (b) are benign from an IP perspective.
Such CQs also solve the practical problem that we don't have an automatic
means to synchronise a detailed list of build/test dependency CQs with the
dependencies encoded in the build system. We also can't generate the list
from the transitive dependencies of the runtime code as in many cases
there
is no such transitive dependency (even when the complete generality of the
Spring framework is taken into account).
So the only way we could verify we had raised the correct set of CQs would
be to do a laborious and error-prone trawl before each release (unlike
checked in or distributed dependencies which are relatively bounded in
number and trivial to scan for).
But suppose for the sake of argument that we had such a system and every
time we added a new build/test dependency, we were prompted to raise a new
CQ. What value would this provide?
Each new CQ would log a build/test dependency on third party library xxx
at
version nnn with license yyy. I believe the thinking as far as PMC
approval
would be: the new CQ is yet another in the long list of build/test
dependencies so there is no problem in approving it. I also believe the
thinking in the legal team would be: if the new CQ has the same license as
some of the other build/test dependencies, again there is no problem in
approving it. If that analysis is correct, the new CQ would *only* add
real
value if it introduced a build/test dependency with a previously unused
license. Well, that is precisely the same value that CQ 4083 (in the case
of LGPL) is providing, but at a much lower net cost to everyone involved.
So, personally, I have yet to understand what value a detailed list of
build/test dependency CQs would add, even if it was practical to maintain
such a list. I'd be grateful if someone could enlighten me.
Thanks,
Glyn
On 11 May 2010, at 21:10, Jesse McConnell wrote:
When jetty was going through the review process we had the
understanding that test dependencies were no different then anything
else in terms of the code being checked into svn. If it was required
to build and/or run at all it had to have a CQ and go through the
proper channels. That being said we still use the artifacts from the
maven central repo for the actual testing but we have solid IPLog
representation for everything (case by case) and we purposefully left
code of jetty on The Codehaus because it would have been problematic
to pass dependencies through the CQ process or the code implementing
it through the IP Validation/Verification process. When we move to
distribute anything from eclipse.org it uses everything from Orbit
like it should.
One case I would like to add for clarification is an artifact that is
never going to be downloaded from eclipse.org, like for example a
maven plugin. It has firm dependencies on things like the maven
plugin api and stuff like that but since its never going to be
download from eclipse.org, much less will its dependencies see the
light of orbit....are we still banned from having that in our svn @
eclipse? We would release it into the maven central repository same
as everything else we release to maven central...
Anyway, I am encouraged to seem further light shown on the issues.
cheers,
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Tue, May 11, 2010 at 14:13, Jeff McAffer<jeff@xxxxxxxxxxxxxxxxx>
wrote:
Great topic Doug. Thanks for the context. I agree with the overall
concern
around blanket CQs. I am also interested in people's thoughts on the
position of test code in the IP landscape.
There has been an increase in the number of libs needed only for
testing. In
the past we have not drawn much of a distinction between coded needed
for
testing and other dependencies. Things like EasyMock are somewhat
obvious
and unproblematic but, what about, *for example*, using Hibernate for
testing? Raises questions like:
- What are you testing and won't users have to get hibernate too?
- If hibernate is just one of the options, can we pick one that would
be
less problematic?
- how does testing code relate to incubating code in the eyes of the IP
system?
As with much of the IP policy, I am quite open to different positions
but
feel strongly that we have a clear and simple set of guidelines so we
can
stop having this kind of discussion :-)
Jeff
On 2010-05-11, at 2:38 PM, Douglas Clarke wrote:
RT PMC,
I would like to revisit the discussion on blanket CQs for test/build
such as
CQ 4083 recently approved for Virgo. I apologize that I was unable to
participate in the earlier discussion but after looking at this CQ I
believe
we need to revisit the issue to ensure we are all clear on how we
handle
these situations.
My concerns include:
The distinction between build/test and code that is contained in the
Eclipse
code repositories and the code/binaries that are distributed from the
projects.
I firmly believe that all code that is included in the
distribution/release
from a project that has a 3rd party dependency either explicitly (i.e.
import) or implicitly (functionality requires the library must be on
classpath to use) should have a separate CQ listing the individual
dependency and explaining how it meets the works-with requirements and
that
CQ be backed up with approval on the PMC mailing list.
Additionally there are some who believe that all code in the
repository,
including test cases, are part of the project's 'release' even if not
distributed in bundles/zip. We should discuss where we draw the line
between
build/test/release and how these CQs for 3rd party dependencies are
handled.
I am concerned that a blanket CQ is too broad and does not offer much
value
from an IP due diligence perspective. I would prefer to see individual
CQs
or at a minimum a list of projects and versions and possibly jar files
that
the CQ applies to. In the case of 4083 I believe the intent was for
testing
utilities only and not to any Virgo code that would be shipped but the
broad
nature of the CQ makes it unclear what it applies to and could lead to
committers inadvertently assuming they can include LGPL dependencies
without
the proper CQs.
I am happy to get the discussion started here and then continue on next
week's PMC call.
Cheers,
Doug
For reference the policy is:
http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_P
arty_Dependencies_Final.pdf
_______________________________________________
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
