Hi Alan
My initial thought was as yours. To have a separate plplot6 branch. I have a
feeling that with so many of us it might be difficult to keep track of sending
patches round. Do you know how that would work with clashes? I.e if two people
send patches round that clash do we have the potential for every developer
would generate their own personal resolution that would clash with everyone
else's? It also sounds quite was for someone to miss a patch.
As you identified, we certainly need parallel development on 5.8 and 6. But if
those branches are public they need to not disappear.
I could make one last alternative suggestion. We could have a private git site.
This could have separate 5.8 and 6 branches. Then when we are ready to merge we
can rebase the branch, push it to our sf repo and close the site. Then we know
that only the devs will have access and it's our own fault if we have
uncommited work based on the branch that dissapears. If it is useful I have a
static ip, a fibre optic internet connection and an always on Linux box that I
use as a media centre. It might have a 98% uptime rather than 99.9% but it
would be free and I'd be happy to set it up for access for everyone.
Phil
-----Original Message-----
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Sent: 23/05/2015 00:27
To: "PLplot development list" <Plplot-devel@lists.sourceforge.net>
Subject: [Plplot-devel] PLplot 6 and git
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
------------------------------------------------------------------------------
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
