Well me Rob, I am just going to get back to you with respect to "scope".. > > 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. > You will find a range of topics have been addressed that include the work of larger teams; the original user interface (and rewrite of the data access layer) was done with a team of 4 over the course of a year for example. The current migration to a new user interface will involve many developers (around June as I understand it), in terms of planning we just need to know what peoples delivery dates are and make sure the code base is stable when needed. I am carefully keeping the WPS project away from any kind of configuration / user interface concerns until after the work in June is complete for example. > > 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. > Understood; you are well represented by Rob Atkinson who is a member of our project steering committee. In general we ask that organizations that are involved heavily in GeoServer development and direction cough of someone to sit on our committee and take responsibility for the actions that are being taken :-) > > 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. > We are suffering from two things at the moment: - a very active development road map for the summer; it is hard for us to see past the current workload (that is what we have a steering committee to do after all) - a very difficult problem with a poor record of communication; the "community schema" idea sounds simple on paper - but is far removed from the day-2-day experience of us here on the developer list. You are "blessed" with existing well defined application schemas that are both exacting and presumably helpful. This is so far away from what most of us get to see it is hard for us to understand it is a serious problem.
The larger problem appears to be behind us: - we lacked a representation of Feature that was capable of addressing your concerns I would like to confirm: - is the "simple" flavour of Geometry supported by GeoTools right now (ie from SFSQL) is this sufficient for your needs? > > I have interested users and by Australian standards a lot of > development effort. I need to understand how AuScope & SISS can work > with the open source community – specifically Geoserver and Geotools. > Both projects have taken steps in the last couple of years to answer your question: - they feature a formal process that can be used to offer a direction to the community; with strict time limits for the community to respond (so your project is not hung while waiting for feedback), the usual open source controls are in place so -1 vote has a consequence in terms of helping you set up an alternative etc... - they have form of community or unsupported space for experiments that are aligned with trunk to take place (so we don't end up with a situation like now where you are pouring money into a branch that will not see the light of day) Well met, Jody ------------------------------------------------------------------------- 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
