[Geoserver-devel] Some wfs related backports on gt2 2.5.x

Andrea_Aime3 · December 4, 2008, 2:40pm

Hi all,
this morning I've spotted a few changes in 2.5.x
that might affect the 1.7.1 release, as they touch
code that is probably used by the WFS module of
GeoServer.

These are Gabriel backports of fixes that occurred
on trunk. I am a bit nervous about them since
we're days away from the release and I'd personally
prefer to have the branches treated as frozen,
as in "only critical bug fixes coming in".

My suggestion:
- Justin, I guess you may want to call a freeze and
   ask people to refrain from committing stuff to
   2.5.x and 1.7.x that's not related to the GeoServer
   1.7.1 release? (anything other than critical bug fixes,
    that is)
- Gabriel, the changes that might affect the WFS module
   seem to be at r31848, 31949, related to
   "GEOT-2191 backport fixes on ows and wfs emf models"
   I'd suggest to have them reviewed or revert them
   for the time being?

If you have already done a peer review and the changes
are considered ok please accept my apologies, I'm just
trying to make sure the 1.7.1 release is going to be solid.

Cheers
Andrea

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

Gabriel_Roldan2 · December 4, 2008, 2:45pm

Hi Andrea,

your concerns are alright, no need to apologize. Explanation bellow.

On Thursday 04 December 2008 12:40:10 Andrea Aime wrote:

Hi all,
this morning I've spotted a few changes in 2.5.x
that might affect the 1.7.1 release, as they touch
code that is probably used by the WFS module of
GeoServer.

The idea is for them to affect the release _positively_, as this allows
RemoteOWSTestSupport to be enabled again. I saw you closed GEOS-1547 as it
targets 2.0 but I wonder if it should point to 1.7.x too since its our stable
branch.
That said, I realize the changeset is quite extensive but honestly I feel
better with it applied than not. Rationale being that it includes all the
improvements developed for the fgdc cap grant. Since the work originally
started on trunk before branching 2.5, when that happened development
continued on 2.6.x and the wfs module on 2.5 was left in a state of flux. For
that reason I cannot have any confidence on it as it was, and also would not be
able to properly support it but aligning with the stuff on trunk of which I'm
confident about seems good to me maintainance wise.

All in all, if it still sounds too risky I would be ok on reverting. I just
think since there were no code freeze and 2.5 had an obsolete wfs it was good
to have it aligned with the one we know works.

Does that make sense? I'm looking forward for your opinions guys, if you feel
better reverting lets do it.
Cheers,

Gabriel

These are Gabriel backports of fixes that occurred
on trunk. I am a bit nervous about them since
we're days away from the release and I'd personally
prefer to have the branches treated as frozen,
as in "only critical bug fixes coming in".

My suggestion:
- Justin, I guess you may want to call a freeze and
   ask people to refrain from committing stuff to
   2.5.x and 1.7.x that's not related to the GeoServer
   1.7.1 release? (anything other than critical bug fixes,
    that is)
- Gabriel, the changes that might affect the WFS module
   seem to be at r31848, 31949, related to
   "GEOT-2191 backport fixes on ows and wfs emf models"
   I'd suggest to have them reviewed or revert them
   for the time being?

If you have already done a peer review and the changes
are considered ok please accept my apologies, I'm just
trying to make sure the 1.7.1 release is going to be solid.

Cheers
Andrea

Justin_Deoliveira · December 4, 2008, 2:57pm

Andrea Aime wrote:

<snip>

My suggestion:
- Justin, I guess you may want to call a freeze and
   ask people to refrain from committing stuff to
   2.5.x and 1.7.x that's not related to the GeoServer
   1.7.1 release? (anything other than critical bug fixes,
    that is)

Well I have reservations. We are still in qa and bug fix mode. Last time I tried to call a freeze in this way people weren't too happy for having to freeze for so long. And since I can't guarantee that no more issues will come up I can't guarantee that we will be ready to create the release tag soon.

