Cool guys, thanks for the clarification. I personally dont have a problem with making a informed, mutually agreed exception (but then I'm bypassing 1.7 tactically so dont really have a valid vote IMHO :-)
I'll do my best to help fill in some of the roadmap aspects we are committed to resourcing, probably as they become clearer. FYI INSPIRE is about to publically release draft schemas - life is going to hot up for Community schema support - I've fielded questions from half a dozen agencies in the meteorology domain this week, and they are not even in the first tranche of INSPIRE standards Rob On Thu, Nov 27, 2008 at 2:32 AM, Justin Deoliveira <[EMAIL PROTECTED]> wrote: > 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 >>> Geoserver-devel@lists.sourceforge.net >>> 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
