On 2015-05-23 09:23+0100 Phil Rosenberg wrote: > 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? Caveat: I want to respond here on general grounds for whenever we do use the "git format-patch"/"git am" method, but that doesn't necessarily mean I dislike your public branch idea you discussed below so see there for further discussion of your idea. First, I don't think there are going to be that many conflicts since we all tend to stick to our strengths (e.g., I doubt I will doing lots of changes to the C++ code, and I doubt you will doing lots of changes to the build system). But I think others here do pretty much trust me on build system matters, and you on C++ matters. So if I resolve a rare conflict in the build system or you resolve a rare conflict in the C++ code, I think others will pay attention and accept our resolutions (as expressed in our constantly updated patch series) rather than trying to resolve the conflicts for themselves. > It also sounds quite was for someone to miss a patch. See Caveat above. We don't have a lot of experience with this method yet, but obviously you do have to pay close attention to "git log --oneline" results from your current private topic branch to see which of a given series should be applied with "git am --interactive". And when presenting a patch series, good communications are a big help, e.g., if you rebased your private topic branch to get some key fix on master into the private topic branch that changes at least the commit id's of your whole patch series. Therefore, if you have rebased your patch series you should say so. And similarly if your patch series does not contain all of the private topic branch, you should state something like "apply this on top of Alan's latest". etc. > 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. That's a nice offer which I very much appreciate. However, I am concerned that in general it is difficult to merge results from two different servers in active use without triggering merge commits which, of course, are prohibited on the SF server (and would likely be prohibited on the "Phil" server as well assuming we would be following the same enforced workflow rules there). I am thinking of the scenario of different PLplot 5 development pushes happening at both the "Phil" server and also the SF one before a merge of one to the other. That is a recipe for merge-commit disaster. You could work around that by enforcing a git vacation at SF so that only the "Phil" server could be used for further development for a while. But then there are concerns about up time, backups, etc. Another alternative for creating a public topic branch for PLplot 6 development would be to do that at SF, but temporarily prohibit everyone but core developers from even reading those results (which it is certainly possible to arrange at SF). But I think that interferes too much with those who are testing and following PLplot development but who are not core developers. And actually, there is the same objection to not allowing read access results to non-core developers on the "Phil" server. So if we are going to collaborate on PLplot 6 development with a public topic branch, I think that must be done at SF with full public access with suitable warnings for the public that the branch is a temporary one that will be rebased from time to time and which will eventually disappear. And if someone ignored those warnings, they would just have to accept the consequences. Technical git question: is it possible to name a branch something like throwaway/plplot6 to help ram home the point? Of course, if that is not possible the name throwaway_plplot6 would be equally effective. I do agree that collaboration on a huge development topic such as throwaway_plplot6 using this approach would be a lot more convenient than the "git format-patch"/"git am" method. However, the big caveat here (if I understand the web warnings about this) is we would have to be extremely careful of rebasing. For example, I think if someone did that by accident on their local repo and pushed the result to the throwaway_plplot6 branch at SF, I think we would all lose our local committed but unpushed work on that branch. 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 so that everyone had a chance to push their changes first. However, I freely admit I might be being overcautious about the consequences to PLplot developers of rebasing a public topic branch so correct me if that is the case. In sum, I think the two good choices for PLplot 6 collaboration are the following: (1) Collaborate on a private topic branch using "git format-patch"/"git am" but with the question still to be answered about how difficult it would be to scale that method to collaboration on a very large development topic such as PLplot 6. (2) Collaborate on a public topic branch hosted at SF with suitable public warnings and accepting the big caveat about having to be extremely careful about rebasing. The big advantage of (1) to my mind is it allows us to gain some important experience with that method which we will likely be using in any case for collaborations on smaller topics. But the case for ease-of-use for (2) is pretty compelling despite the caveats. So I am actually leaning slightly toward (2) at the moment for really big topics like PLplot 6 development unless there is some git issue I forgot. 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
