Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-19 22:55:22
|
On Thu, 19 Feb 2004, Lars Hecking wrote: > If you want to go ahead with a release, fine. I have _zero_ time for > non-work stuff right now, and the situation will not improve in the > short term. OK, so it'll have to be me, then. I'll see if I can prepare a tarball for upload to SF.net before the weekend. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-19 23:17:06
|
On Thu, 19 Feb 2004, Daniel J Sebald wrote: > Hans-Bernhard Broeker wrote: > >it's time for last-minute checking before 4.0 release, run their own > >tests, and report whatever showstoppers they might find. If we don't > Who are the "people out there", other than the developers? I'm talking about a publicly announced release-candidate test here. I.e. we would post to all the relevant mailing lists and newsgroups that there's a release coming up, and whoever feels like it should get their package and try it out. It may be necessary to provide at least some prebuilt binaries for platforms that don't routinely come with a C compiler (DOS, Windows and OS/2, e.g.) at SF.net. > 1) Wait a couple months while the "beta testers" try it out and find > some bugs before releasing to the large group of end users. A couple of weeks will be enough to that, I guess. Easter is in 6 weeks, which is in about the right timeframe and a nicely memorizable date. > 2) Consider the group of developers to be the beta testers. That would be pointless, I think. We've all been running this stuff routinely for ages --- the remaining ugly bugs, if any, will now be hidden in places where none of us ever looks. We need external eyes and exercises for that. > 3) Make a release and let the large group of end users find any bugs. That would be the usual approach in open-source projects, "Release early, release often". Unfortunately, releases of gnuplot are tricky enough to organize to make this a non-option. > Approach 1 means a group of beta testers is required. Is there such a > group? No. We'll have to go public and call for volunteers for that. > testing it for a couple weeks. But I don't think we could ask them to > keep getting updates, so it would have to be fairly close to the actual > 4.0 release. I don't think we either should or can have more than one, maximum two such release candidates. I.e. we'll informally declare 3.8k (to be released ASAP) as release candidate #1 and call to the user mailing list for pre-release testing of that. An RC #2 will only be made if we get so swamped in bug reports that we must assume the fixes for them will break something else or interact with each other. Otherwise, we fix what is found, and I bundle up a release tarball. > I doubt any beta tester would have found the bug, You just disproved yourself by counter-example. You yourself were the beta-tester who found it. ;-) You may not have started out to do it with the term "beta-test" in mind, but that's essentially what you did. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Daniel J S. <dan...@ie...> - 2004-02-20 06:39:29
|
Hans-Bernhard Broeker wrote: >On Thu, 19 Feb 2004, Daniel J Sebald wrote: > > > >>Hans-Bernhard Broeker wrote: >> >> > > > >>>it's time for last-minute checking before 4.0 release, run their own >>>tests, and report whatever showstoppers they might find. If we don't >>> >>> > > > >>Who are the "people out there", other than the developers? >> >> > >I'm talking about a publicly announced release-candidate test here. >I.e. we would post to all the relevant mailing lists and newsgroups >that there's a release coming up, and whoever feels like it should >get their package and try it out. It may be necessary to provide at >least some prebuilt binaries for platforms that don't routinely come >with a C compiler (DOS, Windows and OS/2, e.g.) at SF.net. > > <snip> Sounds like a good plan, Hans. >>3) Make a release and let the large group of end users find any bugs. >> >> > >That would be the usual approach in open-source projects, "Release early, >release often". Unfortunately, releases of gnuplot are tricky enough to >organize to make this a non-option. > > Oh, that I'm not suggesting. Yes, releasing a new version often is bad. Neither is not often releasing a new version very good. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-20 12:44:50
|
On Fri, 20 Feb 2004, Petr Mikulik wrote: > > allow at least a couple of weeks between 3.8k.0 release and 4.0, there's > > no point doing a 3.8k in the first place. > > > > important platforms. For the 16-bit DOS/Windows and part of the Win32 > > > > We're talking about roughly 6 weeks, here, or 1.5 months. That's not > > exactly very much. The code freeze is for *us* to worry about. > > Ok, thus gnuplot-3.8k is released now, including: > - source code tarball > - binary releases for MSW 32bit, OS/2, (and some 16bit?), will full docs > - maybe some RPM package? No RPMs of 3.8k. We'll leave that to the Linux distributors who integrate the actual release version, if and when they decide to do so. > We want that > - bugs are reported > - missing Windows et al terminal entries to be added, if contributed "missing terminal entries"? I don't think I see what you're talking about there. > Announcement should go to all principal application groups -- Octave mailing > list, maybe slashdot and similar? (in CZ, e.g. www.root.cz) Slashdot: no. But freshmeat should be updated. I'll send an announcement gnuplot's own lists (including the newsgroup). If some of you know other places that should receive an announcement, forward it to them once I've posted it. > Deadline for 4.0 should be specified. I would like March 31 (5 weeks) .. > somehow I fear April is quite late. You *do* seem pretty allergic to the word "April", Petr.... something particular about it? ;-) > (It would be great if new gnuplot goes > into some important Linux distro, like SuSE 9.1. -- if not, it's about > loosing half year then!) It feels like there's an average of at least one major Linux distro being updated every month. No matter when we release, we'll have missed the release freeze of half of them by half a release interval.... that's really nothing we should worry about. > > What with the "ask Thomas Williams about it" business and all, an official > > release cycle of gnuplot is difficult enough that we don't need the > > additional complexity of a 4.0.1 fix-up release four weeks later. > > I see. Does he (and other people) have to agree with 4.0 and with any of its > further releases? Yes. Tom Williams (and some others, for individual source files) has final say over any "official" release --- that's what the gnuplot Copyright statement says, like it or not. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Petr M. <mi...@ph...> - 2004-02-20 13:59:50
|
> > - source code tarball
> > - binary releases for MSW 32bit, OS/2, (and some 16bit?), will full docs
> > - maybe some RPM package?
>
> No RPMs of 3.8k.
Ok, I just wanted we make "guideline" binary packages with all docs, demo et
al what should be inside.
> > - missing Windows et al terminal entries to be added, if contributed
>
> "missing terminal entries"? I don't think I see what you're talking about
> there.
Sorry, it was not exact -- there are several of the unimplemented --
according to the TODO file:
-- rotated text is not supported
demo/textrotate.dem does not pass correctly
-- palette colored text is not supported
demo/textcolor.dem does not pass correctly
and some other items, like
-- update wgnuplot menus
-- windows driver does not report font size to windows.trm, thus
character widht and height are quite useless numbers
These things, if someone contributes them, should be added, right?
(Some people can think of them as bugs, others missing features.)
> You *do* seem pretty allergic to the word "April", Petr.... something
> particular about it? ;-)
Maybe I like more winter than spring?
Well, the point is I though gnuplot 4.0 could be released in December, and
now I see how months are passing and passing...
---
PM
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-20 15:38:48
|
On Thu, 19 Feb 2004, Hans-Bernhard Broeker wrote: > On Thu, 19 Feb 2004, Lars Hecking wrote: > > > If you want to go ahead with a release, fine. I have _zero_ time for > > non-work stuff right now, and the situation will not improve in the > > short term. > > OK, so it'll have to be me, then. I'll see if I can prepare a tarball > for upload to SF.net before the weekend. Done. Tarball's up at SF.net, announcement to newsgroup is out. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Petr M. <mi...@ph...> - 2004-02-20 17:00:57
|
> > OK, so it'll have to be me, then. I'll see if I can prepare a tarball > > for upload to SF.net before the weekend. > > Done. Tarball's up at SF.net, announcement to newsgroup is out. Very good! I think that gnuplot.sourceforge.net can be replaced by my creature gpweb-004.zip It links to www.gnuplot.info for those who are not interested in this prerelease. Similarly, it would be worth if www.gnuplot.info contains link to the new 3.8k page. If you agree, and who has the rights, please unzip that creature at the appropriate place. Then we can reference to the new page. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-20 20:06:50
|
On Fri, 20 Feb 2004, Petr Mikulik wrote: > I think that > gnuplot.sourceforge.net > can be replaced by my creature > gpweb-004.zip If I hadn't misplaced my reference as where you have it, it could ;-) > If you agree, and who has the rights, please unzip that creature at the > appropriate place. You could even do it yourself. You have ssh and scp access to a shell at sourceforge, and the Web site gnuplot.sf.net is writable from there. Try to work extra carefully if you decide to do that --- you're working on the live site data! -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Lars H. <lhe...@us...> - 2004-02-20 20:24:49
|
> > If you agree, and who has the rights, please unzip that creature at the > > appropriate place. > > You could even do it yourself. You have ssh and scp access to a shell at > sourceforge, and the Web site gnuplot.sf.net is writable from there. Try > to work extra carefully if you decide to do that --- you're working > on the live site data! I've done it. Excellent work, Petr! |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-02-20 20:44:42
|
On Friday 20 February 2004 12:18 pm, Lars Hecking wrote: > > You could even do it yourself. You have ssh and scp access to a shell > > at sourceforge, and the Web site gnuplot.sf.net is writable from > > there. Try to work extra carefully if you decide to do that --- > > you're working on the live site data! > > I've done it. > > Excellent work, Petr! Yes. It's shaping up nicely. I've updated the gnuplot.sourceforge.net/demo/ directory contents also. They are now html 4.0.1 transitional compliant (well almost), and can should even be viewable in broken browsers like IE5. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center (206)543-1421 Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Lars H. <lhe...@us...> - 2004-02-20 20:50:17
|
> I've updated the gnuplot.sourceforge.net/demo/ directory contents also. > They are now html 4.0.1 transitional compliant (well almost), and can > should even be viewable in broken browsers like IE5. Could you also please go through the permissions of all the files you created (I have moved demo to demo.old, couldn't do much more with it), and make sure that all directories are chmod 755 (maybe 775 is better), all files are 664, and group ownership is always gnuplot. This will insure that all developers in the gnuplot group have full access to all files. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-02-20 21:04:40
|
On Friday 20 February 2004 12:43 pm, Lars Hecking wrote: > > I've updated the gnuplot.sourceforge.net/demo/ directory contents > > also. They are now html 4.0.1 transitional compliant (well almost), > > and can should even be viewable in broken browsers like IE5. > > Could you also please go through the permissions of all the files you > created (I have moved demo to demo.old, couldn't do much more with it), > and make sure that all directories are chmod 755 (maybe 775 is better), > all files are 664, and group ownership is always gnuplot. This will > insure that all developers in the gnuplot group have full access to all > files. Done. I thought that setting g+sw on the directory was sufficient, but apparently not. Sorry. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center (206)543-1421 Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2004-02-23 15:06:37
|
> Could you also please go through the permissions of all the files you created > (I have moved demo to demo.old, couldn't do much more with it), and make > sure that all directories are chmod 755 (maybe 775 is better), all files > are 664, and group ownership is always gnuplot. This will insure that all > developers in the gnuplot group have full access to all files. From some strange reasons, I cannot touch files in subdirectories. I don't see what's wrong in file permissions... only in "demo/" directory I can write a file. Can you please fix it? If you are there, please move scr-new-petr/index.html into screenshots/index.html, and remove this directory. --- pm |
|
From: Lars H. <lhe...@us...> - 2004-02-23 15:19:44
|
> >From some strange reasons, I cannot touch files in subdirectories. I don't > see what's wrong in file permissions... only in "demo/" directory I can > write a file. > > Can you please fix it? > > If you are there, please move scr-new-petr/index.html into > screenshots/index.html, and remove this directory. Done. Petr, you too need to take care that all files and directories you create are group-writable! |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-02-20 15:37:34
|
On Fri, 20 Feb 2004, Petr Mikulik wrote: > > > - missing Windows et al terminal entries to be added, if contributed > > > > "missing terminal entries"? I don't think I see what you're talking about > > there. > > Sorry, it was not exact -- there are several of the unimplemented -- > according to the TODO file: > > -- rotated text is not supported > demo/textrotate.dem does not pass correctly > -- palette colored text is not supported > demo/textcolor.dem does not pass correctly There's nothing strictly wrong with optional features actually not implemented by a particular driver. As long as the demo doesn't break (i.e. gnuplot all.dem exits), that's not a big deal. > and some other items, like > -- update wgnuplot menus They've been updated in 01'2003. If you see any more badly missing things, go ahead and add them --- the syntax is easy enough. > -- windows driver does not report font size to windows.trm, thus > character widht and height are quite useless numbers > > These things, if someone contributes them, should be added, right? *If*. And if the changes aren't too massive to invalidate pretty much all the testing being done with the existing code. > > You *do* seem pretty allergic to the word "April", Petr.... something > > particular about it? ;-) > > Maybe I like more winter than spring? March 31st is in spring too. ;-> -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X