I wrote this the other day, then put it in my draft folder... (So, I'd g=
o with the "tracker page" concept.)
> Timoth=E9e Lecomte wrote:
> > I was wondering if it wasn't the good moment to do a fresh release of
> > gnuplot, I mean "gnuplot 4.1".
> I think it's way too early for that. Worse yet, I'd have to be the one=
> to do it, and I don't see where I could steal the time for that right=20
> now. Last time took about us 6 weeks of preparation, the last two of=20
> them nearly full-time on my end of things.
Yes, but that was a major upgrade spanning back 5+ years, having switched=
archive locations to SourceForge, a fully new home page by Ethan--many p=
roblems that would've been spread out had releases been done more often. =
My thinking is the code has gotten much cleaaner and the developers with=
CVS access have been very prompt about jumping on bugs that find their w=
ay into the code.
> People have got used to a
> "release early --- release often" strategy. Sorry, but with the=20
> licensing issues as they are, that's a non-option for gnuplot.
> That set aside, I don't think the code currently has the level of=20
> maturity people rightfully expect from a release version of gnuplot.=20
> There's way too much on-going activity on the 'adding features' front=20
> for that. We have to let the dust settle a bit before a release can be=
> considered in earnest.
Agreed. But still, I think compared to the position we were in when deve=
lopers decided to release 4.0, we're already much further along.
> The most we could usefully do right now is a general review of open=20
> patches and feature requests, with a view towards making a three-way=20
> decision for each and every one of them:
> 1) outdated ---> tag as such, and close.
> 2) keeper --> tag 'release-critical', integrate in good time, then clos=
> 3) later --> tag 'later', keep open
Also, how about on the web page we have a "future items" list. Something=
we all have accesss to and won't get lost. That is, rather than writing=
the "new features" subsection of the release notice _after_ the release =
is ready, let's do it _before_ the release process is begun. That will h=
alt the new features added to the release candidate for a few months.
So I will offer up a couple things for the list if we were to start one:
Image Plotting: We've covered the major output formats except for Window=
s, I think... I know little about windows resources.
Binary Data Input: I think Petr and I have shaken out the bugs and preve=
nted any kind of major program breakage that could come from trying to in=
terpret binary data. I understand this may be a bit dodgy for some becau=
se of the low use for interactive users. But it is aimed for interchangi=
ng data between programs, not trying to read someone's generic, small, un=
defined raw data.
Faster Data Input?: On that note, after the fact of using binary data to=
speed up data transfer for images came a discussion about the scanf() fu=
nction having major slowdown for long line reads... something I only unde=
rstood in concept, i.e., having to rescan previous entries on the line or=
something. But of course, this probably contributed to the problem of t=
ransferring ASCII image files taking many seconds. Will this scanf() slo=
wdown be addressed in this release? Or are we at the mercy of any compil=
ers on this one?
Passing an X window ID into the program: I don't think this is in yet. =
I'm not particularly motivated to include it, but someone else requested =
that I add it. It seemed such a small addition that it should be bug fre=
e, or easy to fix if a bug does come up. (Writing the xWidgets program t=
o demo the thing was by far more difficult.)
More advanced key placement: Needs debugging. No crash bugs, instead th=
e "that shouldn't go there for this option" kind of thing. I'll get to t=
his within a month when I get back to my home base.
Some compile problems with #ifdef chunks in gnuplot_x11 based upon config=
urations at the ./config command line. Again, within a month.
Raise/lower for X windows: Don't know the status of that one. May be so=
me group reluctance because other window platforms might not have it. Co=
de wise, no brainer.