hello Andrea, my comments are in-line.
On Friday 20 March 2009 20:58:01 Andrea Aime wrote: > Raif S. Naffah ha scritto: > > hello all, > > > > apologies for the intrusion on the list but may i suggest an > > alternative to simply removing those extensions which could be a > > potential source of funding for the GeoServer developers: grade > > the extensions, say into three levels of quality (high, medium, and > > low) and continue publishing them. users can then judge for > > themselves and would know what to expect if they find a bug. this > > of course depends on a minimal level of functionalities these > > extensions should have --beyong getting compiled without errors :-) > > > > later on, and on regular basis you could study the download figures > > and a decision to retire or change the grade of extensions can be > > made. > > Mumble, what would the criteria be? Atm we have the following: > - whatever is in the core distribution is actually supported > and used by the developers > - real GeoServer extensions (i.e., imagemap, excel) have support, > they are just not considered of general interest enough to be part of > the core distribution but they could be considered high quality - a > number of data/coverage store (oracle I'm looking at you) extensions > may have a maintainer but the level of support on them is definitely > lower (medium) > - certain extensions are not really working, and we know it. We could > say they are "low" quality, but it's kind of a stretch since we > all know they have no maintainer at all -> support level on them is > zero solid. If you want to actually use them, better be a developer > that can fix any issue that might come up. from what you describe i can see two categories: "supported" and "unsupported" v/s today's list which does not qualify any of the extensions. even a simple quality-related adjective could be enough indication for the users to know what to expect. > I have troubles going out and tell the world "here, this is not > working and we know it". I mean, by the same token we could start > adding other stuff that's sitting in GT2 as well no? Looking into > geotools unsupported we have netcdf, geomedia, gpx, geometryless, > sql-datastore, tiger that are in no real better shape of the gml > datastore. Maybe they work, maybe they don't, no core dev really > knows any better than that (I never tried out the gml/vpf datastores > for example). if these extensions can be built in the process of a standard release of GeoServer then listing them with the "unsupported" qualifier could be a source of information for users who may have plans to develop a similar extension or contact the developer(s) behind the existing ones to improve them. > Afaik the idea behind providing gml2 datastore was around the lines > of "let's see if anybody is interested enough to step up and become > maintainer of that stuff". understood. as GeoServer gains more momentum and gets installed in more sites as stand-alone or in combination with other applications, this rationale remains valid. again just qualifying it as "unsupported" could be enough for the expectations of those who may be interested in it. > A more serious approach, imho, could be to list all of these and > point people to the sources: "Interested? Jump on the dev board and > help us with any of these modules". cheers; rsn
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
