I view this as one of the "stars" we use to evaluate things (ie things we care about as a community) rather then a complete down check. The fact that the coverage is being checked with a nightly build somewhere means that any incidental breakage will be found out quickly right?
We do not demand all the points raised be covered in order to graduate; but we do want to know what we are up against with respect to plugin documentation, test coverage, ip check etc. I think ip check is the only formal one that can issue a down check. We do try and have our procedures on the website to make the project open; simply so you don't have to go through the PMC to get your module up to supported status. That is you can tell what is needed before hand; rather then learning criteria at the last moment. Ben I am still interested in doing a code review (or tour?) on skype/IRC if it can be arranged. Not that I don't trust your team; I just want the PMC to know what is being added as this is when they are expected to be able to answer for it. Jody On 18/05/2010, at 6:11 PM, Andrea Aime wrote: > Ben Caradoc-Davies ha scritto: >> On 18/05/10 14:38, Andrea Aime wrote: >>> How is the test coverage? >> >> OK. All encoding test are in GeoServer. >> >>> Is it a single module or multimodule? >> >> Multiple. gt-app-schema, gt-app-schema-resolver (coming soon), >> gt-sample-data-access (for testing). >> >>> You are the maintainer for all of them? >> >> Yes. >> >>>> All the docs and much of the test coverage is in GeoServer. >>> Ah, much of the test coverage where it cannot be measured... ugh... >>> does it go beyond 40% with the tests in Geotools? >> >> Even if it did (which I doubt), most of the breakage occurs in bad >> encoded output, which is an integration problem of combining >> gt-app-schema with the encoder in a GeoServer WFS configuration. >> >> Until GEOT-2948 was fixed, it was not possible to write a full encoder >> configuration for testing app-schema encoding outside GeoServer, because >> of the (then) fragile nature of configurations. With Justin's changes >> this is much more robust, and it now should be possible, but all of our >> encoding tests are in GeoServer. Furthermore, given the very complicated >> test fixtures, a GeoServer data directory is pretty much the best way of >> setting them up. We could in theory now backport all out encoding tests >> from GeoServer app-schema-test to GeoTools. And where would be set the >> schemaLocations? A lot of breakage is in the interaction with >> FeatureTypeSchemaBuilder, which is in GeoServer. > > Ok, this goes against the graduation rules, you don't have the necessary > testing coverage. > > I don't see it as a blocker myself, as you say you have the testing > in GeoServer, but at the same time I don't want to start adding > precedents of module graduations that formally break the graduation > rules (when another module is in the same situation what do we do, > negate graduation because the maintainer is not a friend/PMC member?) > > I think the best way to handle this is to call for a full PMC vote, > it is an exceptional situation and requires slightly exceptional > measures. Should be quick and provide the necessary backing for > bending the rule on this particular occasion. > > Cheers > Andrea > > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
