Martin Desruisseaux ha scritto: > This bring the question about when geotidy can be offered for a merge with > GeoTools. Currently the referencing module is done, except for Oracle and > HSQL > plugins of EPSG (I'm doing my test on PostgreSQL for now) and the builder > package, maybe to move in an other module.
GeoTidy has been source of many headaches so far, at least for me. I appreciate the need for cleaning up the code, and I'm _very_ interested in the list of improvements and fixes you've implemented there (I really mean it). On the other side, GeoTidy has been created on a separate repository, and managed by a single person, which makes it look a lot like an hostile fork. The list of changes (http://geotidy.geomatys.fr/build/tools/gt-migrate/changes.html) also says in some places GeoTidy is GeoTools 3, but there is no PSC agreement on it, it's a single handed decision. Also, to my knowledge no-one outside of Geomatys has right now the resources or the need to create a GeoTools 3 branch. I thought the plan was to make GeoTidy a replacement of the referencing modules that could be used by GeoTools trunk, yet the number of changes, removed and renamed classes seems to preclude a solution in which the GeoTidy changes are simply merged into the GeoTools SVN (that is, the place where the official GeoTools library is stored). An alternative path that seems promising would be to build GeoTidy a GeoTools compatible version that GeoTools trunk can depend onto, just like we depend on many other external libraries. This would also clarify once and for all that GeoTidy is its own library, separated from GeoTools, on which GeoTools depend just like it depends on JAI, Jakarta commons, Batik and many others. It would also fit very well with your intention to be the benevolent dictator of GeoTidy, preventing anyone else to directly commit on it. It also seems, and this is new to me, that GeoTidy contains also coverage handling classes. Mixed with your intention of being a benevolent dictator of your modules I find this very disturbing, as it would prevent Simone from contributing to it (after all you said at FOSS4G 2008 that you don't want anything to do with Simone, with various other PSC members present that can confirm what I've just wrote). This is very problematic, as from a GeoServer point of view: Simone work is what made the difference between unusable raster support to something that can rival with MapServer on standard imagery. Also, we have a very strong need for a more serious coverage I/O support that the "coverage store" proposal seems to match pretty effectively. I appreciate that you're open to work on that, but past experience show that does not mean we'll get anything usable in the year to come. After all, Jody's threading issues have been officially considered and merged into GeoTidy 1.5 years after he proposed them, no? I don't think we can wait that much, plus I don't want a situation in which you're the sole judge of what's good and wrong in a proposal, this is a community, and the PSC is the only valid judge on proposals. You've completely bypassed the PSC and the proposals mechanism for all the GeoTidy code changes, which makes me believe you're not interested in collaborating with GeoTools by its rules. In your own library instead you're free to do pretty much what you want, without asking other people and without compromising, but that's no more a community effort, that's no more GeoTools. So, whilst I see a viable future for a GeoTools dependency on GeoTidy as an external referencing library, I have reservations that the same could be made work for coverages. In order to bring GeoTidy back home it is my personal opinion that two things would be needed: - make all the API changes occurred in GeoTidy go through a standard GeoTools proposal process and merge back on svn - accept the fact that the proposal mechanism in GeoTools might overrule your judgement on coverage handling. In particular, when the coverage store api reaches the proposal stage, it may well happen that you have the only -1 on the proposal. In that case after two subsequent votes the proposed changes would go in even if you're the maintainer of the module As I said, this is only my point of view, a PSC vote is needed to deal with this matter, but first we have to sort out a list of possible action plans, discuss, and vote on the best one. Btw, a shared and distributed community is one of the requirements for OSGEO incubation, DeeGree is having troubles incubating because there is a single company behind the project. They only lately went past that issue: http://wiki.osgeo.org/wiki/Deegree_Incubation_Status See the list of OSGEO principles: http://www.osgeo.org/incubator/process/principles.html A benevolent dictator model is nor open nor collaborative. See for example GDAL, where Frank W. had to give up the benevolent dictator model for a PSC made of people coming from different organizations. One last hard question. You're a PSC memember, yet the whole GeoTidy thing seems to either suggest you're either not recognizing the PSC anymore (given you've bypassed the proposal mechanism whilst still using the org.geotools package names) or that you already decided that GeoTidy is a separate library. Which one is it? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
