2009/5/18 Paolo Cavallini <[email protected]>: ... > 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
