Martin Desruisseaux ha scritto: > This is your vision, but I disagree that it is the way OpenSource > work. Linux and Gnumeric for instance don't work that way. They do > have module maintainers who have the final word on what goes in. > Those projects don't let anyone commit any code. Commiters must proof > that they really master the module, and for some projects like BSD it > takes years of contributions in the form of patches.
There are also successful projects where the model is even more drastic than ours, as there is no module maintainer, worse, there is not even an author on each source code file. I'm not talking about some strange niche project, I'm talking about Subversion itself, and I have to say, I like this model very much: http://subversion.tigris.org/ http://video.google.com/videoplay?docid=-4216011961522818645 Plus, all OSGEO projects have a PSC that can overrule eventual decisions of a module maintainer, provided they have a concept of module maintainer at all (most don't). And much of the OSGeo precedents were derived from Apache, which has similar governance rules. Even in the projects that requires most of the review, like OpenLayers, where each patch gets reviewed by two other people before being committed to trunk, there is no single person that can just decide to block the code contributions, it takes two reviews, from any PSC member, not from specific ones. > I remember someone whose very first contribution in the referencing > module was to break the Object.equals(Object) contract in > GeneralEnvelope, because he was not aware of the relationship between > equals and hashCode. I had to revert his commit and write an email > about this aspect of Java. Then he made changes based on an erroneous > understanding of what WeakReference are for - I had to revert again. > Then he replaced some calculations on AffineTransform by > calculations on Envelope without asking me, because Envelope are > easier to understand. He did not realize that Envelopes are ambiguous > (they said nothing about axis order, axis reversal, rotations...). > Breaking a module with changes based on wrong Java and mathematic > understanding commited without asking the maintainer is not my vision > of how OpenSource works. Even if Simone didn't quite get things right early on he then turned in to a very valuable contributor to the library. We all have areas that we might not know as well as others, and if we don't have the space to correct people and teach them better then we don't have much at all. The flip side is something like georeferenced images, which you for many years refused to accept as a valid GIS use case. Having mechanisms for the project to learn from the collective intelligence of all involved _is_ how Open Source works. There may be differences in the specifics of people's preference for governance models, how that collective intelligence gets tapped and used with out being a burden. And it sounds like there are different visions going on here. > I'm all for collaboration. But given the above, do you understand > that I really want to review every line of code commited in the > modules that I maintain? (at least until I find someone I trust > enough). It should not be such a big problem. You don't need my > agreement; do whatever you want on your own Mercurial clone. The > clone that I maintain will have every lines reviewed by myself or by > someone that I trust, but no one is forced to use that clone as his > primary source. If it can be done under a GeoTools umbrela, cool!! If > it can not, thats fine. We will leave GeoTools, thats all. Martin, from where I stand you left GeoTools when you decided to make your own fork and bypass all the GeoTools governance rules. Being part of GeoTools is about respecting its rules, we have a PSC, we have process to perform API changes, and GeoTidy did not respect either. Which is absolutely fine if you're making your own fork, not as much if you allow people to see it as part of a GeoTools "umbrella". An "umbrella" in which each subproject does what it wants sounds like an empty label, has no other practical meaning and does not seem to offer any advantage to either party over what we already do use "reuse" other projects jars, that is, go on the Internet, add a maven dependency, and use what is provided in the manner we see best fit. GeoTools has traditionally not been a benevolent dictator model, and joining OSGeo only reinforces that. If GeoTidy chooses a benevolent dictator model that's great - people working together should have the same preference in governance models. At some point, maybe when GeoTools upgrades to Java 6, or when there's a solid Java 5 jar from GeoTidy that doesn't break anything, then GeoTools will rely directly on GeoTidy. Cheers Andrea ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
