Re: [Plplot-devel] Plans for the release of 5.11.1

[Jim D. <ji...@di...>]

No objection on my part. I'm working towards the next release. 



> On Jul 15, 2015, at 11:59 AM, Alan W. Irwin <ir...@be...> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel