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 <[email protected]> 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 <[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. > > > > -- > Gabriel Roldan > [email protected] > Expert service straight from the developers > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
