On Tue, Mar 29, 2011 at 7:28 PM, Gabriel Roldán <[email protected]> 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 [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> --
> Gabriel Roldan
> [email protected]
> Expert service straight from the developers
>
>
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
