Apologies, my intentions were poorly phrased. "not an option" was too strong a statement. Really what the point of the email was is that I wanted an exception in project policy for a single release. But lesson learned, the community has spoken. Won't make the mistake again.
-Justin Rob Atkinson wrote: > When you say "its not an option" because of "those who pay the bills", > you sound like you are either declaring post-facto or proposing a move > to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided > itself as being a "Bazaar". > > If this is not the intention, then a better mechanism needs to be > found. IMHO nothing should be promised to clients as "will be core" > until it has been run past the community and accepted by a formal > vote. The ability to meet the needs of paying clients is a well > understood requirement, but we need all to be playing by the same > rules for anyone else to have a chance of bringing resources. > > Working up such a roadmap, with resourcing mapped to it, needs to be a > formal commitment by the community to support that roadmap by not > taking on mutually incompatible obligations - and this means not > suspending or dropping pieces of work being depended on by others > because of a new opportunity. We need to negotiate both inclusion and > changes to the roadmap. > > > Rob A > > On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <[EMAIL PROTECTED]> wrote: >> Justin Deoliveira ha scritto: >>> Hi all, >>> >>> Sorry I missed the IRC meeting today, was out of the office. I just read >>> through the logs and wanted to share my thoughts. >>> >>> It was no shock to me that people are surprised about the sudden move to >>> make rest and geosearch core modules. First off, i have to apologize b/c >>> this process has been poorly managed by me. These needed to be included >>> in 1.7.1 and I did not spend any time before hand working to get them to >>> a "releasable" state. >>> >>> The requirement to include these modules comes down from those who pay >>> the bills... so not getting them into this release is not really an option. >>> >>> So the best I could come up with is a compromise. To include them in >>> this release but start the process toward moving them to core modules, >>> test coverage, documentation, etc... And indeed making this a blocker >>> for the 1.7.2 release. >> Would making them into an extension for 1.7.1 and move them to core >> by 1.7.2 be an acceptable (maybe a little more in line with policy) >> path? >> >>> So I know we are diverging from project policy for this release but I >>> ask for leniency. >>> >>> Moving past his and ensuring that this sort of situation does not pop up >>> again. We *desperately* need a proper and detailed road map for the >>> project. Currently we sort of organize jira for a single release pushing >>> back all sorts of issues to the next release and doing it all over >>> again. While this works on a release by release basis its not all that >>> great for long term planning. Having a proper road map in place would >>> allow us to much better plan when requirements come in from people with >>> money who want features. >> Yep, very much agreed. >> >>> I am open to strategies on how to plan this road map. I know a lot of >>> different people want to see a lot of different things and have >>> different requirements. So I am not sure how to proceed in order to >>> build a balanced and fair road map. >> Well, all the people involved in GeoServer work some way or the other >> for consultancy companies and as you said we need to pay our bills >> as well. >> So I guess the roadmap should point towards directions, >> items, give a scope, and make sure it has enough sponsoring (but >> just throwing out ideas is ok, provided we don't pretend others >> to realize our dreams). But let it generic and relaxed enough to >> allow for the extra stuff that plops into our consultancy >> bucked and that really allows the people working on GeoServer to >> live. >> >> Hard balance to strike I know, but then again, we have only limited >> control of what eager users might decide to sponsor tomorrow (and >> when that happens it's a pity to let it go away). >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
