Re: SourceForge seems to add adware to software (windows installer)

[Mojca M. <moj...@gm...>]

On Thu, Jun 18, 2015 at 2:03 AM, Tatsuro MATSUOKA wrote:
>
> 1. File distribution
> Source, small document (NEWS, README), windows binary (installer and zip)
> Facilities of Bitbucket and Github seem not to be so systematical as that in SF.

Distribution of source code is very well supported. But it's *a lot*
easier if ./configure and other vital files become part of the
sources. Then it becomes just a matter of tagging a specific commit
and declaring it to be a version. GitHub/Bitbucket then automatically
generates zip/tar.gz files. GitHub is a bit more picky about
distributing binaries.

> *4 Both Bitbucket and Github do not support CVS.
>  The CVS is now considered to be an old version control. Many other projects uses git or mercurial.
>   Bitbucket git and mercurial
>   Github    git
>
>   Gnuplot project have been used cvs for a long time and code size is not so large and number of people
>   who has write access is limited so that the CVS is enough for the gnuplot project (Am I right?)

I just wanted to say that if anything, CVS is *the* most vulnerable
part of the project and the one that should be "migrated off" with the
highest priority. I don't think the following would happen, but if
SourceForge really starts being evil, you could loose the complete
history of gnuplot source code (unless you make regular backups of CVS
from the server via rsync; not just the current checkout).

>  If the gnuplot project transfer from SF to Bitbucket or Github, the version control system should be changed.

Indeed, but that's a very good thing. Git (and mercurial) have strong
checksumming built in and even if the server disappears out of the
blue, you'll still have a complete copy on everyone's machine and
nobody would be able to tamper with the sources without everyone else
noticing.

CVS is vulnerable. It has a bit of "dementia" (it's not always
possible to reconstruct the exact history), if one deletes a folder,
the whole history of that folder is gone, one can easily modify files
on the server ...

>  The automatic transfer tools from cvs to git or mercurial exist but they seem not to be complete.
>  Human resources will be required if we change the version control system.

People offered help, but it was usually declined because developers
wanted to stick to CVS. The problem with "incompleteness" of the tools
is that CVS history cannot be reconstructed exactly, so one needs some
 heuristics and guessing (and some obscure features like tagging
together files from different times cannot easily be reproduced in
git). And the longer one waits, the more history gets "forgotten".

The main problem with CVS -> GIT conversion is that it's feasible to
do it once, but it's very annoying to do incremental updates.

Mojca