On 2014-08-14 01:39-0700 phil rosenberg wrote: > That workflow seems good to me. >
> This model depends quite heavily upon having at least two permanent branches. A stable master and an unstable testing and perhaps also a (semi-stable) bug fixes branch. Are you suggesting that we should adopt this for Plplot? Yes, so long as another stable integration branch that you didn't mention (called variously main and maint) is also part of the story, I believe this whole branching scheme is similar to <http://nvie.com/posts/a-successful-git-branching-model/> but with one less integration branch. But I am not completely sure of that, and the CMake wiki article appears to be for the benefit of topic branch developers. For example, it says little about the main branch and may gloss over some behind-the-scenes details about what happens at release time for CMake where indeed there might be a release branch as well. I will have to review some messages in cmake devel near release time about how they handle releases, and also look carefully at gitk results for the cmake git repository to get a more complete story from the point of view of managing releases. But I am confident if that aspect works for CMake it will also work for me as our current PLplot release manager. > > The basic workflow would be: > 1) When you want to work on a topic, branch from master (never from testing). > 2) If your work depends on work in another topic that hasn't been merged > into master then merge the other topic into your topic. > 3) Never ever merge master into a topic. > 4) When a topic is complete merge it into testing and perhaps into bug-fixes. > 5) At release time or every now and then, the release manager takes all the > stable topics and merges them into master. > > The only downside I see is that 2) and 5) are a bit fiddly because the topic branches are never published so you have to search for merge points into testing, get their hashes and use them for merging. > One advantage would be that it would force us to evaluate what should be moved to master fairly often, otherwise 2) will become rather cumbersome. I do think it is probably a pretty good workflow to adopt. If it works for cmake there is no reason why it shouldn't work for us. Good summary except I don't think 5) is an issue since my interpretation is that it is the topic developer's responsibility to merge to master. For example, note that the wiki article mentions the release manager has control of merges to main (the maintenance branch for releases), but it doesn't say anything about such control for master. But same comments as I made above about release management details. I do agree with your point that 2) would be a bit fiddley for extremely long-lived topic branches that become dependent on other's work over time. But I don't think that has historically ever been an issue for PLplot. One issue not mentioned in the article was collaboration between developers working on the same topic branch. But in the cases when such collaboration was desired, I assume that could be arranged (e.g., via github facilities for publishing individual developers repos) so long as all collaborators on a topic resisted the urge to merge master into their topic. 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
