Raif S. Naffah ha scritto: > hello all, > > i'm one of those users "...lurking on this mailing list to 'check the > pulse' of the development" as Andrea put it :-) > > i agree it's a great idea and am willing to help, but pls. consider this: > > * we include GeoServer in our application but we can not, or do not, > always include the latest released version --for lots of reasons that > cannot be discussed here. the end result is that while for example the > current GeoServer is at version 2.0 (unstable) / 1.7.6 (stable), we have > installations out there that have GeoServer versions 1.5.4b and 1.6.4b!
Both dead for a long time > * 2-3 days testing is not enough. for my type of application, at least > 1-week is more like it. having a 4-6 weeks notice would also mean that > this testing period can be better planned. Our current release cycle is "once per month", so of course 4 weeks in not possible. One week could be, thought I have some reservation on it as people would use the week from end to end, so we'd end up with something like 10 days of stopped development. I guess we could tag the release in both gt2 and gs svn and treat the tags as mini branches... which would make for a "3 branches" development for a short time. My gut feeling says "no, too much work", but I'm happy to be convinced otherwise, especially if there is support from other developers to the idea and the associated extra burden. > * may be listing the general aspects/features that Users are interested > in (and are invited to) testing would also help describe the coverage of > the tests. such a list could include: WMS <version>, WFS <version>, > WFS-T <version>, WCS <version>, Datastore Extension <type>, > installation, administration, documentation, REST, GeoWebCache, I18N, > <extension>s, etc... also by OS. Getting people to test GeoServer is already hard, I think we'd be more than happy to get any testing that people feel like doing, whatever it is (e.g., it could be integration testing against your application, something that you care more about and thus have better interest in doing). If a testing group forms and there is a believe some manual testing script is beneficial some of the poeple could write it and use it, but I feel telling people what to test might hinder participation. So my feeling is that testing scripts and directions are a good idea, but people should be free to test in whatever manner they feel it's better for them. > * while this is not completely related to the idea of Users helping w/ > testing, i think it affects the Quality of GeoServer releases: i would > like to see an official "end-of-maintenance" date for every GeoServer > official release. this should not hinder the concept of "release often" > but IMO would improve the Quality factor of the/any release. of course > it may add a burden on the developers when deciding about new features, > bug fixes, etc... but again IMO it would increase the already high > quality of the GeoServer product. Historically each series reached end of development when the new series is released as stable. So for example 1.6.x died when 1.7.0 was released. That is, unless someone decides to step up and back port interesting bug fixes to the 1.7.x series and make releases. Lisasoft expressed some interest in that and is helping with the current 1.7.x releases, which the dev team would have already abandoned otherwise (so thank you Lisasoft, 1.7.6 might not have been there without your help). As an alternative there are commercial support companies that can be "persuaded" to port back selected bug fixes and make further releases out of dead branches. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
