Hi Alan and Dave Some specific comments first, then some general ones after.
>Fundamentally, the git world is split on the rebase-only >versus merge-only question As it happens I fall in the merge camp. But for the work we have been doing up to now I don't feel there has been much difference either way.But this is personal and I know you feel strongly about rebase only so I have no intention to push you on this. >However, we could allow for deliberate rebasing (e.g., to >propagate a must-have fix from master to throwaway_plplot6), but that >would have to be scheduled a couple of days in advance I feel very strongly against this. If somebody misses the deadline because they are off email or their work isn't is a state to commit (i.e. it would break the build) then we could easily lose large chunks of work that somebody has created. In my opinion we absolutely must not rebase a branch we are working on. Ever. So perhaps some general points now In the last development cycle I tried to work simultaneously on my Windows machine and two Linux machines to test my personal branches on all three. The rebase only workflow made this essentially impossible. I continually ended up in situations where I broke my repos because I rebased some work that existed in another repo and this caused massive issues. This was one person with three checked out versions of the code and it was a nightmare. If we have more than one person then I can guarantee we will break people's repos with almost every rebase. On question that might have an impact. Do we wish to continue supporting PLPlot 5 for some time with bug fixes? It might be that some users have legacy software that relies on v5 API. So maybe we should consider having permanently separate v5 and v6 branches? I'm not sure what this does to our development model. I'm not sure this is right, but I would assume that if we apply a bug fix to the v5 branch then create a patch of this commit and apply that to the v6 branch then if we ever merge (or rebase) the branches then git is clever enough to not create a conflict. Is this correct? So in my opinion we have limited options (in no particular order) 1)We just don't run a parallel v6 branch. 2)We run a parallel branch permanently and if we have commits we wish to apply to both v5 and v6 we do so with a patch 3)We run a parallel branch permanently and if we have commits we wish to apply to both v5 and v6 we do a rebase (I think this would be very bad!!!) 4)We move to a merge workflow 5)We hide our v6 branch so we only break out own when we rebase only once when v6 is ready (already discounted by Alan) Out of all those perhaps the idea of having a v5 and v6 branch that we actually never merge together, and use patches to commit to both gives use the advantage of parallel branches and also rebase workflow? Phil On 23 May 2015 at 21:14, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > Hi Dave: > > I already made my points about continuing with the present workflow > for quite a while longer if not indefinitely in my original post > starting this topic so I think we just have to agree to disagree on > this issue. Fundamentally, the git world is split on the rebase-only > versus merge-only question, and we just happen to fall in different > camps. > > On 2015-05-23 11:59-0700 David MacMahon wrote: > >> A fairly significant advantage (IMHO) to keeping 5.8 and 6 > > development in one repository is that it makes it much easier to diff > between versions. > > This is another good point against separate servers. But I am pretty > sure Phil will agree with a variation of his idea (collaborate on a > throwaway public topic branch devoted to PLplot 6 development) that I > just proposed where it is implemented on the SF server with suitable > warnings. > > > 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
