[Gfoss] [SoC] modulo GRASS per il kriging - utenti cercasi

Markus Neteler neteler a osgeo.org
Lun 18 Maggio 2009 16:38:57 CEST


2009/5/18 Paolo Cavallini <cavallini a faunalia.it>:
...
> Solo una cosa: io, dopo lungo rimuginio, sono *contrario* agli addons
> per grass. In effetti quasi sempre i moduli, che dovrebbero stare in
> addons come incubatore, mi sembra che ricevano pochissimo testing, e
> quindi rimangano incubati per sempre. Qual e' il problema nel metterli
> nel trunk (o, nel caso siano invasivi, in un branch)?

Per motivi vari serve una incubazione:
- mantenere la qualità di GRASS "main"
- evitare che sviluppatori nuovi mettono codice in trunk che
  non è compatibile con la licenza di GRASS
- dare un testbed a quelli che sviluppano in gruppo senza
  aprire trunk al "mondo"
- ...

Esempi:
- r.viewshed: bellissimo, velocissimo, ma con errore di precisione (vedi
   test script nella cartella). Se lo mettessi in trunk oggi la gente
inizierebe
   a sostituire il lentissimo r.los, ma poi accuserebbe GRASS di creare
   dati sbagliati...,
- una serie di programmi non segue gli standards di GRASS come
  descritti nei FILE SUBMITTING*.txt. Gli autori apparentemente non
  hanno voglia di pulire il codice (nemmeno io),
- alcuni comandi sono senza documentazione,
- alcuni sono troppo specialistici (non vogliamo fare GRASS trunk
   un "sourceforge" di roba non mantenuta). Bisognerebbe generalizzare
   l'uso prima di metterli in trunk

Comandi messi in "main" di GRASS (vuol dire che c'è speranza):
- v.buffer
- v.delaunay
- r.horizon + r.sun
- ...
dopo la sistemazione dei loro problemi però.

Proposta/Soluzione:
- scrivere un meccanismo per integrare pacchetti di SVN-Addons tramite
  script (vedi R extensions manager) - volunteers?

ciao
Markus


Maggiori informazioni sulla lista Gfoss