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

Reply via email to