[Geoserver-devel] commits to gwc on stable branch

GeoServer GeoServer Developer
1

Hi Gabriel,

Looking at the commit log today I am seeing quite a lot of activity in the gwc module… which sort of worries me with RC3 just going out the door and trying to release 2.1.0 soon after. And also worrisome is the fact that there is no discussion about this development going on.

I also have to beg the larger question of if all this gwc development is suitable for the stable branch. This seems much more like trunk development to me. As was illustrated with the last minute fixes for gwc having to go into the RC3 release.

Anyways, I hate to be critical because the work you are doing is obviously great stuff… but it just seems like at this point it is introducing instability at a crucial point in the release stream and would be better suited to trunk.

Care to comment?

Thanks.

-Justin

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

2

ok, sorry about the lack of discussion.

It looks like I misunderstood the state of things wrt 2.1.x cause I
really thought with rc3 out we were ok to backport stable stuff.
Today's commit is part of a two commit that we need for tomorrow's
deadline so that GeoNode can depend on 2.1.x, which was not possible
until now, and address the following concerns (or will when it's
finished):
- ability to enabled/disable gwc. Something people needed to do by
removing the jars instead
- ability to turn on/off caching for individual layers
- ability to properly react to style changes

But it also comes with a fix for png encoding that slipped into RC3.

None of it should be critical and I could revert it if it weren't really
necessary for GeoNode tomorrow's deadline. That said I understand the
concern and reiterate I really thought it was ok as it doesn't affect
anything but gwc integration.
I hate having done so without having properly checked, sorry about that.
If that's really unacceptable I think my only way out would be branching
2.1.x and have GeoNode depending on that branch until it's ok to merge
to the actual 2.1.x branch, but that would have to be on svn caue I'm
not sure how hard it would be to make GeoNode depend on a github branch
instead.

So I would ask that if possible we accept this. Where to go from there
I'm open to suggestions. If we really want to get to a release after a
true RC for once I volunteer to take care of RC4, if we're up to wait
for yet another week until 2.1.0. Actually I'd really like that better.
But if not just let me know and I'll revert that patch and branch.

Sorry about the confusion.
Gabriel

On Tue, 2011-03-29 at 17:39 -0600, Justin Deoliveira wrote:

Hi Gabriel,

Looking at the commit log today I am seeing quite a lot of activity in
the gwc module... which sort of worries me with RC3 just going out the
door and trying to release 2.1.0 soon after. And also worrisome is the
fact that there is no discussion about this development going on.

I also have to beg the larger question of if all this gwc development
is suitable for the stable branch. This seems much more like
trunk development to me. As was illustrated with the last minute fixes
for gwc having to go into the RC3 release.

Anyways, I hate to be critical because the work you are doing is
obviously great stuff... but it just seems like at this point it is
introducing instability at a crucial point in the release stream and
would be better suited to trunk.

Care to comment?

Thanks.

-Justin

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

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

3

On Tue, Mar 29, 2011 at 7:28 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

ok, sorry about the lack of discussion.

It looks like I misunderstood the state of things wrt 2.1.x cause I
really thought with rc3 out we were ok to backport stable stuff.
Today’s commit is part of a two commit that we need for tomorrow’s
deadline so that GeoNode can depend on 2.1.x, which was not possible
until now, and address the following concerns (or will when it’s
finished):

  • ability to enabled/disable gwc. Something people needed to do by
    removing the jars instead
  • ability to turn on/off caching for individual layers
  • ability to properly react to style changes

But it also comes with a fix for png encoding that slipped into RC3.

I am sure the fixes are very worth while but that is not the point. These are not bug fixes, they are full blown features from the looks of it. Features that were added while in release candiate mode. Perhaps the project policy is not clear but we generally agreed that since 2.1-RC1 we could keep development on 2.1.x to bug fixes and “modest” features. Now I agree we are often too liberal with what a modest feature means… but it does seem excessive in this case. Perhaps I am wrong.

