I was confident in early February that the planned release date of February 28th for PLplot-5.11.0 would be straightforward to achieve, but obviously the release was delayed 6 weeks beyond that date by a number of factors. I would prefer to avoid such factors if at all possible in the future since a sliding release date is extremely difficult for volunteer developers to adjust to. All of us have lots of other things going on in our lives, but with a fixed release date that everybody knows in advance it is fairly likely most of us can make an effort for the last week of the release to help get it out the door. But all that potential cooperation is out the window when that single critical week stretches (ouch!) into 7 weeks.
As release manager I have to take responsibility to provide the guidance to avoid such an issue in the future so below I discuss some general lessons I have learned from this bad experience, and the remedies I plan to adopt so this experience is not repeated for future releases. Here are the lessons: 1. Keep release cycles short. Adopting that lesson reduces the chances of regressions creeping in and creating surprises (as occurred for this release) that tend to indefinitely delay the release. 2. Create definitive benchmark comprehensive tests for all platforms accessible to us. Adopting that lesson will make it much easier for us to detect regressions in the future. 3. Master branch should be primarily used for bug fixing in preparation for the next release. So all major PLplot changes should be implemented on local topic branches which are shared with those interested in helping with the initial testing using the "git format-patch"/"git am" approach mentioned in README.developers. Only when a topic has completely matured (i.e., all bugs discovered by initial testing have been fixed) should it be pushed to master branch for testing and debugging by a larger group. 4. Pushes of major topics to the master branch should be done only relatively early in release cycles. That gives important time for the "testing and debugging by a larger group" referred to above to take place. Here are the specific remedies I propose: 1'. Consistent with lesson 1, I propose to get the next release out in 4 months (by mid-August) _at the latest_. However, an earlier bug-fix release (say called 5.11.1) that contains only bug fixes and not major changes is certainly possible if a lot of bug fixing gets done soon. @Everybody: Through release testing we uncovered a number of bugs discussed on this mailing list that we had to put off fixing until post-release. The time to deal with those known bugs is now. 2'. Consistent with lesson 2, I have already (in a different post) strongly encouraged everybody here to run scripts/comprehensive_test.sh on the platforms you have access to and report those benchmark results to me and/or <http://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>. When that testing clearly reveals comprehensive_testing.sh issues (such as Arjen having to brute-force Cygwin to get that script to run) or build-system issues, I certainly plan to either provide the fix or provide strong support for finding the fix. 3'. I am going to encourage everybody to use the lesson 3 approach for further major developments. This immediately applies to both Arjen (currently working on a fortran binding rewrite) and Jim (currently working on major changes to plmeta/plrender and possibly plbuf). @Arjen and Jim: does this lesson 3 approach work for you? 4'. Consistent with lesson 4, I think pushes of important topics to the master branch should only be done in the first month of a release cycle. @Arjen and Jim: To be specific I plan to adopt May 9th as the deadline for pushing of major mature topics to master. So if you make that deadline, your work will get into the next release, but if your other time commitments make it impossible for you to make that deadline, then please continue to mature your topics as time permits and aim to push your major topics to master in the first month of the subsequent release cycle. @Everybody: I hope these lessons I have learned and my specific plans to conform to these lessons makes sense to everybody here. But if not, I would welcome further discussion of your own ideas for making the release process a lot easier for both you and me. 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 __________________________ ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
