[Geoserver-devel] #roadmap update, July 28, 09

Hi all,

Release release release. We have a release going 1.7.6 this week and an up coming release scheduled for next.

* 1.7.6 release

I believe it is in progress being worked on by Mark. How is that going Mark?

* 2.0-RC1 release date

Scheduled for August 3 which makes it next week. How does everyone feel about that date? To soon? Do we need to push back?

* 2.0-RC1 priority fixes

The only high priority left open is:

http://jira.codehaus.org/browse/GEOS-2887, jdeolive
Port all extensions to trunk

The extensions that still need to be ported:

* sqlserver
* feature-pregen
* imagemosaic-jdbc

Any other issues that need to be high priority?

-Justin

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin Deoliveira ha scritto:

Hi all,

Release release release. We have a release going 1.7.6 this week and an up coming release scheduled for next.

* 1.7.6 release

I believe it is in progress being worked on by Mark. How is that going Mark?

I'd like to point out quite a few annoying bugs have been squashed
recently and people kept asking if they were going to be included
in 1.7.6. I replied that 1.7.6 was already tagged, yet it's sort of a
pity not to have the fixes in, a few are annoying and close to one liners:
http://jira.codehaus.org/browse/GEOS-3287
http://jira.codehaus.org/browse/GEOS-3292
http://jira.codehaus.org/browse/GEOS-3304
I think Gabriel had an important raster symbolizer fix as well.

Usually I'd say ok, next month but... will there be a 1.7.7?

* 2.0-RC1 release date

Scheduled for August 3 which makes it next week. How does everyone feel about that date? To soon? Do we need to push back?

Hummm... feels a little early to me, it all depends on how much
effort we can put into it.

* 2.0-RC1 priority fixes

The only high priority left open is:

http://jira.codehaus.org/browse/GEOS-2887, jdeolive
Port all extensions to trunk

The extensions that still need to be ported:

* sqlserver
* feature-pregen
* imagemosaic-jdbc

Any other issues that need to be high priority?

This ones should be fixed too imho:
http://jira.codehaus.org/browse/GEOS-3302
(regression)

http://jira.codehaus.org/browse/GEOS-3295
(regression)

http://jira.codehaus.org/browse/GEOS-3294
(non trivial change, better done earlier)

http://jira.codehaus.org/browse/GEOS-3259
(current status is a work in progress, new
  page unfinished, edit page not modified)

http://jira.codehaus.org/browse/GEOS-3170
(small, but still a regression)

