On 2016-09-23 11:29+0100 Tom Schoonjans wrote: > Hi Alan, > > > > A move to Github would certainly be advantageous for a number of reasons: > > - It would make receiving contributions and patches a lot easier (git-patch > is not that cool). The fork-pullrequest system is phenomenally good. > - Github provides a more pleasant user experience on its website: no one is > confronted with annoying ads when downloading tarballs > - Github is a more stable and reliable host: it has a very impressive uptime, > and I think we all remember SF’s week long outage last year… As another > example, it took me yesterday three attempts before I could successfully > clone the PLplot repository.
> - Github is considerably less evil than SF > https://en.wikipedia.org/wiki/SourceForge#Controversies > <https://en.wikipedia.org/wiki/SourceForge#Controversies> They are both big companies trying to figure out a way to monetize free software so in my view some stupidities are inevitable with both, and the question is when such stupidities occur how well do they ultimately respond to the concerns of the free software community they are hosting. I also think use of true free software products for their hosting environment does provide the free software community with some options to curb the worst excesses of the big companies in the long term. So the fact that Allura is completely free software that allows "SF clone" alternatives to SF to exist that use their identical hosting environment is reassuring to me. So I lean toward sticking with SF or one of its clones. But I might encourage someone else to move our git repository to github if git outages become the norm at SF rather than the one or two isolated incidents we have encountered so far. > > Moving the git repository to Github itself would be trivial. Just use > https://github.com/new/import <https://github.com/new/import>, but I do > recommend using the PLplot organization as owner. Just add yourself to it > first and get sufficient privileges. Hazen I think you would be able to help > out here since you seem to be in charge of this organization. > > The git history would be identical to the current one as it is a direct copy. > Afterwards you can enforce whatever workflow you are comfortable with > regarding contributions/patches. > > The website you host at plplot.sourceforge.net > <http://plplot.sourceforge.net/> is another matter. Github does allow you to > host websites (e.g. plplot.github.io), but they have to be static: no PHP! > However there is nothing from switching the git repo to github while keeping > the website where it is right now. This is actually pretty common. > > Same for downloads: either they can stay where they are or they can be moved > to github. You have answered Hazen and my concerns about the negatives well. And it does makes sense to look at each SF service we currently use (e.g., git repository, website, file release area, wiki, and mailing lists) in turn to see which we might want to migrate to github and which not. So if some PLplot developer wanted to start that process with just the git repository, I would not stand in their way. However, that person would have to take full responsibility for moving our git repository to github which would include figuring out how to enforce our current workflow (and also our future workflow if we ever change to a different enforced workflow) at github in that git pull environment. However, that work would not be enough. That same person would also have to take the responsibility for responding to git pull requests, and when they discovered a pull violated our workflow rules, they would have to advise the requester what they have to change in their own workflow to make their pull request a valid one. And I am pretty sure a request simply to rebase on master tip will not be enough for topic branches with a seriously complex history that includes merge commits. So this is a non-trivial responsibility which I would not want to personally take on. Of course, another alternative (which my impression is a lot of naive git projects use) is not to worry in the slightest about enforced workflow and just accept the consequences of a seriously complex history and git log results that are impossible for a human to decipher. But I think that would be a serious mistake for PLplot to move in that naive direction so someone really does have to take the responsibilities that I have outlined above if they are determined to move our git repository from SF to github. However, I would also be content if the PLplot developers decided as a group to stick with our current simple procedure of using the SF git repository and git format-patch/am when we wish to collaborate on non-public topic branches. Note the git format-patch/am method worked very well for Arjen and me when we collaborated on the new Fortran binding before we jointly matured that private topic enough so that we could push that whole topic to master. And that collaboration was non-trivial with much repeated use of git format-patch and git am with essentially no issues at all (other than the occasional necessary conflict resolution between our various sets of concurrent changes). To be fair, I also note that one of our other developers has not been able to get the git format-patch/am method to work for the even simpler task of collaborating with himself on various Unix and Windows platforms. But because Arjen and I had no such trouble on widely different platforms (Cygwin git for him and Linux git for me), I assume that self-collaboration trouble is simply a matter of learning the correct workflow (e.g., preparing the appropriate private branch on each local repository so that it can be brought up to date with git am) so that the git format-patch/am method works properly. But so far this other developer has not followed up with trying some of our suggestions to resolve his difficulties with git format-patch/am so it does remain a question mark for now. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
