On Wed, Nov 26, 2008 at 11:55 AM, Rob Atkinson <[EMAIL PROTECTED]>wrote:
> 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.
>
Thanks Rob.
>
> 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
>
Cool. Let's try to come up with perhaps a specific roadmap / pitch to put
on the GeoServer site, so we can point people at a plan, that they can help
accelerate with funding. I'll try to put some time in to this next week,
perhaps we can try to pass it around on a wiki site. I think Justin took a
first crack at it, turning the stuff Gabriel mentioned in to a document.
C
>
> 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
> >>> [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
>
-------------------------------------------------------------------------
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
