- a nice email from an OSGeo education committee member asking me to take part in some research on how open source projects collaborate
- a full email box we iron out the relationship between GeoTools and the ImageIO-Ext project
These two forces are in opposition; new functionality is the enemy of stability. Processes were introduced to help with stability; process cuts down research (due to adding overhead). So a compromise of the "unsupported" module was born - an area of svn where experimental (or unloved) work could exist without being deleted.
This has been a great compromise - it allows us to welcome in new developers and see what they are up to (without getting them to pass all the QA checks and code reviews). We figure once we have them involved we can buckle down on them later - when their code runs - and ask them to upgrade their module to "supported' status and thus have it included in the library for download. One of the nice things an "unsupported" module enables is the experimentation with "Fun New Stuff".
The ImageIO-Ext project reads like a text book example of "Fun new Stuff" - it combines GDAL goodness with Java Advanced Imaging goodness. And at least while it is under development it will be stepping on a few toes and taking a few short cuts while the idea is proven as real and good.
Since my mail box was full today - I expect the ImageIO-ext project is getting close.
Here is what I am going to try for going forward:
1. The 2.5.x release story with unsupported/supported modules needs to be clear.
a) I figure deploying unsupported modules to maven is okay for right now; it is a good move that allows new contributors to join geotools and contribute (which is the goal here)
b) The user list wanted unsupported modules as a separate download as well (I asked them after the last meeting). I don't want to do this:
- making unsupported modules available for download would take away a motivation for making a module supported.
- The GeoTools PMC should not be asked to take responsibility for code we have not reviewed (indeed by definition it does not meet the project standards).
c) We always get stuck on the unsupported modules that lack a module maintainer - these modules are *required* for one of two reasons:
- For modules that are required to complete a product story (Oracle Datastore I am looking at you). Frankly we are in a bind in these kind of things; as long as GeoServer keeps shipping with Oracle support Refractions can not make a good play to get a support contact (and make Oracle supported). We have customers interested in paying; but no threat is evident. Should we ask GeoServer to stop shipping Alphas with Oracle support?
- For new unsupported work that is required for the library to build or function (xml parser stuff I am looking at you) we need to see if these can be brought in as supported modules. If we must we should make a new category for this kind of work - I need to emphasis that this is important - the modules we are talking about here are set up to address long term goals of the library (goals that may not be reached with in a single contract, or within a single geotools release). I would even consider "accepting" these modules as supported - with a known deficit of say test coverage.
2. Review of dependencies
a) We have had several good discussions about dependencies - usually this focus on minimizing duplication (do we need 3 time support libraries?). Minimizing dependencies is a great direction to take and one it looks like everyone is motivated to follow
b) Todays discussion about what we expect from a dependency is a good one
- We expect open source? no. Or at least a dummy jar so we can build? usually. Or a profile so code written against a proprietary jar does not upset other developers? yes.
- in terms of distributing a dependency I want to focus on that only for supported modules
b) I expect unsupported modules to work with extra dependencies beyond what the rest of the library is using:
- Remember the goal here is to capture experiments that otherwise are lost to the public community - experimenting with a new dependency is a great use of the unsupported idea
- I need to respect the fact that unsupported modules are often work that needed to get done right now - as such I don't hold them to a high standard of review
- I would like to welcome outside contributors to contribute plugins and Adapters allowing GeoTools to work with additional libraries (Jump? Deegree? Sextante? gvsig?). Providing an area to work (and the ability to be versioned along with the GeoTools library) is a good enabler in this respect.
c) We need to be confident of dependencies we package up for download and distribution
- going through the website is a good start
- spots checks are a fine idea
- we should focus on the supported modules that are part of the library
d) Projects such as uDig and GeoServer that make use of unsupported modules (via maven dependencies) do so at their own risk - GeoTools makes no assurances
- hopefull by the time a module is ready for supported status the dependencies have been vetted; we should put this as a requirement for a supported module
In the specific case of imageio-ext I want to make sure the unsupported jars are not package up for download by innocent bystanders . For non-innocent bystanders like uDig we will help where needed before nominating the jar to be included in a GeoTools release (ie supported status). Currently imageio-ext is central to our story of supporting additional raster formats; with Eclipse RCP framework we have the chops to handle the platform dependence issue - I am not interested in being pure Java (I already have an SWT dependency).
GeoTools is moving out of the fast paced world of research and into the quiet solitude of maintenance. Careful attention to details as we make this transition is going to be very important - wish us luck! And we always accept volunteers.