Hamish <hamish_b <at> yahoo.com> writes: > > Jarek wrote: > > Ok, it explains everything. So if I want to publish code with any GPL > > privileges granded, but keep code integrity in one official place which > > I can put in paper as link to OFFICIAL source code, with guarantee that > > it won't be accidentaly changed, I must put it outside GRASS repository? > > Right? > ... > if you want to delay releasing under the GPL until you have your article > published, then you would have to wait to put it in the grass addons repo > too, which is open to GPL-compatible code only. (as per rfc2) >
I think that Jarek's concern is that someone other than the add-on developers have commit rights. In R, this is handled by having an add-on incubator called R-Forge https://r-forge.r-project.org/, which can also be used for installation, but where the project intiator(s) are the only non-admins with commit rights. When packages are released to CRAN, installation becomes somewhat easier. This might work here if OSGeo had a *-Forge facility, part of which could be used for add-ons for GRASS. The point about R-Forge rather than CRAN is that the R-Forge SVN lets people collaborate and try things out before the add-ons reach usability (the classes start at Planning, then pre-Alpha, and so on using Trove). So until the add-on developers release it, no-one they haven't nominated can commit. It looks as though the -install argument takes a complete URL, so a miminal *-Forge would make a nightly tarball that could be installed. Of course, someone might download the add-on source, modify it, and distribute that modified version, but I'm not sure that this was the underlying issue here, rather that the public add-on SVN server has potentially many commit permissions. Roger > Hamish > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
