No objection on my part. I'm working towards the next release.
> On Jul 15, 2015, at 11:59 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > Unless someone (Phil? or Jim?) objects because they are in the middle > of a substantial bug fix they would like to get into this release I > plan to declare a freeze 24 hours from now on pushing anything to > master except epa_build changes (see below), simple, no-brainer bug > fixes, and documentation improvements. I also plan to release > PLplot-5.11.1 on July 25th (just 10 days from now) unless someone > objects in the next 24 hours. > > My understanding from off-list discussion with Arjen is he is > likely done making any further changes for this release cycle. > > @Phil and Jim: > > Is it the same for you guys are do you have any more substantial bug fixing > plans for this release that should affect when I declare the > above freeze? > > To review the typical design of PLplot release cycles, the first month > is devoted to merging in matured topic branches concerning big changes > or new work (examples once these topics have matured would be Arjen's > work on the Fortran bindings, and Jim's work on his new Windows device > driver, plbuf, and new -dev plmeta) to allow long testing by all of us > during a release cycle of those big changes. Consistent with that > idea, one month into the release cycle I normally declare a freeze > (really just a guideline, but you have all been kind enough to follow > it) on pushing anything to master other than bug fixes and > documentation improvements. Then in the last week or so of the > release cycle, I tighten the criteria for allowed bug fixes as in the > freeze plans above. > > Of course, the above release cycle design will not work very well > if the intervals between releases are too large. But that is not an > issue this time since our last release was just 3 months ago, and I > hope to continue in the future with keeping release cycles to 4 months > or less. > > Here are my remaining personal plans for this release. > > 1. Work on epa_build with regard to updating many of the packages, and > trying to figure out the octave-4.0.0 segfaults. Note that epa_build > is actually specified as an exception in the above release-cycle rules > since it is just a testing platform for PLplot. Note a complete > failure of epa_build for a release is extremely unlikely to happen > since I routinely use it for release testing, but in the unlikely > event that such a failure occurred due to some stupid last-minute > change I did to epa_build, then it would still have no impact on > ordinary PLplot users since they don't use epa_build. Furthermore, > testers that do use epa_build are most likely to use the latest git > version rather than some release version in any case. So I feel > justified in making even large changes to epa_build in the last few > days of a release cycle if they "work for me".) > > 2. Monitor the results of your comprehensive testing, and fix the > build system when problems with certain platforms are revealed by such > testing. Thanks to Greg's testing of Cygwin and Arjen's testing of > Cygwin, MinGW-w64/MSYS2, and MinGW/MSYS we seem to be in pretty good > shape for those Unix-like Windows platforms. And thanks to Greg's > testing of openSUSE and my testing of Debian Wheezy we appear to be in > fairly good shape for Linux. But where our current comprehensive > testing really falls down is there are currently no results for either > the MSVC Windows platform or Mac OS X, and I hope those of you with > access to those platforms will address those testing issues soon. > Additional comprehensive testing of Unix-like Windows platforms and > especially Linux platforms is strongly encouraged as well. > > 3. Go through the release process documented in > README.Release_Manager_Cookbook starting very soon (e.g., with > updating versions, release notes, generating and testing a preliminary > version of the website, and generating and testing a preliminary > version of the release tarball) so that effectively we are all testing > a 5.11.1 release candidate for the next 10 days. > > That is really all I have time for before the release so this means I > will be putting off the following important topics until post-release: > > * Deal with two bugs I discovered in the pointinpolygon code used by > our fill software as a result of looking into what Phil thought was > a bug in the notcrossed function. These bugs only affect results in > extremely rare corner cases (one of which Phil hit but cannot > reproduce now) so the fixes will require some changes to example 25 > to hit those corner cases and will also likely require lots of > testing by pseudo-random fill events as we test PLplot in our daily > use of that software. So I plan to get these pointinpolygon fixes > in during the first month of the next release cycle to maximize > testing of the fixes before they are released. > > * Deal with some Ada language support issues for all Windows > platforms. Until this is done all comprehensive testing on Windows > should use the -DENABLE_ada=OFF cmake option. But that option > should not be used for Linux or any other Unix platform since Ada > language support should currently "just work" on such platforms. > > * Work on extending TEST_DEVICE functionality (e.g., use svg rather > than psc) from ctest to the test_noninteractive target for the build > tree, install tree, and traditional install tree. > > * Generalize exporting of PLplot targets following > <http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html>. > This fairly intrusive change should allow Orion and other PLplot > packagers a lot more flexibility in how they factor PLplot binary > packages. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
