On 2016-11-14 20:05-0500 Hazen Babcock wrote: > On 09/23/2016 06:29 AM, Tom Schoonjans wrote: >> Moving the git repository to Github itself would be trivial. Just >> use 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. > > I have transferred my personal PLplot github mirror to the PLplot > organization (Hezekiah and are currently the only members): > https://github.com/PLplot/PLplot > > Now I would like to add some things into master that I think would be of some > benefit to the project, but are primarily there specifically for Github. > > (1) A README.md file. This would have a short project description as well as > links to the SF site, the documentation, etc. as well as some badges (see (2) > below). > > (2) Some .yml files, for example, one to provide "continuous" testing using > Travis-CI (.travis.yml). >
Hi Hazen: I don't mind you adding individual github-related files like you have indicated above, but I do have some overall concerns with use of github by PLplot developers. For example, as a major contributor to PLplot, I really like our "no merge commit" workflow rules since it leads to a clear history mere humans can understand on all master and topic branches. I am also satisfied with the service provided by our SF git server and our configuration of that server so that it enforces our workflow rules on the server side. Therefore, I currently plan to stick with that server as our definitive git repository for now. My primary concern is use of github would allow PLplot developers to be sloppy about following our workflow rules leading to convoluted git history that is impossible for humans to understand. However, if you can reassure me that the github version also _enforces_ our workflow rules like the SF server does (or you plan to configure the github git server for PLplot that way soon) that would clearly answer this concern. That github workflow enforcement would make it trivial to push github master branch updates to our definitive SF git server following exactly the workflow documented in README.developers that any PLplot developer with a local git repository follows now. But if you don't have that github enforcement, then the github master branch history will inevitably get filled with merge commits making it impossible to push that branch to the SF server. In sum, it would be a positive thing to establish a github git server for PLplot that enforces our workflow rules on the server side since that insures workflow discipline for all those using that repository and would be a step towards the possibility that we might move our definitive git repository to github. (Or at least it gives us that option in the future if we ever get dissatisfied with the SF git service). But without that workflow enforcement, I believe a github repository for PLplot would not be very practical for many of us to use because of the "merge commit" and bad history reasons stated above. 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
