|
From: <pl...@pi...> - 2015-06-17 11:27:26
|
On 17/06/15 13:04, Clark Gaylord wrote: > The only exception I would make is that this change in philosophy at SourceForge isn't new. I have never felt they were trustworthy, only (begrudgingly) convenient. > > Action item: we should always (have had) reference to the canonical gnuplot domain: gnuplot.info At this time, that points to SourceForge and will for the foreseeable future, but when it changes to another hosting service we only want a simple DNS update to make it happen. This change is an eventuality, so we should make changes to all documentation now. > > -- > Clark Gaylord > cla...@fa... Good suggestion. Hijacking an account then calling it a "mirror" when it delivers something else with undeclared additional software being installed on the end user's computer is fundamentally dishonest. If it was a mirror it would provide the same thing: byte perfect, not commercial crap. It betrays the confidence people have in the original product and damages the reputation thereof. Image is important and can be monetised, which is what they are doing, except it is someone else's rep. they profiting from and damaging in the process. If someone could get it together to sue, they would likely be entitled to damages. Peter. |
|
From: Tatsuro M. <tma...@ya...> - 2015-06-18 00:03:12
|
----- Original Message ----- > From: "plotter > To: Clark Gaylord > Cc: gnuplot-beta > Date: 2015/6/17, Wed 20:18 > Subject: Re: SourceForge seems to add adware to software (windows installer) > > On 17/06/15 13:04, Clark Gaylord wrote: >> The only exception I would make is that this change in philosophy at > SourceForge isn't new. I have never felt they were trustworthy, only > (begrudgingly) convenient. >> >> Action item: we should always (have had) reference to the canonical gnuplot > domain: gnuplot.info At this time, that points to SourceForge and will for the > foreseeable future, but when it changes to another hosting service we only want > a simple DNS update to make it happen. This change is an eventuality, so we > should make changes to all documentation now. >> >> -- >> Clark Gaylord >> cla...@fa... > > Good suggestion. > > > Hijacking an account then calling it a "mirror" when it delivers > something else with undeclared additional software being installed on > the end user's computer is fundamentally dishonest. > > If it was a mirror it would provide the same thing: byte perfect, not > commercial crap. > > It betrays the confidence people have in the original product and > damages the reputation thereof. Image is important and can be > monetised, which is what they are doing, except it is someone else's > rep. they profiting from and damaging in the process. > > If someone could get it together to sue, they would likely be entitled > to damages. > > Peter. I also think that SourceForge (SF) behavior becomes really bad but facilities that SF provides is not so bad. I summarized what services the gnuplot project are offered from SF and compare them on those alternative (Bitbucket and Github). (I do not have write access right to the gnuplot project on SF so my summary may not be complete. Please correct errors the below.) 1. File distribution Source, small document (NEWS, README), windows binary (installer and zip) 2. Project Trackers Bugs Feature Requests Patches Support Requests 3. Project Mailing Lists gnuplot-beta: Subscribe | Archive | Search — Developers and beta testers of new gnuplot code gnuplot-info: Subscribe | Archive | Search — For questions and discussion about gnuplot 4. CVS version control system # The "News" facility on SF has been used until ver 4.6.4 but later version do not use this facility. According to the page I introduced in my previous post https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities Popular source code hosting facilities seems to be Bitbucket and Github. For Bitbucket and Github 1.* 2. 4.* are supported but 3*. is not supported. *1 Facilities of Bitbucket and Github seem not to be so systematical as that in SF. *3 Bitbucket and Github do not also support forum. I found the tortoisehg uses Bitbucket but their mailing list is hosted on SF Mailing list (Personally I prefer mailing list than forum.) or forum cannot be omitted from the project. *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?) If the gnuplot project transfer from SF to Bitbucket or Github, the version control system should be changed. 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. To be honest, I myself cannot judge that the gnuplot project should leave SF because I have never done maintaining works on SF system. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2015-06-18 03:08:37
|
----- Original Message ----- > From: Tatsuro MATSUOKA > To: "plotter; Clark Gaylord > Cc: gnu...@li... > Date: 2015/6/18, Thu 09:03 > Subject: Re: SourceForge seems to add adware to software (windows installer) > > ----- Original Message ----- > >> From: "plotter >> To: Clark Gaylord >> Cc: gnuplot-beta >> Date: 2015/6/17, Wed 20:18 >> Subject: Re: SourceForge seems to add adware to software (windows > installer) >> >> On 17/06/15 13:04, Clark Gaylord wrote: >>> The only exception I would make is that this change in philosophy at >> SourceForge isn't new. I have never felt they were trustworthy, only >> (begrudgingly) convenient. >>> >>> Action item: we should always (have had) reference to the canonical > gnuplot >> domain: gnuplot.info At this time, that points to SourceForge and will for > the >> foreseeable future, but when it changes to another hosting service we only > want >> a simple DNS update to make it happen. This change is an eventuality, so we > >> should make changes to all documentation now. >>> >>> -- >>> Clark Gaylord >>> cla...@fa... >> >> Good suggestion. >> >> >> Hijacking an account then calling it a "mirror" when it delivers >> something else with undeclared additional software being installed on >> the end user's computer is fundamentally dishonest. >> >> If it was a mirror it would provide the same thing: byte perfect, not >> commercial crap. >> >> It betrays the confidence people have in the original product and >> damages the reputation thereof. Image is important and can be >> monetised, which is what they are doing, except it is someone else's >> rep. they profiting from and damaging in the process. >> >> If someone could get it together to sue, they would likely be entitled >> to damages. >> >> Peter. > > > I also think that SourceForge (SF) behavior becomes really bad but facilities > that > SF provides is not so bad. > > I summarized what services the gnuplot project are offered from SF and compare > them > on those alternative (Bitbucket and Github). > (I do not have write access right to the gnuplot project on SF so my summary > may not be complete. Please correct errors the below.) > > 1. File distribution > Source, small document (NEWS, README), windows binary (installer and zip) > > 2. Project Trackers > Bugs > > Feature Requests > Patches > Support Requests > > 3. Project Mailing Lists > gnuplot-beta: Subscribe | Archive | Search — Developers and beta testers of > new gnuplot code > gnuplot-info: Subscribe | Archive | Search — For questions and discussion > about gnuplot > > > 4. CVS version control system > > # The "News" facility on SF has been used until ver 4.6.4 but later > version do not use this facility. > > According to the page I introduced in my previous post > https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities > > > Popular source code hosting facilities seems to be Bitbucket and Github. > > For Bitbucket and Github > 1.* 2. 4.* are supported but 3*. is not supported. > > *1 Facilities of Bitbucket and Github seem not to be so systematical as that in > SF. > > *3 Bitbucket and Github do not also support forum. > I found the tortoisehg uses Bitbucket but their mailing list is hosted on SF > Mailing list (Personally I prefer mailing list than forum.) or forum cannot be > omitted from the project. > > *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?) > > If the gnuplot project transfer from SF to Bitbucket or Github, the version > control system should be changed. > 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. > > To be honest, I myself cannot judge that the gnuplot project should leave SF > because I have never done maintaining > works on SF system. > > Tatsuro Perhaps many people know the below but at least for me I have found this today (2015-06-18). Third party offers will be presented with Opt-In projects only http://sourceforge.net/blog/third-party-offers-will-be-presented-with-opt-in-projects-only/ I personally feel that their statement is not consistent with that Gimp project insists on this issue. However, they state that they added adware to the binary of unmaintained project. The gnuplot project is very active on SF. * Changes on the source tree have been done very frequently. * Version up has been regularly done. Believing SF's statement the above, the gnuplot project may not become a target. Therefore we do not need hurry at this moment and discuss this issue with taking time involving other people who are related to the gnuplot project. # However, what they did on Gimp windows installer is quite horrible. # I wonder that SF will change their matter again to illy direction. Tatsuro |
|
From: Mojca M. <moj...@gm...> - 2015-06-18 05:30:32
|
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 |