Assuming we move forward with plplot6 development in the short term (either with or without moving to C++ for the core library depending on what the consensus is here on that topic), then we should also start thinking about the git workflow implications of such a large and important development topic.
Our current rebase workflow does allow us to create a public topic branch called (say) plplot6 which would make it very easy for us to collaborate on PLplot 6 development on that branch. But our workflow rules absolutely prohibit merging that public branch back to master unless plplot6 is rebased, but rebasing of a public branch is never a good idea since it annoys users who are depending on some of those public commits which disappear due to rebasing. Of course, one possibility is simply never to rebase and never to merge and then when the plplot6 branch has matured we could rename the master branch to plplot5 and rename plplot6 to master. But I am concerned we are all in such a habit of rebasing private branches we are working on, that someone would try that for the public plplot6 branch which would not be a good result for the above reason. So because of that concern about accidental rebasing, my gut feeling is it would be better to create plplot6 as a private topic branch where local private rebases are fine, and simply collaborate on plplot6 development using the well-known "git format-patch"/"git am" method that has worked reasonably well in the past for collaborations between Phil, Jim, and me; which I am encouraging Arjen to use in his future collaboration with me on the new fortran binding private topic branch; and which other software projects use a lot for their own private topic branch development. Of course, another possibility is to change to an alternative git workflow i.e., the merge-only first-parent linear history workflow recommended by Brad King that he suggested we might want to move to after all our developers are completely comfortable with git using the current rebase workflow that he recommended we start with. That alternative does allow easier public collaboration at the expense of a lot more complexity in both following and enforcing the workflow. But I think it is much too soon for such a change in our workflow because not all our developers are comfortable with git yet. Furthermore, I quite like the current rebase-only workflow (as described in README.developers) so I would like to continue with that indefinitely and develop major topics such as plplot6 always on rebased private branches using "git format-patch"/"git am". Comments? 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 __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
