Vaclav Petras <wenzesl...@gmail.com> writes: > On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler <nete...@osgeo.org> wrote: > > The general criteria are > - code follows submission standards > - must be portable > - must be well documented with examples > - must be of interest to a wider audience > > I would add "well tested (i.e. very mature) or having somebody willing to fix > it (soon) if needed". > > Related to that, I wonder if we should create some standard mechanism for > introducing experimental things - things which might later show as unstable, > not useful or buggy. For example, I introduced v.decimate which is now in 7.2 > branch. It has its merit but I started to think that perhaps a different set > of > functions or interface can be more useful there. I wonder if I should just > put [experimental - use with care] at the end of the module description.
I would add the following: 1) add [experimental] / [beta] / ... behind the in the menu 2) disable the experimental / beta / ... addons 3) add an option to enable all the experimental / beta / ... addons, which can than state "experimental, might make your computer explode, use at own risk and only in well ventilated rooms"... Cheers, Rainer > > This is out-of-topic here, but similarly we might want to introduce something > like [deprecated] for modules, options and flags. > > Vaclav > > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982
signature.asc
Description: PGP signature
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
