Hi Andrea; How to deal with distributed version control (so far I would like to treat them as branches?) is going to be something we need solved this year; indeed I mentioned that in my status report to OSGeo.
We actually have a smaller branch to try this out on in the form of adding OSGi manifest information. As indicated earlier I am mostly ignoring geotidy as a branch since I have no say in its direction or development. When there is a proposal I have a roll to play and will pay attention. Ideally I like the idea of figuring out tough problems on a branch where there is less risk of tripping over each other; however it makes the merge process more expensive for everyone involved. Jody PS. I agree with your points about being careful about branding (and really want to avoid a situtation like with complex features where a branch was run for years). I actually made the same point on the udig list last week; also about the OSGi manifest repo/branch. On Wed, Mar 25, 2009 at 10:20 PM, Andrea Aime <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ 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
