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
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://locationtech.org/mailman/listinfo/technology-pmc
|