| [technology-pmc] Minutes from March 25, 2015 meeting |
|
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 |