Some major development topics that have been raised either recently or within the last few months are
1. Jim's substantial planned update to plmeta/plrender and possibly plbuf. 2. Jim's potential substantial update of the wingcc device driver. 3. Arjen's substantial update to the Fortran bindings. I strongly encourage both of you to continue to develop those topics on dedicated topic branches, regardless of the various release deadlines and rules that I have forwarded below. (In other words, do not let the release process interrupt your important development work.) However, for major topics of development like these there is at least one release deadline you should be aware of which is once these topics have matured, you should wait until the first month of a release cycle to merge these topics with master. So note especially that deadline has already come and gone for the current release cycle which means the forthcoming release will be strictly a bug-fix release which I will designate as 5.11.1. Thus, ideally you should plan to land your major topic work on master right after that release. That is, please do not miss the equivalent deadline for the next release cycle. Although this current release cycle already has had a substantial number of bug fixes applied to the master branch, there is still _lots_ of bugfixing work to do for that branch. For example, I am sure that Phil would like to commit some fixes for the known bugs for his new wxwidgets code. And as a result of extremely useful reports from Orion (Fedora) and Arjen (Cygwin and MinGW/MSYS), there are still at least ~10 build system bugs I am aware of that I plan to fix in this release cycle. And once I have dealt with all of those, I plan to call for at least one more round of comprehensive testing in this release cycle to test those fixes but also to see whether additional build system issues are turned up not only on Debian wheezy, Fedora, Cygwin, and MinGW/MSYS but other platforms as well. In sum, the exact deadline for this forthcoming release obviously cannot be estimated at this time because all these planned bug fixes take an indefinite time to complete, but I will do my best to make this a short release cycle. That means I plan to get through the bugs I am working on as quickly as possible, and I assume others here who have bug fixes they want to get into this forthcoming release will do the same. 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 __________________________ ---------- Forwarded message ---------- Date: Sun, 12 Apr 2015 17:49:17 -0700 (PDT) From: Alan W. Irwin <ir...@beluga.phys.uvic.ca> To: PLplot development list <Plplot-devel@lists.sourceforge.net> Subject: [Plplot-devel] Making PLplot releases easier in future 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 ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