None of it should be critical and I could revert it if it weren’t really
necessary for GeoNode tomorrow’s deadline. That said I understand the
concern and reiterate I really thought it was ok as it doesn’t affect
anything but gwc integration.

Unfortunately deadlines of downstream projects are not really an acceptable reason for disregarding project policies. Other projects depend on geoserver as well but we have never used them as a reason for violating project policy. And to say that only gwc integration is affected is sort of naive. As Andrea points out in a separate thread changes that were isolated to the gwc module have lead to a regression (the inability to run two geoservers from a single data directory).

I hate having done so without having properly checked, sorry about that.
If that’s really unacceptable I think my only way out would be branching
2.1.x and have GeoNode depending on that branch until it’s ok to merge
to the actual 2.1.x branch, but that would have to be on svn caue I’m
not sure how hard it would be to make GeoNode depend on a github branch
instead.

I suggest that you do. This is exactly what I do for other projects that depend on gs 2.1.x but also require some changes are deemed unfit for the stable branch or must wait for the release of 2.1.0 in order to backport to 2.1.x.

So I would ask that if possible we accept this. Where to go from there
I’m open to suggestions. If we really want to get to a release after a
true RC for once I volunteer to take care of RC4, if we’re up to wait
for yet another week until 2.1.0. Actually I’d really like that better.
But if not just let me know and I’ll revert that patch and branch.

Like I said before I think all the development is great and I have no doubt that the stuff you are working on is making gwc better. But when does it stop? To release 2.1.0 after a raft of large changes can’t be done imo and I think others will agree. So we release RC4. But what happens then? Will we receive another batch of changes after RC4 and have to do an RC5? And there is the question of how to address the multiple data dir regression. We’ll see what the other devs think, and while I am ok with getting your changes in and pushing back release date, at some point (soon) we need to get serious about actually putting out a release candidate. And that means adhering to the project development policies that have been unofficially agreed upon. If they don’t work for you then yes please branch.

Sorry to be so harsh but what you have done because you had a deadline has pushed back other peoples deadlines (including myself) who are waiting for gs 2.1.0 to be released.

Sorry about the confusion.
Gabriel

On Tue, 2011-03-29 at 17:39 -0600, Justin Deoliveira wrote:

Hi Gabriel,

Looking at the commit log today I am seeing quite a lot of activity in
the gwc module… which sort of worries me with RC3 just going out the
door and trying to release 2.1.0 soon after. And also worrisome is the
fact that there is no discussion about this development going on.

I also have to beg the larger question of if all this gwc development
is suitable for the stable branch. This seems much more like
trunk development to me. As was illustrated with the last minute fixes
for gwc having to go into the RC3 release.

Anyways, I hate to be critical because the work you are doing is
obviously great stuff… but it just seems like at this point it is
introducing instability at a crucial point in the release stream and
would be better suited to trunk.

Care to comment?

Thanks.

-Justin

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

Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro ™ technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

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

4

I understand.
So I'll branch 2.1.x on svn and revert that commit out.
Sorry again for the hassle.

On Tue, 2011-03-29 at 20:47 -0600, Justin Deoliveira wrote:

On Tue, Mar 29, 2011 at 7:28 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
        ok, sorry about the lack of discussion.
        
        It looks like I misunderstood the state of things wrt 2.1.x
        cause I
        really thought with rc3 out we were ok to backport stable
        stuff.
        Today's commit is part of a two commit that we need for
        tomorrow's
        deadline so that GeoNode can depend on 2.1.x, which was not
        possible
        until now, and address the following concerns (or will when
        it's
        finished):
        - ability to enabled/disable gwc. Something people needed to
        do by
        removing the jars instead
        - ability to turn on/off caching for individual layers
        - ability to properly react to style changes
        
        But it also comes with a fix for png encoding that slipped
        into RC3.

