GeoTools / GeoServer Meeting 2013-05-13
Participants
------------
Ben Caradoc-Davies
Andrea Aime
Jody Garnett (eh?)
Jukka Rahkonen
Alessio Fabiani
Agenda
------
- GeoTools contributor agreement process
- International politics and contributions
- GeoWebCache breakage and milestone for release
- GridCoverageReader proposals
- Kill Info Objects?
- Release this week
Updated GeoTools Code Contributor Agreement
CSIRO managed to sign in a fairly straightforward manner (yay!)
Need to be careful about contributing other people's patches (ie accepting patches).
Q: Process?
Print / Sign / Scan
Q: Quick Patch vs Contribution Agreement
Eclipse draws distinction between small change and one requiring a code contribution agreement. Quick rule of thumb: code contribution agreement required when the change involves the creation of a new file (or sample data).
ACTION: Ben to propose Quick Patch / Contribution guide for developers guide procedures
GeoWebCache breakage and milestone for release
- GWC API breaking
- ACTION: Ben to create GWC milestone 1.4-M20130509 on osgeo repo
- ACTION: Ben to update GeoServer 2.3.x and master to use this version
GridCoverageReader Proposals
Tasks section missing <-- so jody is not voting yet
So what is being done?
- Everything is ready to be committed (so poor community process)
- Documentation tasks not covered (so need community help here)
Actions:
- AA: Update the tasks section (deadlines, community resourcing needed)
- JG: Jody will volunteer for code example showing new API (steal from test case)
Q: File harvest is not symmetric (harvest cannot be done on other readers)
A: ImageMosaic limited to harvest files.
A few other ideas discussed, mostly to explore the idea of harvesting between PostGIS Raster implementations etc...
Q: A vote of noconfidence in DataAccess?
A: Not usable for raster data, would of doubled the effort.
Notes:
- GridAccess / GridSource API (from spike) considered.
- Last modification to grid coverage readers before transition
Q: Use of Info objects for Granule?
This is one of the reasons why FeatureSource was not implemented, Granule is at the level of SimpleFeature (not an independent "resource" with its own MetaData).
Kill Info Objects
Discussion from above.
Q: Should we consider killing the GeoTools Info objects?
Perhaps: uDig could make use of WFS and WMS GetCapabilities directly.
A: JG: Review Info implementations, and ask on email list
Release this week
Tues: GWC
Wed: GeoTools
Thurs: GeoServer
Q: Cite Test Failures?
They appear to be random ... so probably an environmental difficulity.
Notes:
- Announcement on Monday
Actions:
BC: Remind email list that there is a release this week
BC: Tag and Bag GWC
International politics and contributions
- Contributors affected by trade embargoes / international tensions are asked to keep their code in community modules.
- Core changes might be achieved by unaffected volunteers, but this is an unfunded effort.
- API changes require proposals as usual.
Actions:
- Workflow: GitHub for fork to identify changes, GSIP for each API change, community module for TJS
- Community workload may be high (similar to App Schema)
Q: Code contribution agreement
Waiting to hear back.
Q: Can formal review mitigate effort?
Cost prohibitive, requires independent security consultants etc...
Q: How to mitigate effort?
TDD in community module for API Core changes
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre