[EMAIL PROTECTED] ha scritto: ... >>The SISS project will have the same kind of relationship with GeoServer, > ie as community members we > >>both need to play nice with others and follow the process as outlined. > > > > This is exactly what I’m wanting and clearly I need to become more > informed about the Geoserver community process. I’m concerned that these > mechanisms are intended for “smaller contributions” so to speak. All the > previous contributions to Geoserver I’ve heard of involve only a couple > of developers per feature. We could easily get to 8 or more. I’m not > certain the impact this effort would have on the rate of change and > administrative aspects of the Geoserver community. I also need to > understand how to have the Auscope+SISS development team work in its > “sandbox” whilst ensuring neither the Geoserver community nor the > Auscope+SISS developments hold each other up. The issue here isn’t so > much developers but stakeholder management.
We have only a place for "smaller contributions" for a reason of self preservation. If you look at the GSIP process, which is used for non trivial changes, you'll find out that no matter what, each of them required a relatively small amount of changes to be performed. The main reason behind that is that even with such smallish changes the likeliness of breaking GeoServer stability is not trivial, so each of them has been made in isolation, and with a small period of calm in between them so that things were allowed to settle down and go back to stability. The way to introduce big changes without breaking the GeoServer stability, on which users and at least 3 businesses around depend, is to slice change into manageable amount that get merged onto the GeoServer trunk one at a time, each one with a separate proposal and a review, in order to keep the code working, and every developer on the same page. Release wise this would work a lot better, since we're aiming at making geoserver releases more frequent and with less big changes per release, again, in an attempt to make GeoServer solid. This affects more the stable series, but also means we're trying to shorten the time between major ones, meaning that a "trunk" is going to be switched over to a stable branch probably every 6 months or so A team of 8 people working full time is scary in this respect, because it's going to produce big changes no matter what. Those 8 will sum up to the already existing 7-10 developers working on GeoServer, increasing a lot communication routes and generating serious develpment scalability issues. In order to avoid problems there, it is necessary to split the work so that the areas of friction are minimal. This is relatively easy with things like the WPS module RR is developing, because it is separated from the other serfices, but not that easy when we start talking about complex features, since that encompasses the whole GeoServer/GeoTools architecture. > As Ben mentioned, I’ve had some non-list conversations with others in > the Geoserver community to try and investigate these issues but > responses so far (they are ongoing) aren’t quite what I expected. Ben > already mentioned that some of the strings attached to the funding would > be a little strained if I contracted a commercial organisation that is > supporting the open source effort. I think the proposal for a commercial support was made in good faith. TOPP/OpenGeo is at the moment the major player in GeoServer development, and it's getting quite a bit of contracts lately, meaning we are having less and less time to dedicate to the pure open source community support, and that even on the spot commercial requests might have to be put in a queue. A contract with OpenGeo would guarantee we're there when you need to discuss further developments, or need a helping hand understanding some of the gt/gs code, or reviewing and testing your changes and so on, that is, it's just one way to make sure core developers are available. We care about GeoServer, and we'll be there even without a contract, it's just we cannot guarantee how prompt reactions will be, and how much time we'll be able to dedicate to it. The development you're proposing is very interesting, I'd hate not being able to attend to its evolution/integration in a timely fashion, that's all. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
