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
