All that sounds good to me Alan Regarding the naming - well that is not so important to me as everything else and it sounds like there are options if we need them.
Phil On 28 May 2015 at 00:33, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-05-26 22:13+0100 Phil Rosenberg wrote: > >> On 24 May 2015 at 23:01, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: >>> >>> [...] I just skimmed an interesting paper called "Fighting >>> regressions with git bisect" by Christian Couder which I highly >>> recommend to others here. (You can probably find it with a google >>> search, but for Debian wheezy it appears as >>> <file:///usr/share/doc/git/html/git-bisect-lk2009.html>.) > > >> Yeah I used git bisect a few times and it was useful. I haven't >> thought about how it would work with merges, but I can imagine how >> life would be easier with a linear workflow. Although presumably with >> merges, git bisect would simply fork down each branch? > > > Read that paper to see what happens for complicated history topology. > >> As I said with just me using 3 computers I could not get a >> system that worked. With more of us I can guarantee it won't. Don't >> forget also that there are likely to be a number of developments that >> aren't quite ready in time for release so even a final rebase will >> stuff up all of these. > > > See below. >> >> >>> >>>> >>>> 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. >>> >>> >>> >>> I think this is an illustration of the point I made previously in this >>> thread that pushing between multiple servers is virtually a guarantee >>> of merge commits which are prohibited under the rebase-only workflow. >>> >>> However, I think you could have made the above work quite simply as >>> follows (or at least I would like to see you try this method next >>> time): >>> >>> 1. Always keep master on each server exactly the same as master on >>> our official SF server. >>> >>> 2. Always rebase your topic branch on each server on that (common) >>> master branch. >> >> >> This doesn't work. Lets say I have my topic branch on PC1 and PC2. If >> I rebase my topic branch on PC1 then history gets rewritten and all my >> commits get a new guid. > > > I am not going to argue with you further here except that with care I > am positive the "git format-patch"/"git am" method will work, but I > have had a further thought that makes that argument irrelevant. > > You do have to be careful synchronizing local and remote public > branches which appears to me to be exactly what you were trying to do > amongst your various git servers. Think of all the extra steps we go > through to do that correctly for the master branch according to our > current workflow. So to do the same thing for a public topic branch I > think you have to go through exactly the same procedures, i.e., work > on a local private topic branch for plplot6 called private_plplot6, > git fetch to update the public branch origin/plplot6, merge --ff-only > that with local plplot6, rebase private_plplot6 on plplot6, merge > --ff-only private_plplot6 onto plplot6, then push plplot6 back to get > all your changes in local plplot6 changes published to the rest of > your servers. But to make this all work, it is clear you could not > rebase plplot6 on (say) the ongoing PLplot 5 development occurring in > master until there was absolutely no work left on plplot6. You have > made this point before about rebasing public topic branches so it > appears I have arrived at the same conclusion by a different route. > Note, however, that the above steps do use rebase properly and are > consistent with our rebase workflow! > >> [...]So I think I agree with most stuff up to here apart from rebasing >> during 6.0 development and maybe what happens at the "end". See below >> >>> If we follow that model it should be possible in theory to go smoothly >>> from the last PLplot 5.x release (where x < 99) to the release of >>> 6.0.0 with no overlap in support between PLplot 6 and 5, but we should >>> definitely tag the last PLplot 5 commit (as I stated in the details >>> above), and subsequently (if needed) use that tag as the origin of a >>> semi-permanent public plplot5 branch if we need to do further PLplot >>> 5.x bug-fix releases. Obviously in this case the plplot5 branch would >>> never be rebased or merged with the master branch since PLplot 5 would >>> be a dead-end branch of development (only devoted to minimal bug >>> fixing) by design. >> >> >> So I am now rather out of my depth here. this should definitely be >> considered discussive opinion and I would love feedback on this. Many >> projects seem to have some form of bugfix support for old versions or >> at the very least the option to install older versions. For example I >> canstile go to my package manager and install GTK2 and wxWidgets 2.8, >> despite the fact that GTK3 and wxWidgets 3.0 exist. The reasons are >> clear. If someone has code that uses an old API then they may not want >> to rewrite for the new API, or if someone has written another package >> which depends on plplot then we change our API and the version that >> exists in the repos then we break all those builds. I can therefore >> see a big advantage to simply leaving plplot5 frozen, and create a >> "new" library/package called plplot6 which moved forward with the api. > > > Agreed (since I have mentioned this same idea before.) We do not have > the developer resources to work on or support two different major > versions of PLplot. So the idea would be the first priority of PLplot > 6 would be to finish the backwards-incompatible stuff and pass all > tests as well as PLplot 5 currently does without introducing many (if > any) new features. Once such an initial release of PLplot 6 was made, > then we could go on from there adding new features as desired. And > PLplot 5 development would be severely limited to just fixing the most > egregious bugs. > >> That way apt-get install plplot still gives me a package compatible >> with the other binaries as expected and when ready a user can choose >> to upgrade to plplot6. As jim mentioned in an email. PLPlot 5 might be >> around for some time to come. > > > Yes, as the current PLplot-5.11.0, imminent 5.11.1 (and future? > 5.11.2) tarball releases which the PLplot 5 packagers could use for > years to come. > >> [...] If at the end we >> do want to merge plplot 5 and plplot 6, then I think that is exactly >> what we should do. In this one single instance to save us a lot of >> pain I think we should do a merge. I think that one single merge only >> at the changeover of major versions would be entirely acceptable even >> to most rebase advocates and I am sure this would be better than a >> rebase of a public branch. > > > As you might expect I am completely against breaking our workflow > unless and until we decide to permanently adopt another workflow model. > > That said, I think we are now agreed that once PLplot 6 development > starts, PLplot 5 development will continue on master and PLplot 6 > development will be done on a public branch plplot6 with no rebasing > of plplot6 on master. (Instead, fixes on master will have to be > propagated to plplot6 in other ways such as "git format-patch"/"git > am".) So if enthusiasm for PLplot 6 wanesm there are several false > starts, or the final product doesn't work very well, our ongoing > development of PLplot 5 will be unaffected. > > So really the only point of contention left is _if_ PLplot 6 development > is a complete success, how to reach the end goal of > ongoing PLplot 6 development and releases occurring on a branch called > master and ongoing PLplot 5 development (if there is any) should occur > on a branch called plplot5? One idea that I have mentioned before > which might work is to simply rename the two branches. See > <http://stackoverflow.com/questions/4753888/git-renaming-branches-remotely> > for further discussion. There was no mention there of problems for > other users (other than to rename their local branches consistently). > For example, if there was some chance of other users losing their > work, I think it would have been mentioned. > > However, at this stage I don't think we have enough information to > make a final decision now about how to implement if/when PLplot 6 is a > success. In other words, let's cross that bridge when we come to it > and not argue about it now. After all, PLplot 6 right now is a dream > in everyone's mind, but the fundamental decisions about how that > should be implemented (i.e., C++ based or C based?) have not even been > agreed on yet. And our group experience with the current workflow is > still painfully inadequate in my mind, and we will have a lot more > experience with it (for example, I hope you will be quite experienced > and comfortable with it for your 3 servers) by the time that we are > ready to release PLplot 6. > > > 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-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