I am sure the fixes are very worth while but that is not the point.
These are not bug fixes, they are full blown features from the looks
of it. Features that were added while in release candiate mode.
Perhaps the project policy is not clear but we generally agreed that
since 2.1-RC1 we could keep development on 2.1.x to bug fixes and
"modest" features. Now I agree we are often too liberal with what a
modest feature means... but it does seem excessive in this case.
Perhaps I am wrong.
        
        None of it should be critical and I could revert it if it
        weren't really
        necessary for GeoNode tomorrow's deadline. That said I
        understand the
        concern and reiterate I really thought it was ok as it doesn't
        affect
        anything but gwc integration.

Unfortunately deadlines of downstream projects are not really an
acceptable reason for disregarding project policies. Other projects
depend on geoserver as well but we have never used them as a reason
for violating project policy. And to say that only gwc integration is
affected is sort of naive. As Andrea points out in a separate thread
changes that were isolated to the gwc module have lead to a regression
(the inability to run two geoservers from a single data directory).
  
        I hate having done so without having properly checked, sorry
        about that.
        If that's really unacceptable I think my only way out would be
        branching
        2.1.x and have GeoNode depending on that branch until it's ok
        to merge
        to the actual 2.1.x branch, but that would have to be on svn
        caue I'm
        not sure how hard it would be to make GeoNode depend on a
        github branch
        instead.

I suggest that you do. This is exactly what I do for other projects
that depend on gs 2.1.x but also require some changes are deemed unfit
for the stable branch or must wait for the release of 2.1.0 in order
to backport to 2.1.x.
        
        So I would ask that if possible we accept this. Where to go
        from there
        I'm open to suggestions. If we really want to get to a release
        after a
        true RC for once I volunteer to take care of RC4, if we're up
        to wait
        for yet another week until 2.1.0. Actually I'd really like
        that better.
        But if not just let me know and I'll revert that patch and
        branch.

Like I said before I think all the development is great and I have no
doubt that the stuff you are working on is making gwc better. But when
does it stop? To release 2.1.0 after a raft of large changes can't be
done imo and I think others will agree. So we release RC4. But what
happens then? Will we receive another batch of changes after RC4 and
have to do an RC5? And there is the question of how to address the
multiple data dir regression. We'll see what the other devs think, and
while I am ok with getting your changes in and pushing back release
date, at some point (soon) we need to get serious about actually
putting out a release candidate. And that means adhering to the
project development policies that have been unofficially agreed upon.
If they don't work for you then yes please branch.

Sorry to be so harsh but what you have done because you had a deadline
has pushed back other peoples deadlines (including myself) who are
waiting for gs 2.1.0 to be released.
        
        Sorry about the confusion.
        Gabriel
        
        On Tue, 2011-03-29 at 17:39 -0600, Justin Deoliveira wrote:
        > Hi Gabriel,
        >
        >
        > Looking at the commit log today I am seeing quite a lot of
        activity in
        > the gwc module... which sort of worries me with RC3 just
        going out the
        > door and trying to release 2.1.0 soon after. And also
        worrisome is the
        > fact that there is no discussion about this development
        going on.
        >
        >
        > I also have to beg the larger question of if all this gwc
        development
        > is suitable for the stable branch. This seems much more like
        > trunk development to me. As was illustrated with the last
        minute fixes
        > for gwc having to go into the RC3 release.
        >
        >
        > Anyways, I hate to be critical because the work you are
        doing is
        > obviously great stuff... but it just seems like at this
        point it is
        > introducing instability at a crucial point in the release
        stream and
        > would be better suited to trunk.
        >
        >
        > Care to comment?
        >
        >
        > Thanks.
        >
        >
        > -Justin
        >
        > --
        > Justin Deoliveira
        > OpenGeo - http://opengeo.org
        > Enterprise support for open source geospatial.
        >
        >
        
        >
        ------------------------------------------------------------------------------
        > Enable your software for Intel(R) Active Management
        Technology to meet the
        > growing manageability and security demands of your
        customers. Businesses
        > are taking advantage of Intel(R) vPro (TM) technology - will
        your software
        > be a part of the solution? Download the Intel(R)
        Manageability Checker
        > today! http://p.sf.net/sfu/intel-dev2devmar
        > _______________________________________________
        Geoserver-devel mailing list
        Geoserver-devel@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/geoserver-devel
        
        --
        Gabriel Roldan
        groldan@anonymised.com
        Expert service straight from the developers
        
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