But yes, I can ask for a freeze. Perhaps for geotools we are ready to create the release tag for 2.5.2 and work from there. Although I have not yet even discussed the 2.5.2 release on the geotools lists. So how about we proceed as follows:

1. ask for a freeze on geoserver until Monday... I think we will probably be able to create the release tag by then (fingers crossed)
2. ask for permission to release gt 2.5.2 and create the release tag, updating the 1.7.x branch to work against it

Thoughts?

- Gabriel, the changes that might affect the WFS module
   seem to be at r31848, 31949, related to
   "GEOT-2191 backport fixes on ows and wfs emf models"
   I'd suggest to have them reviewed or revert them
   for the time being?

If you have already done a peer review and the changes
are considered ok please accept my apologies, I'm just
trying to make sure the 1.7.1 release is going to be solid.

Cheers
Andrea

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

Andrea_Aime3 · December 4, 2008, 3:07pm

Justin Deoliveira ha scritto:

Andrea Aime wrote:

<snip>

My suggestion:
- Justin, I guess you may want to call a freeze and
   ask people to refrain from committing stuff to
   2.5.x and 1.7.x that's not related to the GeoServer
   1.7.1 release? (anything other than critical bug fixes,
    that is)

Well I have reservations. We are still in qa and bug fix mode. Last time I tried to call a freeze in this way people weren't too happy for having to freeze for so long. And since I can't guarantee that no more issues will come up I can't guarantee that we will be ready to create the release tag soon.

But yes, I can ask for a freeze. Perhaps for geotools we are ready to create the release tag for 2.5.2 and work from there. Although I have not yet even discussed the 2.5.2 release on the geotools lists. So how about we proceed as follows:

1. ask for a freeze on geoserver until Monday... I think we will probably be able to create the release tag by then (fingers crossed)
2. ask for permission to release gt 2.5.2 and create the release tag, updating the 1.7.x branch to work against it

Yep, pretty much aware of the issues with long freezes. Then again,
if you don't call "something" people will keep on merrily committing
changes to the branches we're using for the release no?

Cheers
Andrea

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

Justin_Deoliveira · December 4, 2008, 3:09pm

<snip>

Yep, pretty much aware of the issues with long freezes. Then again,
if you don't call "something" people will keep on merrily committing
changes to the branches we're using for the release no?

So its a darned if you do, darned if you don't situation... not very nice for the guy doing the release trying to walk the line.

Cheers
Andrea

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

Andrea_Aime3 · December 4, 2008, 3:14pm

Justin Deoliveira ha scritto:

<snip>

Yep, pretty much aware of the issues with long freezes. Then again,
if you don't call "something" people will keep on merrily committing
changes to the branches we're using for the release no?

So its a darned if you do, darned if you don't situation... not very nice for the guy doing the release trying to walk the line.

Indeed you're right, not an easy position, I've been there before
keeping a freeze two weeks long with people complaining at me
(I had my reasons, they had theirs, and we were both right, so
it was indeed a lose/lose situation).

The only escape route I know of if you plan to keep a freeze lasting
longer than a week is to branch off... which as its own issues as you
know, one more place to port changes to

A solution? Maybe... talk. Ask people to start a freeze, if the
freeze takes more than expected or people are getting uncomfortable
with it, just branch off to insulate the freeze from other people
work. Hopefully most of the time the freeze won't affect people enough
to require a real branch, and when it does, well, you know that
you have at least tried.

Cheers
Andrea

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

Gabriel_Roldan2 · December 4, 2008, 3:17pm

On Thursday 04 December 2008 13:09:20 Justin Deoliveira wrote:

<snip>

> Yep, pretty much aware of the issues with long freezes. Then again,
> if you don't call "something" people will keep on merrily committing
> changes to the branches we're using for the release no?

So its a darned if you do, darned if you don't situation... not very
nice for the guy doing the release trying to walk the line.