http://jira.codehaus.org/browse/GEOS-3110
http://jira.codehaus.org/browse/GEOS-3188
(one of the two, please let's get RC1 out without
  the white hole in the home page :slight_smile:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi all,

Release release release. We have a release going 1.7.6 this week and an up coming release scheduled for next.

* 1.7.6 release

I believe it is in progress being worked on by Mark. How is that going Mark?

I'd like to point out quite a few annoying bugs have been squashed
recently and people kept asking if they were going to be included
in 1.7.6. I replied that 1.7.6 was already tagged, yet it's sort of a
pity not to have the fixes in, a few are annoying and close to one liners:
http://jira.codehaus.org/browse/GEOS-3287
http://jira.codehaus.org/browse/GEOS-3292
http://jira.codehaus.org/browse/GEOS-3304
I think Gabriel had an important raster symbolizer fix as well.

Usually I'd say ok, next month but... will there be a 1.7.7?

Now that we have some more resources for performing releases I don't see why not. Keeping with the per month release cycle still does seem a bit much at this point but I am definitely not against it. Also at this point in a stable branch the nightly builds are pretty safe to use.

* 2.0-RC1 release date

Scheduled for August 3 which makes it next week. How does everyone feel about that date? To soon? Do we need to push back?

Hummm... feels a little early to me, it all depends on how much
effort we can put into it.

* 2.0-RC1 priority fixes

The only high priority left open is:

http://jira.codehaus.org/browse/GEOS-2887, jdeolive
Port all extensions to trunk

The extensions that still need to be ported:

* sqlserver
* feature-pregen
* imagemosaic-jdbc

Any other issues that need to be high priority?

This ones should be fixed too imho:
http://jira.codehaus.org/browse/GEOS-3302
(regression)

http://jira.codehaus.org/browse/GEOS-3295
(regression)

http://jira.codehaus.org/browse/GEOS-3294
(non trivial change, better done earlier)

http://jira.codehaus.org/browse/GEOS-3259
(current status is a work in progress, new
  page unfinished, edit page not modified)

http://jira.codehaus.org/browse/GEOS-3170
(small, but still a regression)

http://jira.codehaus.org/browse/GEOS-3110
http://jira.codehaus.org/browse/GEOS-3188
(one of the two, please let's get RC1 out without
  the white hole in the home page :slight_smile:

Ok, this list as is represents quite a bit of work so it would mean pushing back the release substantially. At this point I would prefer we keep things to regressions only (and maybe low hanging fruit) or I fear we will go down a feature creep path of improvements that might not end.

We should also try to set more realistic dates for the RC1 to 2.0 release cycle as well, rather than bomb with a bunch of issues shortly before a release is due and push back the date. The reason being not because I am against pushing back, more that it is misleading to users who are watching the road map dates planning for 2.0.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi all,

Release release release. We have a release going 1.7.6 this week and an up coming release scheduled for next.

* 1.7.6 release

I believe it is in progress being worked on by Mark. How is that going Mark?

I'd like to point out quite a few annoying bugs have been squashed
recently and people kept asking if they were going to be included
in 1.7.6. I replied that 1.7.6 was already tagged, yet it's sort of a
pity not to have the fixes in, a few are annoying and close to one liners:
http://jira.codehaus.org/browse/GEOS-3287
http://jira.codehaus.org/browse/GEOS-3292
http://jira.codehaus.org/browse/GEOS-3304
I think Gabriel had an important raster symbolizer fix as well.

Usually I'd say ok, next month but... will there be a 1.7.7?

Now that we have some more resources for performing releases I don't see why not. Keeping with the per month release cycle still does seem a bit much at this point but I am definitely not against it. Also at this point in a stable branch the nightly builds are pretty safe to use.

* 2.0-RC1 release date

Scheduled for August 3 which makes it next week. How does everyone feel about that date? To soon? Do we need to push back?

Hummm... feels a little early to me, it all depends on how much
effort we can put into it.

* 2.0-RC1 priority fixes

The only high priority left open is:

http://jira.codehaus.org/browse/GEOS-2887, jdeolive
Port all extensions to trunk

The extensions that still need to be ported:

* sqlserver
* feature-pregen
* imagemosaic-jdbc

Any other issues that need to be high priority?

This ones should be fixed too imho:
http://jira.codehaus.org/browse/GEOS-3302
(regression)

http://jira.codehaus.org/browse/GEOS-3295
(regression)

http://jira.codehaus.org/browse/GEOS-3294
(non trivial change, better done earlier)

http://jira.codehaus.org/browse/GEOS-3259
(current status is a work in progress, new
  page unfinished, edit page not modified)

http://jira.codehaus.org/browse/GEOS-3170
(small, but still a regression)

http://jira.codehaus.org/browse/GEOS-3110
http://jira.codehaus.org/browse/GEOS-3188
(one of the two, please let's get RC1 out without
  the white hole in the home page :slight_smile:

Ok, this list as is represents quite a bit of work so it would mean pushing back the release substantially.

Not necessarily. I'm finding out that working on benchmarking alone
is not a very productive use of my time, I usually need to mull
over perf issues a bit before getting a solution. In the meantime
I can squash some jira :slight_smile:

At this point I would prefer we keep things to regressions only (and maybe low hanging fruit) or I fear we will go down a feature creep path of improvements that might not end.

I guess I can fix most of those by mid of next week, maybe earlier.
Is that going to be ok?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Ok, this list as is represents quite a bit of work so it would mean pushing back the release substantially.

Not necessarily. I'm finding out that working on benchmarking alone
is not a very productive use of my time, I usually need to mull
over perf issues a bit before getting a solution. In the meantime
I can squash some jira :slight_smile:

I more meant the stuff that are not bug fixes. Like:

http://jira.codehaus.org/browse/GEOS-3294

Is not trivial. So my point was more to try to limit to bugs and regressions as much as possible or else the road to 2.0 will get drawn out and delayed imo.

And no offense but I don't think we should hinge release dates on a single developers time available to churn through a bunch of tasks.
Don't get me wrong, it is great that you have time to put toward these issues but I feel like the point of this process is to gather consensus for release dates that work for everybody. And to try and do so somewhat in advance.

That said, if people think such a process is not working, or is not agile enough for us I will be the first one to advocate for a better process.

Another thing is that if everyone agrees we should try to file all regressions as high priority or blocker, as issues coming up shortly before the release that are blockers but not filed as so keep coming up. And it turns out to be a surprise for those who did not file or were not assigned the issue.

At this point I would prefer we keep things to regressions only (and maybe low hanging fruit) or I fear we will go down a feature creep path of improvements that might not end.

I guess I can fix most of those by mid of next week, maybe earlier.
Is that going to be ok?

Sure, I would be fine with pushing back by a week. How do others feel?

I will also point out there are other developers available to take on some of the issues as well (such as myself), so unless you really want to take them all on we can split up the work.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin Deoliveira ha scritto:

Ok, this list as is represents quite a bit of work so it would mean pushing back the release substantially.

Not necessarily. I'm finding out that working on benchmarking alone
is not a very productive use of my time, I usually need to mull
over perf issues a bit before getting a solution. In the meantime
I can squash some jira :slight_smile:

I more meant the stuff that are not bug fixes. Like:

http://jira.codehaus.org/browse/GEOS-3294

Is not trivial. So my point was more to try to limit to bugs and regressions as much as possible or else the road to 2.0 will get drawn out and delayed imo.

Got it. So that will be fixed by 2.0.1? 2.1? I ask because it's not a trivial change, once we enter RC stage it will be more risky to fix.

And no offense but I don't think we should hinge release dates on a single developers time available to churn through a bunch of tasks.
Don't get me wrong, it is great that you have time to put toward these issues but I feel like the point of this process is to gather consensus for release dates that work for everybody. And to try and do so somewhat in advance.

Duh, I did not mean I would fix all of them, sorry, put down
the sentence in the wrong way. I was thinking about these only:
http://jira.codehaus.org/browse/GEOS-3302 (regression)
http://jira.codehaus.org/browse/GEOS-3295 (regression)
http://jira.codehaus.org/browse/GEOS-3259 (in progress)

The others are assigned to someone else.
RC should also mean "feature complete" so I'm not sure we can go there
without fixing the status of the home page (the "white hole" issue).

Another thing is that if everyone agrees we should try to file all regressions as high priority or blocker, as issues coming up shortly before the release that are blockers but not filed as so keep coming up. And it turns out to be a surprise for those who did not file or were not assigned the issue.

Yup, sorry about that, I upgraded the priority of each regression to
critical status.

At this point I would prefer we keep things to regressions only (and maybe low hanging fruit) or I fear we will go down a feature creep path of improvements that might not end.

I guess I can fix most of those by mid of next week, maybe earlier.
Is that going to be ok?

Sure, I would be fine with pushing back by a week. How do others feel?

I will also point out there are other developers available to take on some of the issues as well (such as myself), so unless you really want to take them all on we can split up the work.

No no, as I said above I did not express myself properly, I wanted
to take only on the ones assigned to me.
And then there is the issue of the home page, which is expressed
in two differen jiras and should require a bit of work for sure...

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, this list as is represents quite a bit of work so it would mean pushing back the release substantially.

Not necessarily. I'm finding out that working on benchmarking alone
is not a very productive use of my time, I usually need to mull
over perf issues a bit before getting a solution. In the meantime
I can squash some jira :slight_smile:

I more meant the stuff that are not bug fixes. Like:

http://jira.codehaus.org/browse/GEOS-3294

Is not trivial. So my point was more to try to limit to bugs and regressions as much as possible or else the road to 2.0 will get drawn out and delayed imo.

Got it. So that will be fixed by 2.0.1? 2.1? I ask because it's not a trivial change, once we enter RC stage it will be more risky to fix.

Well, are there any open bugs that were are sure depend on this? The only issue I know of is not being able to change the table structure underneath a feature type. Any others?

And no offense but I don't think we should hinge release dates on a single developers time available to churn through a bunch of tasks.
Don't get me wrong, it is great that you have time to put toward these issues but I feel like the point of this process is to gather consensus for release dates that work for everybody. And to try and do so somewhat in advance.

Duh, I did not mean I would fix all of them, sorry, put down
the sentence in the wrong way. I was thinking about these only:
http://jira.codehaus.org/browse/GEOS-3302 (regression)
http://jira.codehaus.org/browse/GEOS-3295 (regression)
http://jira.codehaus.org/browse/GEOS-3259 (in progress)

The others are assigned to someone else.
RC should also mean "feature complete" so I'm not sure we can go there
without fixing the status of the home page (the "white hole" issue).

Another thing is that if everyone agrees we should try to file all regressions as high priority or blocker, as issues coming up shortly before the release that are blockers but not filed as so keep coming up. And it turns out to be a surprise for those who did not file or were not assigned the issue.

Yup, sorry about that, I upgraded the priority of each regression to
critical status.

Cool.

At this point I would prefer we keep things to regressions only (and maybe low hanging fruit) or I fear we will go down a feature creep path of improvements that might not end.

I guess I can fix most of those by mid of next week, maybe earlier.
Is that going to be ok?

Sure, I would be fine with pushing back by a week. How do others feel?

I will also point out there are other developers available to take on some of the issues as well (such as myself), so unless you really want to take them all on we can split up the work.

No no, as I said above I did not express myself properly, I wanted
to take only on the ones assigned to me.
And then there is the issue of the home page, which is expressed
in two differen jiras and should require a bit of work for sure...

Sorry, my apologies. I think i took your statement too literally :slight_smile:

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin Deoliveira ha scritto:

Got it. So that will be fixed by 2.0.1? 2.1? I ask because it's not a trivial change, once we enter RC stage it will be more risky to fix.

Well, are there any open bugs that were are sure depend on this? The only issue I know of is not being able to change the table structure underneath a feature type. Any others?

None that I know of. Yet for this use case it is a regression :slight_smile:
The use case by itself is not common for people publishing existing
data, might hit commonly people trying to setup an empty table
for WFS-T editing thought (since you probably iterate a few times
before getting the table structure right).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Got it. So that will be fixed by 2.0.1? 2.1? I ask because it's not a trivial change, once we enter RC stage it will be more risky to fix.

Well, are there any open bugs that were are sure depend on this? The only issue I know of is not being able to change the table structure underneath a feature type. Any others?

None that I know of. Yet for this use case it is a regression :slight_smile:
The use case by itself is not common for people publishing existing
data, might hit commonly people trying to setup an empty table
for WFS-T editing thought (since you probably iterate a few times
before getting the table structure right).

Since this 'might' hit people trying to do something that I imagine may be fairly rare (as it's not something we've commonly done), I'd say we should wait for a bug report on it. At some point I'd love to have a nice REST API to set up a new table, and even to change the table structure, so people could make a new empty WFS-T table through GeoExt.

If a user actually reports it then it should shoot to high priority. If we fix regressions on everything that could potentially be a problem we'll be in beta/rc land for a long time.

Cheers
Andrea

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin Deoliveira wrote:

Hi all,

Release release release. We have a release going 1.7.6 this week and an up coming release scheduled for next.

* 1.7.6 release

I believe it is in progress being worked on by Mark. How is that going Mark?

Between other work that is eating my time and evil cite tests, my progress is far too slow. I'm going to send some cite issues to the list in a few minutes, to avoid polluting this thread, but the two word summary just now is "Aahahhh *%#&".

Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com