Andrea Aime wrote: > Justin Deoliveira ha scritto: >> Hi all, >> >> I have revamped the extensions/community module GSIP: >> >> http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules >> >> I have taken into account Jody's feedback, and also some of the >> conversation that has taken place over IRC while I was away. >> >> Please look over again and provide any more feedback, or comment on >> things you don't like or are missing. > > Well done. A few comments: > * I don't see any reference to signing the contribution > agreement. When does this happen? We have three choices: > - when getting commit access in the community area > - when graduating to extension > - when graduating to core > Imho core module shall be covered. Probably extensions too, > since we are distributing them. Community, meh, let's > avoid this requirement and allow people to contribute > without that extra headache? Agreed, i think we want to keep the bar for community modules as low as possible. Signing a contributor agreement is now a req for promoting a community module. > * Imho the wording for the demotion from extension/core > to community should be more direct: once the maintainer > steps down the destiny of the module is in the PSC hands, > which will evaluate if it's good, quiet, whatever is > deemed necessary to keep in in the supported land I have broken this out into its own section with some process and requirements for demoting a module. Should be move explicit now. > * community and extensions do have a maintainer. > Person or company? What about core modules, who's > the maintainer for them? the PSC itself? Seems fitting, > if you want to have a seat on the PSC you take some > of the onus of keeping the boat afloat (aka > "with great power comes great responsibility") I like this idea for sure... but i am not sure it has to be explicit. If anyone is an active maintainer of core modules, chances are they are already on the PSC, and if not I would say there is more a problem with the PSC process. > * in the extension process you say: > "A license called '<module>-LICENSE.txt' which > contains the license for the extension". You mean, > stuff like reporting usage of Apache modules and > the like? I mean, the extension module should be > GPL'd no? Or else, maybe not, but as things are > today, it's very hard to develop a module that does > not link to one of our's GPL'ed classes Not sure about this one... this is what we do now with extensions so i just went with it. My initial thoughts are that any GPL compatible license would be ok...? so an extension could a different license...? Not sure, what do the license guru's think about this one?
> * typo: "The more t4est coverage a community module > the more credibility it gets." t4est -> test Fixed. > > Provided the contribution agreement and wording > for demotion of extension/core are taken care of, > assume I'll vote +1 (since I won't be around next > meeting). > > Cheers > Andrea -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