and back to this specific commit, do you think its a good thing to re enable
remote ows test on the stable 1.7 branch or we should let that functionality
wild?
Andrea's original concern was about the quality of such an extensive commit on
the wfs module, but the discussion diverged. So we can either: assume its good
enough since its what proved to work ok on trunk instead of the unmaintained,
obsolete bits that were on 2.5.x. On trunk this already passed Justin's
functionality QA, not sure if he did some QA code wise though. Or revert and
may be let the issue of enabling the remote ows tests for the next release.
Opinions?

Cheers,
Gabriel

> Cheers
> Andrea

Justin_Deoliveira · December 4, 2008, 3:50pm

<snip>

Indeed you're right, not an easy position, I've been there before
keeping a freeze two weeks long with people complaining at me
(I had my reasons, they had theirs, and we were both right, so
it was indeed a lose/lose situation).

The only escape route I know of if you plan to keep a freeze lasting
longer than a week is to branch off... which as its own issues as you
know, one more place to port changes to

A solution? Maybe... talk. Ask people to start a freeze, if the
freeze takes more than expected or people are getting uncomfortable
with it, just branch off to insulate the freeze from other people
work. Hopefully most of the time the freeze won't affect people enough
to require a real branch, and when it does, well, you know that
you have at least tried.

Well I think once the road map is in place it should help since this situation should not really occur. For one release dates are set to people know when a release is coming. It would probably be good to also add to the process something like no non-bug fix commits at least a week before release date.

But it also will prevent any commits that the community has decided should not get into the release.

But yeah, until this is in place we will just have to continue to ask for a freeze and deal with situation in which people need to commit.

Cheers
Andrea

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

Justin_Deoliveira · December 4, 2008, 3:54pm

<snip>

and back to this specific commit, do you think its a good thing to re enable remote ows test on the stable 1.7 branch or we should let that functionality wild?
Andrea's original concern was about the quality of such an extensive commit on the wfs module, but the discussion diverged. So we can either: assume its good enough since its what proved to work ok on trunk instead of the unmaintained, obsolete bits that were on 2.5.x. On trunk this already passed Justin's functionality QA, not sure if he did some QA code wise though. Or revert and may be let the issue of enabling the remote ows tests for the next release.
Opinions?

Yeah, Gabriels work definitely passes my review. But I still would be hesitant to add to 2.5.x at this point. However... it seems to me that most of the commits (to the wfs xml and emf modules) should not affect geoserver b/c geoserver does not use the wfs xml bindings in geotools?

Cheers,
Gabriel

Cheers
Andrea

-------------------------------------------------------------------------
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.

Andrea_Aime3 · December 4, 2008, 4:22pm

Justin Deoliveira ha scritto:

<snip>

and back to this specific commit, do you think its a good thing to re enable remote ows test on the stable 1.7 branch or we should let that functionality wild?
Andrea's original concern was about the quality of such an extensive commit on the wfs module, but the discussion diverged. So we can either: assume its good enough since its what proved to work ok on trunk instead of the unmaintained, obsolete bits that were on 2.5.x. On trunk this already passed Justin's functionality QA, not sure if he did some QA code wise though. Or revert and may be let the issue of enabling the remote ows tests for the next release.
Opinions?

Yeah, Gabriels work definitely passes my review. But I still would be hesitant to add to 2.5.x at this point. However... it seems to me that most of the commits (to the wfs xml and emf modules) should not affect geoserver b/c geoserver does not use the wfs xml bindings in geotools?

Oh, I thought they were used, that's why I asked. Sorry for bothering
for nothing then
Cheers
Andrea

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

Justin_Deoliveira · December 4, 2008, 5:59pm

Oh, I thought they were used, that's why I asked. Sorry for bothering
for nothing then

Hmmmm... apparently not, the current build is broken do the wfs model changes that were backported.

Cheers
Andrea

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