Hi Alan,
> On 20 Nov 2016, at 13:15, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > Hi Tom: > > You obviously have a very keen interest in PLplot via your project at > <https://github.com/tschoonj/gtkmm-plplot>. Just out of curiosity, > how soon do you expect to mature that project (i.e., support all > PLplot C++ API). And which of our plot capabilities do you personally > expect to use the most once you have matured that project? > I am actually quite pleased with its current functionality: it supports everything I need it to for my project (XMI-MSIM) that makes extensive use of it. Would the need arise I will definitely restart work on it (probably when Gtk4 is out). I will of course gladly accept pull requests from anyone willing to contribute code. > More below in answer to your recent comments.... > > On 2016-11-20 10:07-0000 Tom Schoonjans wrote: > >> Hi Alan, >> >> >> Many thanks for your quick fix! It works fine: the pkg-config files are >> working fine now. > > You are welcome. > >> I would like to renew my request for a PLplot bug fix release > though. Currently, 3 patches need to be applied to get the 5.11.1 > compiling and working properly with the latest CMake. > > I assume this request is on principle and not for your own personal > needs since you can readily use the git version. Of course, I do > agree with this principle of creating bugfix releases so I would like > to grant this request, but I believe it is really too late in the > current release cycle to do that. However, if I cannot convince Hazen > to take over as release manager after 5.12.0 is out the door, then I > promise to study what I need to do from the git perspective so that I > will be well prepared to make a bugfix release after 5.12.0 if that > becomes necessary. But I am not at all well prepared now in this > regard (I am not as familiar with git as I should be) so I prefer to > avoid this distraction until after the release of 5.12.0 is completed. > It is indeed mostly for my personal needs, but it’s a bit more complicated than that. Most people that use PLplot, or any software package for that matter, use official releases, and not git master. Mostly because there is no guarantee that git master is API-stable or even reasonably bug free. git master is only meant for those that really need a particular cutting-edge new feature or so. Apart from being an enthusiast user of PLplot, I am also a Homebrew maintainer, and I am the one who is currently maintaining the PLplot formula. Given the popularity of Homebrew, it is probably fair to say that a large share (perhaps even the largest) of PLplot’s MacOS users, use Homebrew to install PLplot. Since Homebrew policy is to ensure that always the most recent releases of software packages are included, this sometimes means that tarballs need patching. Sometimes we get the patches from upstream, sometimes we produce them ourselves (and submit them upstream), but either way there is quite some time involved to get the formula up to date and working properly. Homebrew is run by volunteers with little time to contribute so we are happy when no patches are required to get a formula up and running :-) So in the case of PLplot, the formula currently requires two patches (from three commits I took from git master) to get it working for our (and your) users. I am hoping you won’t take offense, but based on what you have told me so far I find it hard to believe that it is either too late or too complicated to make a bug fix release. I don’t see how this is significantly different from: git checkout plplot-5.11.1 git checkout -b plplot-5.11.2-bugfixes git cherry-pick cac0198537a260fcb413f7d97301979c2dfaa31c 11c496bebb2d23f86812c753e60e7a5b8bbfb0a0 db396b9fbdc9cd54fb8545ea655185ca73a2a07e (+ any other bug fixes you think should be added here) run tests update changelog and commit git tag plplot-5.11.2 make tarball and release It is also certainly not too late: even if you would release 5.11.2 the day before releasing 5.12.0, that wouldn’t mean anything at all. No one would think less of PLplot or its developers. On the other hand, having a release out that cannot properly be built with the latest version of its build system for many months, while fixes are in git master, that may raise some eyebrows though :-) Best regards, Tom >> Also, this kind of bug would have been detected easily with a > continuous integration setup: that’s how I discovered this particular > bug in fact. > > I independently came to the same conclusion earlier today. This > nameclash between our build system and the CMake code provided by the > CMake official release (caused by the old CMP0054 CMake policy we are > stuck with at the moment) should have (easily) been caught when > CMake-3.7.0 was a release candidate. So to catch all such PLplot bugs > early in the future (and/or to catch CMake regressions that affect > PLplot in the CMake release candidate phase of their release cycle) we > need to continously test the latest master branch version of PLplot > that is built with the last tagged release of CMake, i.e., currently > CMake-3.7.0, but presumably CMake-3.7.1 is coming fairly soon and > CMake-3.8.0-rc1 will be coming slightly later, and they both will need > to be tested this way when their time comes. > > I plan to set up such continuous testing here with the results posted > at my.cdash.org. This should be trivial with PLplot's well-understood > ctest facility. (In fact, years ago I published ctest results as a > one-time experiment at my.cdash.org to make sure the process worked > and generating nightly test results instead and posting them at > my.cdash.org should be no more difficult.) Because of that triviality > and because the results are potentially so useful during a release > process, this is something I hope to do soon so we can get some use > out of this continuous testing at the tail end of this 5.12.0 release > cycle. > > By the way, my.cdash.org is a free service for a given project like > PLplot with the limitation that only 3 different ctest users can > publish results for a given project. So once I set this up for > ctesting on my Linux platform, I will be looking for two others (one > on a Cygwin or MinGW-w64/MSYS2 platform and one on Mac OS X to get as > wide platform coverage as possible) to publish nightly ctest results > at my.cdash.org. > > 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-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
