On Wed, Mar 30, 2011 at 3:28 AM, 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.
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 ------------------------------------------------------- ------------------------------------------------------------------------------ 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
