On 2015-02-26 10:40-0000 Phil Rosenberg wrote: > Okay that [clear sample code of how to set up fonts] sounds promising, I take > it from this that I can leave this > in your hands for now while I deal with the aspect ratio bugs?
Yes. > >> >> Finally, another strong "would be nice" is to rewrite >> drivers/README.wxwidgets >> which your work has completely outdated now (so it is positively >> misleading). And also please put a paragraph into README.Release >> describing your recent wxwidgets work. > > Yes I very much agree and the user documentation will probably need a > rewrite which really should be done before release. > > >> So as you both are already aware, I have postponed the release to at >> least March 4th, but it struck me tonight that I did not want to >> disrupt your bug fixing by some artificial deadline. > > > So this is in many ways up to you as the release manager. Many of the > bugs we are uncovering here are long standing bugs related to the > buffer, so in some ways one could say that we should not stress too > much about them. Agreed. > However the move to using the buffer for initial > rendering of wxWidgets (when run via wxPLViewer from a console app) > has exposed them in a way that makes them rather obvious to any user. > For people making use of this driver it wouldn't be great if suddenly > we broke their code. See below in my comments about scenario 3 about one alternative for users that should allow them to avoid any issues with the rewritten wxwidgets. > I would imagine that there is another week or two > of work to bring the wxWidgets driver/binding up to scratch. So > fundamentally I see three options > 1) Release quickly regardless of the wxWidgets status and just live > with the fact that the driver isn't really up to scratch. > 2) Wait another couple of weeks to get the driver into a state where > we are happy it is of at least a similar quality to the old driver > 3) Branch from master before my first push of the new wxWidgets driver > and release that version. We can then merge the wxWidgets and buffer > fixes back in post release and go for another release in a few months > when we have had time to really get everything ironed out > > I'm sure there are potentially other options I haven't thought of too. > > However I could do with knowing what I should and shoudn't be > tampering with now. For example there is an inherited state issue with > the buffer that I thought was too intrusive to deal with now. I have > put it on Trac as a reminder for later, but I didn't see an email > about it on the list. This is the cause of the bad colours on e.g. > example 19. The slow rendering of some examples can be speeded up by > better memory allocation strategies, but again this requires t=some > changes to plbuf.c so I was going to leave this to post release. If we > are postponing then perhaps I should fix these now. To my mind scenario 3 is too much work because present master has more than just wxwidgets/plbuf commits since your big commit. However, in any case I don't think we have to be concerned with scenario 3 above so long as we make clear in the release notes this wxwidgets rewrite still is in active development, we point users to a list of the known bugs to help emphasize that point, and we also advise any wxwidgets users that currently need it for serious work, that they should likely stick for the time being with 5.10.0 until we get more of the bugs under control. In sum, I think we should be able to avoid a KDE4.0-type scenario where the initial version had quite a few bugs. I think KDE4 developer's reputation could have easily survived that (because nobody expects initial versions to be very good), but they made the situation much worse by emphasizing all the great features KDE4 would have (most of them unwritten at the time of that 4.0.0 release) and glossing over the bugs rather than being completely up-front about those like I plan to do for the wxwidgets case. With regard to what you should and should not do leading up to the release, my general advice (without much practical knowledge of wxwidgets and plbuf and the issues you actually face so that is why the advice is so general!) is don't overplan and instead simply knock off the least intrusive issues first like you are currently doing. I think ultimately it will come down to some compromise between scenario 1 and 2 above so let's see how much bug fixing we can do on the most non-intrusive issues over the next few days into the weekend and also how far I get with the preliminary tasks I need to do for the release such as updating versions, updating the website, and comprehensive testing on Linux. Then let's plan to reassess again, say by next Monday, concerning when the release date should be. So in sum, for now the release date will be March 4th at the earliest, but it might be as much as say 10 days later (the weekend of March 14th), and we will keep refining that estimate of the release date as the wxwidgets/plbuf bugs continue to be fixed and as I start to get rid of some items in my preliminary release process ToDo list. 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
