I had a talk with Barb about this a bit and wanted to follow up on
this thread with this blurb from our conversation...
my current frustration with the IP policy/procedure is the existence
of a 'safe on the build server' classification for some things. In my
little slice of heaven we write software that builds straight out of
svn...and the current definition of 'distribution' includes what is in
svn...which means that I am unable to make use of this 'safe on the
build server' classification of IP. From what I hear the whole 'safe
on the build server' exists because there is an explicit understanding
that the builds produced on the build server are not 'eclipse
distributions'.
so I don't understand how there exists a case where a build occurring
on the eclipse build server is not a distribution but somehow software
being built from something checked out from SVN is some how an
'eclipse distribution'. I understand that is absurd and its not
'really' but if I want to open a CQ to use something like apache
directory service its basically a rubber stamp if I have it on the
build server and use it there, but if my build system has an actual
'dependency' declared on it for usage in a test case (not going into
my distribution at _all_, just a unit test) it is suddenly a full
fledged dependency (because there is no distinguishing between test
scope or distribution scope).
cheers,
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxxOn Mon, Sep 13, 2010 at 15:45, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
Hey Barb,
Thanks for the additional info. Comments embedded.
Jeff
On 2010-09-13, at 2:11 PM, Barb Cochrane wrote:
1) Eclipse-developed test code deposited in the repository calling
third party test code which does not reside on Eclipse servers.
Ø In the cases described, third party code could be characterized as a
“workswith” or perhaps “exempt pre-req”
Can you clarify "could"? Is it "should" or "must"?
As I recall from the discussion there were various shades here. There are
a) test setups that just need some other function to be present but do not
reference this function directly in any code.
b) test setups that need specific function to be present but still do not
reference the function directly
c) test setups that directly reference the third party libraries but that
function is not part of the actual released output of the project
Other scenarios where the third party references come from (to be) released
project output are easier to handle as classical dependencies. The subtlety
in the above comes from the absence/presence of direct references and the
fact that test code is not generally released so is not typical consumable
project output. That is, we don't expect any significant number of people to
get this code (see case 2 below). Under that model, scenarios a-c above
would be instances of case 2.
Ø The process outlined in the Guidelines for the Review of Third Party
Dependencies would apply (as there is no distinction made based on the type
of code involved)
Ø It is our understanding that the dynamic nature of calls to these
third party packages would make the task of creating CQs for each package an
extraordinarily heavy burden
Ø The IP team is in the process of reviewing the IP Policy to try to
identify what we can do to alleviate this burden. Janet will raise any
suggested changes to the Policy to the IP Advisory Committee as necessary.
2) A risk was identified in that there are a small number of
bleeding-edge developers (low single percentage of users) who may download
code from the build server or from the Eclipse repository before it is
“officially” released by a project. In either case, the downloader may
consume code that has not been fully reviewed / approved by the IP team.
We appreciate this risk being highlighted but feel the additional controls
necessary to eliminate this small risk would not justify the adverse impact
such additional controls would have on the community.
3) There was a question raised as to why CQs are required for
“workswith” dependencies, but not their further dependencies. In the case
of dependencies, we are trying to highlight to our downstream consumers the
Eclipse Project dependencies in such a way so that they may investigate
further and make decisions accordingly. In so doing, we must determine what
level of information is reasonable to provide given our resource
constraints. It was felt that the first level of information regarding
dependencies struck a reasonable balance given our current staffing levels.
I hope that helps. If an additional conference call would be useful,
please let me know. I hope to update you further on the first topic in the
next couple of weeks.
Cheers,
Barb Cochrane
Eclipse Foundation, Inc.
Phone 613.224.9461 ext 232
Eclipse Summit Europe, Nov 2-4
http://www.eclipsecon.org/summiteurope2010/
_______________________________________________
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