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> 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. On to the next email! Tom > On 22 Sep 2016, at 19:50, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > Hi Tom: > > On 2016-09-22 13:54+0100 Tom Schoonjans wrote: > >> Hello again, >> > [Hazen asked] >>> We have been trying to maintain a linear history with git following > the process explained in the README.developers file. I think that the > fork and pull-request system would break this? > >> Not necessarily, you can ask people submitting a PR that they rebase > against master. You can even enforce as a required check before > merging that new branches are up to date with the latest changes in > master. > > @Tom: > > Keeping both a github and SF repository adds quite a bit of work so I > think what we are really discussing is whether we want to move > completely to github. But that move is a lot of work as well. I (as > current de facto maintainer of our official git repository at > SourceForge) would not want to do such work. However, if someone else > wanted to take up the responsibility of maintaining our official git > repository, I would be happy to hand over that responsibility. Furthermore, > if they decided it would be a good idea to move to > github, I would not get in the way of such a move so long as such a > move did not dictate our git workflow and our git history (currently > stretching back to the early 90's) was preserved. More later about our > workflow > under a different subject line.... > > 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
