Re: [Plplot-general] Possible move to github?

[Alan W. I. <ir...@be...>]

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
__________________________