|
Jim,
After reading what I've read, I think exempt prereq makes the most
sense. See it further down in the same pdf I referred to.
It categorizes them the same as Windows, Linux, Java, etc. i.e.
Ubiquitous platform tech that the user installs for themselves but
the projects can sit on top.
Andrew
On 26/03/15 11:53, Jim Hughes wrote:
Hi all,
For Hadoop, Spark, Accumulo, etc., I'd really, really like to see
a bulk way for us to knock out lots of those dependencies as
'workswith' rather than there being any body/group, etc which has
to deal with dozens of requests.
Cheers,
Jim
On 03/26/2015 09:43 AM, Andrew Ross
wrote:
Hi All,
First thing, I went back and refreshed my memory about the
board resolutions for LocationTech that allowed non EPL
licenses & LGPL for certain components... it approved the
license, and not the software, so that's why things
like Geotools are still going through IP review.
I'm still digging regarding the Spark using metrics-core
issue. Related, from:
https://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
I can see how one might argue that GeoTrellis (for instance)
has additional functionality enabled when dropped in with
Spark, but can exist without it in other contexts. In that
case, maybe there's an argument to be made for workswith. It's
not black & white though so I'll chat with Janet &
Sharon to get their thoughts.
Also, from the same document:
"
2. All "works-with" dependencies as determined by the PMC are
approved for use by the projects without further EMO review. "
So, assuming I don't learn reasons why it shouldn't be so, it
may be that the PMC agreeing that things like Hadoop, Spark,
Accumulo, and distros of each are workswith dependencies may
resolve a lot of this.
More soon,
Andrew
On 25/03/15 16:53, Andrew Ross wrote:
Hi Everyone,
Here are some quick & simple minutes captured from today's
meeting. Please feel free to add/modify/delete as needed.
The meeting took place at 3pm eastern via. Google Hangout
In attendance were Rob, Jim, David, and Andrew.
To start, Andrew noted that Google Code (& Codehaus) are
shutting down. Andrew reached out to the S2 project to see if
they might be interested in coming to LocationTech. Response
was a bit cool at first, but discussion continues & they
are interested in collaboration.
Discussion moved on to the list of items for the LocationTech
Steering Committee & Eclipse Foundation Board exceptions.
JAI & EPSG are pretty clear. Anything else? (see
doc here to collaborate on that)
Discussion continued about Spark & in an issue around
metrics-core, one of Spark's dependencies with some issues
(~125 developers & no CLA, see IPZilla
8444). GeoTrellis itself doesn't use that functionality.
Should it stub out metrics-core with it's own custom Spark?
Can it simply leave it to the user to install GeoTrellis on
Spark and avoid the issue? This prompted a discussion about
the nuances of workswith & platform technologies such as
Spark, Hadoop, Accumulo, and others. Andrew took an action to
dig in a bit to be able to understand better and advise.
Related, we talked about the similarities to these
technologies & Linux distributions. For example, Red Hat
Enterprise may pick a different line-up vs. Ubuntu vs. Mint
and under the covers there are different versions of 1800+
components. For Eclipse for instance, it doesn't go down to
that level of detail. So for the LocationTech big data
projects, what are our options to avoid death by CQ.
We talked about the sequence of projects in IP review.
Currently:
GeoMesa (8 waiting + 7 new), GeoGig (large number submitted),
GeoTrellis
Proposed:
GeoMesa, GeoGig, SFCurve, JTS, Spatial4J, GeoTrellis
The team liked the ideas of a) Keep pushing on GeoMesa b) Fast
Track SFCurve c) Move up JTS & Spatial4J since they are
low level dependencies for almost everything else. =>
Andrew will recommend this to the Steering Committee... should
find support.
Andrew
|
