Hi Chris;
As you can see anything that will help with planning is encouraged. I have
found it very scary ground however. With uDig the moment an idea was
expressed publicly (even when it had no funding) we have had funding dry up
from other sources for the same idea (why pay for something if it is going
to get done anyways?).
As such I would encourage you to have a list of good ideas that is clearly
labeled as required funding. Or at least be very careful as you walk this
ground.
Jody
On Wed, Feb 18, 2009 at 11:18 AM, Chris Holmes <[email protected]> wrote:
>
>
> Raif S. Naffah wrote:
> > hello Chris,
> >
> > apologies for barging in on the developers list but i didn't want to
> > miss the opportunity for registering my enthusiastic approval for such
> > an effort. this for sure is a valuable tool for people like me who are
> > asked to help plan for future releases of a product that depends on
> > GeoServer.
> >
> You're definitely welcome to barge in, I just kept it on the devel list
> to keep the audience a bit smaller, and to make sure it was a good idea.
> It sounds like there's support for it, so I'll definitely follow up
> with an email to the users list and a blog post.
>
> > two additional things you might want to consider:
> >
> > a. add dates (tentative ones or year quarters are fine) for releases
> > beyond the next immediate one.
> >
> This one is tough. My organization at least won't commit to any dates
> until we have a client paying for it. Anything else can get bumped by
> another client. So in our last roadmap even some of the things I put in
> short term (3 months) didn't get done, even though I'm not updating the
> roadmap like nine months later.
>
> We could just put dates when developers know clients are demanding it.
> But often times that's not even an indication that it will be in a
> general geoserver release, as that takes more time, and few clients
> require it.
>
> What I'd ideally like to do is set up a mechanism where a group of
> clients could put in money to ensure that a group of developers finishes
> things by a certain date. But with the open source nature of things
> it's hard to get any guarantees, so I just dropped it.
>
> I think some of these may be able to have some dates on it though, I
> know the complex feature stuff is well supported and they have
> deadlines, so I'll see if I can get them to fill out some more details
> of their deliverables that they hope to meet.
>
>
> > b. give an idea about the end-of-life period/date of earlier versions.
> > this would help planning for conversion between different versions of
> > the GeoTools and other libraries for oragnizations that use the same
> > versions as those in GeoServer.
> >
> >
>
> You mean like on a separate page? And are you saying put the
> anticipated end of life? Or just the end of lifes of the last versions?
> And by end of life you just mean when there's not going to be any more
> releases on the branch?
>
> Some of this is a bit tough, as my organization was not planning a
> 1.6.5, but we had enough clients that were paying for bug fixes on 1.6.x
> that it made sense for us to put out the release for all. But in
> general we move fairly aggressively towards developing the next release,
> and only _guarantee_ bug fixes on stable branches for paying clients.
> And for our paying clients we'll fix anything that's a bug that affects
> them. Also note that other organizations may do patches and put out a
> stable release even if we're not planning on it.
>
> But yeah, point taken, and I'd like to at least make my organization's
> intentions more clear, so others can plan on what we're going to do,
> even as they understand those priorities may shift due to our clients,
> and make it easier to understand that they can influence our priorities
> with funding.
>
> best regards,
>
> Chris
>
> > On Tue, 17 Feb 2009 09:04:54 am Chris Holmes wrote:
> >> Hey all, so I used to maintain a page that was called 'roadmap', with
> >> short, medium and long term plans. With the new jira based roadmap
> >> it got relegated to 'Roadmap Ideas' (which it should have been, it
> >> was _hopelessly_ out of date).
> >>
> >> I just spent some time at least updating it, see
> >> http://geoserver.org/display/GEOS/Roadmap+Ideas
> >>
> >> My ideas is that there should be a more 'user friendly' way for
> >> people to see what may be coming next in GeoServer land.
> >>
> >> What I'm hoping to do is to have it linked up with the actual
> >> roadmap, and have the two reflect one another. Someone should be
> >> able to navigate from an individual feature the Roadmap Ideas page to
> >> an overall jira task for it, potentially to an RnD page, and then
> >> eventually to a number of individual tickets.
> >>
> >> Do people think this is a good idea?
> >>
> >> I just took a rough pass at things, if there is anything that I
> >> missed please go ahead and fill it in.
> >>
> >> Does anyone have better ideas of what to call this document? I think
> >> roadmap makes sense for the more granular one, but I'd like something
> >> to call this. 'Plans'?
> >>
> >> thanks,
> >>
> >> Chris
> >
> >
> > cheers;
> > rsn
>
> --
> Chris Holmes
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
