Hi Tom:

At the end of this I have a question concerning using our preferred
workflow at github (assuming someone wants to take responsibility for
such a move).

But first, you need some background.  PLplot used CVS for a long time,
then SVN for a long time, and then fairly recently made the transition
to git, but with an enforced rebase workflow since that was so similar
to the CVS and SVN workflow we had been using previously.  And we
still have core developers getting up to speed with git even though we
have made it easy for them to transition from svn with the rebase
workflow. We also have some developers with quite a bit more
experience with git who are urging that we might want to move to a
more sophisticated workflow that makes collaboration more convenient
then it is with git format-patch/am, but we have proved with some git
format-patch/am collaborations that that method works well, and the
tradeoff for moving to a merge-based workflow appears to be either (a)
a completely messed up git history that is impossible for a human to
understand or (b) a complex but enforced merge-style workflow that
maintains clean --first-parent history (see, e.g.,
<https://itk.org/Wiki/Git/Workflow/Topic#History_Shape>). In both the
CMake and Itk cases, that clean --first-parent history is enforced by
server side hooks, but both those related projects have a human git
integration manager (Brad King in the CMake case) to help git users
navigate the complex merge workflow rules (and particularly help them
get the mess sorted out when they inevitably run afoul of the workflow
enforcement rules).

Given our own CVS/SVN background, Brad's advice when we first moved to
git was to follow the enforced rebase workflow that we currently have,
but he did also say after several years of that we might want to move
to a git workflow similar to that used by CMake.  I would not stand in
the way of such a move if someone else wanted to take full
responsibility for it including being the guy to interpret for the
rest of our developers what has gone wrong when the server side hooks
reject their pushes.  Note, I am assuming here that whatever workflow
we adopt will be enforced by server side hooks (just like now) because 
otherwise you
just end up with a mess.

@Tom: I assume github would allow us to set any server side hooks we
wanted to use to enforce our adopted workflow (just like SF does), but
could you confirm that please?

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

Reply via email to