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

Reply via email to