5

On Wed, Mar 30, 2011 at 3:28 AM, Gabriel Roldán <groldan@anonymised.com> wrote:

ok, sorry about the lack of discussion.

It looks like I misunderstood the state of things wrt 2.1.x cause I
really thought with rc3 out we were ok to backport stable stuff.

The initial plan was to release it as is unless bugs were found.
Unforutnately we stumbled into the disk quota regression we're discussing
in the other thread, a couple of other issues with rendering coverages
(which are regressions from 2.0.x) and the WMS 1.3 bugs.
We need an RC4.

Today's commit is part of a two commit that we need for tomorrow's
deadline so that GeoNode can depend on 2.1.x, which was not possible
until now, and address the following concerns (or will when it's
finished):
- ability to enabled/disable gwc. Something people needed to do by
removing the jars instead
- ability to turn on/off caching for individual layers
- ability to properly react to style changes

But it also comes with a fix for png encoding that slipped into RC3.

None of it should be critical and I could revert it if it weren't really
necessary for GeoNode tomorrow's deadline. That said I understand the
concern and reiterate I really thought it was ok as it doesn't affect
anything but gwc integration.

Yeah, the concern I have is that we might stumble into something
like the RC2 -> RC3 issue.

I do respect and happy GeoNode is providing development time towards
GeoServer, yet that should not authorize large changes during RC.

I also have customers that want rendering transformations sooner rather
than later, and they have been waiting for two months already, but
we did not backport them to 2.1.x to avoid destabilizing GeoServer/GeoTools
codebase in a RC state, the agreement we had on that was first release
2.1.0, than backport.

I hate having done so without having properly checked, sorry about that.
If that's really unacceptable I think my only way out would be branching
2.1.x and have GeoNode depending on that branch until it's ok to merge
to the actual 2.1.x branch, but that would have to be on svn caue I'm
not sure how hard it would be to make GeoNode depend on a github branch
instead.

So I would ask that if possible we accept this. Where to go from there
I'm open to suggestions. If we really want to get to a release after a
true RC for once I volunteer to take care of RC4, if we're up to wait
for yet another week until 2.1.0. Actually I'd really like that better.
But if not just let me know and I'll revert that patch and branch.

We need a RC4 in any case, RC3 cannot be released as final unfortunately.

Could you describe what kind of changes were made to GWC in the last
commit?

When I saw the commit my jaw almost fell on the floor cause I feared
the integration changed and GWC stopped using the integration at
the dispatcher level to move towards a direct WMS integration.
That would have been really bad, as it would have made GWC impervious
to the control-flow limitations, and as a result would have made the
GS-GWC integration useless in a production enviroment that is supposed
to take a lot of dynamic caching load.

A quick inspection seems to suggest the integrated GWC is still going through
the dispatcher (pheew) but I'd still like to hear what were the changes and
why they were so important to justify their last minute commit.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

6

To be clear I was not pushing for you to roll back your commits as I did not analyze them. Just given your overview they seemed more geared toward new features rather than bug fixing and moving gwc toward stability. If I am wrong then I would say restore your changes and since we are going to have an RC4 we can try again to release it and keep fixes after its release only to bug fixes. But I leave that to you.

On Tue, Mar 29, 2011 at 9:05 PM, Gabriel Roldán <groldan@anonymised.com…1501…> wrote:

I understand.
So I’ll branch 2.1.x on svn and revert that commit out.
Sorry again for the hassle.

On Tue, 2011-03-29 at 20:47 -0600, Justin Deoliveira wrote:

On Tue, Mar 29, 2011 at 7:28 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
ok, sorry about the lack of discussion.

It looks like I misunderstood the state of things wrt 2.1.x
cause I
really thought with rc3 out we were ok to backport stable
stuff.
Today’s commit is part of a two commit that we need for
tomorrow’s
deadline so that GeoNode can depend on 2.1.x, which was not
possible
until now, and address the following concerns (or will when
it’s
finished):

  • ability to enabled/disable gwc. Something people needed to
    do by
    removing the jars instead
  • ability to turn on/off caching for individual layers
  • ability to properly react to style changes

But it also comes with a fix for png encoding that slipped
into RC3.

I am sure the fixes are very worth while but that is not the point.
These are not bug fixes, they are full blown features from the looks
of it. Features that were added while in release candiate mode.
Perhaps the project policy is not clear but we generally agreed that
since 2.1-RC1 we could keep development on 2.1.x to bug fixes and
“modest” features. Now I agree we are often too liberal with what a
modest feature means… but it does seem excessive in this case.
Perhaps I am wrong.

None of it should be critical and I could revert it if it
weren’t really
necessary for GeoNode tomorrow’s deadline. That said I
understand the
concern and reiterate I really thought it was ok as it doesn’t
affect
anything but gwc integration.

Unfortunately deadlines of downstream projects are not really an
acceptable reason for disregarding project policies. Other projects
depend on geoserver as well but we have never used them as a reason
for violating project policy. And to say that only gwc integration is
affected is sort of naive. As Andrea points out in a separate thread
changes that were isolated to the gwc module have lead to a regression
(the inability to run two geoservers from a single data directory).

I hate having done so without having properly checked, sorry
about that.
If that’s really unacceptable I think my only way out would be
branching
2.1.x and have GeoNode depending on that branch until it’s ok
to merge
to the actual 2.1.x branch, but that would have to be on svn
caue I’m
not sure how hard it would be to make GeoNode depend on a
github branch
instead.

I suggest that you do. This is exactly what I do for other projects
that depend on gs 2.1.x but also require some changes are deemed unfit
for the stable branch or must wait for the release of 2.1.0 in order
to backport to 2.1.x.

So I would ask that if possible we accept this. Where to go
from there
I’m open to suggestions. If we really want to get to a release
after a
true RC for once I volunteer to take care of RC4, if we’re up
to wait
for yet another week until 2.1.0. Actually I’d really like
that better.
But if not just let me know and I’ll revert that patch and
branch.

Like I said before I think all the development is great and I have no
doubt that the stuff you are working on is making gwc better. But when
does it stop? To release 2.1.0 after a raft of large changes can’t be
done imo and I think others will agree. So we release RC4. But what
happens then? Will we receive another batch of changes after RC4 and
have to do an RC5? And there is the question of how to address the
multiple data dir regression. We’ll see what the other devs think, and
while I am ok with getting your changes in and pushing back release
date, at some point (soon) we need to get serious about actually
putting out a release candidate. And that means adhering to the
project development policies that have been unofficially agreed upon.
If they don’t work for you then yes please branch.

Sorry to be so harsh but what you have done because you had a deadline
has pushed back other peoples deadlines (including myself) who are
waiting for gs 2.1.0 to be released.

Sorry about the confusion.
Gabriel

On Tue, 2011-03-29 at 17:39 -0600, Justin Deoliveira wrote:

Hi Gabriel,

Looking at the commit log today I am seeing quite a lot of
activity in
the gwc module… which sort of worries me with RC3 just
going out the
door and trying to release 2.1.0 soon after. And also
worrisome is the
fact that there is no discussion about this development
going on.

I also have to beg the larger question of if all this gwc
development
is suitable for the stable branch. This seems much more like
trunk development to me. As was illustrated with the last
minute fixes
for gwc having to go into the RC3 release.

Anyways, I hate to be critical because the work you are
doing is
obviously great stuff… but it just seems like at this
point it is
introducing instability at a crucial point in the release
stream and
would be better suited to trunk.

Care to comment?

Thanks.

-Justin

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

Enable your software for Intel(R) Active Management
Technology to meet the
growing manageability and security demands of your
customers. Businesses
are taking advantage of Intel(R) vPro ™ technology - will
your software
be a part of the solution? Download the Intel(R)
Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Gabriel Roldan
groldan@anonymised.com…
Expert service straight from the developers

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

–

Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

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