[GRASS5] GRASS 6.0.1 release schedule

GRASS GIS GRASS GIS developer
1

Hi developers,

I think that it's time to get out GRASS 6.0.1 bugfix release.
The 6.0.1 version should be in a good shape now.

Here a proposed schedule:

- 5 July 2005 (Tuesday): I'll package a 6.0.1_beta1 and publish it
  on the web site. Testing needed.
- 12 July 2005 (Tuesday): I'll package a 6.0.1_beta2and publish it
  on the web site. Testing needed.
- depending on the test, we can get out GRASS 6.0.1 in the week
  from 18-22 July.

I volunteer for being the release manager (in case of objections let
me know).

TODO for now:

- testers please grab and compile/test the current GRASS GIS 6.0.1 CVS
  snapshot:
  http://grass.itc.it/grass60/source/snapshot/
- report problems to get them potentially fixed for 6.0.1_beta1 next week.

Again: please test it on various platforms.

Thanks

Markus

2

I think that it's time to get out GRASS 6.0.1 bugfix release.
The 6.0.1 version should be in a good shape now.

Here a proposed schedule:

Sounds good.

To recall a bug list from a previous email:

--
Subject: [GRASS5] Re: [Pkg-grass-general] update
Date: 2005-05-28 01:01:57 GMT
I wrote:

[Pkg-grass-general]
> > GRASS 6.0.1 has not been released yet.
>
> So we should do that!

critical bugs to fix:

cs2cs doesn't see GRASS's NTv2 grid files. see:
  http://bugzilla.remotesensing.org/show_bug.cgi?id=834

Fixed by Paul. I have lightly tested; don't know if it has been applied
to the 6.0.x release branch.

v.in.garmin - add more checks to survive above bug when downloading
track.

done. Merged.

r.out.gdal - broken with quoting problem.

done. I don't know if it has been applied to the 6.0.x release branch.

r.terraflow still using insecure temp files

Laura pointed out that r.terraflow uses mkstemp() to create the temp
files in raster/r.terraflow/IOStream/lib/src/ami_stream.cc. So the temp
files should be secure after all.

100% cpu usage during mouse ops. Real problem for multi-user machines
and when using GRASS over a network connection.

outstanding, not good, but not release critical.

others?

Hamish

3

From: "Hamish" <hamish_nospam@yahoo.com>

I think that it's time to get out GRASS 6.0.1 bugfix release.
The 6.0.1 version should be in a good shape now.

Here a proposed schedule:

Sounds good.

To recall a bug list from a previous email:

--
Subject: [GRASS5] Re: [Pkg-grass-general] update
Date: 2005-05-28 01:01:57 GMT
I wrote:

[Pkg-grass-general]
> > GRASS 6.0.1 has not been released yet.
>
> So we should do that!

critical bugs to fix:

cs2cs doesn't see GRASS's NTv2 grid files. see:
  http://bugzilla.remotesensing.org/show_bug.cgi?id=834

Fixed by Paul. I have lightly tested; don't know if it has been applied
to the 6.0.x release branch.

v.in.garmin - add more checks to survive above bug when downloading
track.

done. Merged.

r.out.gdal - broken with quoting problem.

done. I don't know if it has been applied to the 6.0.x release branch.

r.terraflow still using insecure temp files

Laura pointed out that r.terraflow uses mkstemp() to create the temp
files in raster/r.terraflow/IOStream/lib/src/ami_stream.cc. So the temp
files should be secure after all.

100% cpu usage during mouse ops. Real problem for multi-user machines
and when using GRASS over a network connection.

outstanding, not good, but not release critical.

others?

Hamish

Several. Not sure if really none of them has been fixed - I've been using a month old 6.1 CVS and can't grab a fresh one right now (modem). Besides, none of the comments in the bugtracker proves any has been fixed thus it would be good to take a look at them and evantually close. Other bug reports of mine which I'm sure got fixed I closed about a month ago. I might be able to test these remaining bugs with a fresh 6.1 CVS about next weekend. Plaese do it yourself if you can't wait.

r.proj works ONLY when source and target mapset names are identical
http://intevation.de/rt/webrt?serial_num=3362&display=History

d.where -l is giving wrong results
http://intevation.de/rt/webrt?serial_num=3172&display=History
(Paul said it shouldn't be hard to fix yet the discussion stopped at some
point. Quite important - GIS should handle any coordinates conversion perfect.)

zooming in v.digit changes resolution in region settings
http://intevation.de/rt/webrt?serial_num=2962&display=History

if you zoom in/out much v.digit is likely to crash
http://intevation.de/rt/webrt?serial_num=3047&display=History
(I guess that http://intevation.de/rt/webrt?serial_num=3164&display=History
refers to the same problem.)

r.to.vect - broken pipe
http://intevation.de/rt/webrt?serial_num=3168&display=History
(Guessing - might it be related to problems with topology support for points and memory leaks with v.in.ascii which were dicussed recenlty on grass devel list?)

r.statistics G_calloc: out of memory
http://intevation.de/rt/webrt?serial_num=2668&display=History
(Sorry, I haven't checked if it applies in 6.0/6.1; could somebody do it?)

invisible errors in GUI
http://intevation.de/rt/webrt?serial_num=3010&display=History
(If a segfault happens when the command is called from GUI there is *no any
information* for the user about it, all looks normal. Thus, one can seat for
ages and wonder, why the program doesn't make any progress).

v.type GUI bug
http://intevation.de/rt/webrt?serial_num=2969&display=History

v.in.ogr, GUI, fails during "Building areas:"
http://intevation.de/rt/webrt?serial_num=2937&display=History
(As far as I recall Radim told me it doesn't make sense to fix this bug because TCL/TK interface "has no future". Maybe right, but a bug is a bug.)

r.bilinear result is rounded to .5, GUI and --help issues
http://intevation.de/rt/webrt?serial_num=2790&display=History
(The "rounded to 0.5" issue still aplies as I recall.)

r.info displays the '(zone 0)' message in any location
http://intevation.de/rt/webrt?serial_num=3054&display=History
(A lot mess there, sorry! Go to the bottom of the page, there is a fresh
comment by me).

r.mapcalc - warning/errorr amibiguity
http://intevation.de/rt/webrt?serial_num=3069&display=History

d.m should close on exit
http://intevation.de/rt/webrt?serial_num=3050&display=History

v.to.rast doesn't asign the cats and labels
http://intevation.de/rt/webrt?serial_num=3045&display=History

I'm talking here of my bugs. Could other reporters take a look at their bugs as well? I mean if 6.0.1 is really going to be a bugfix relaese...

Cheers
Maciek

4

On Sat, 2 Jul 2005, Maciek Sieczka wrote:

cs2cs doesn't see GRASS's NTv2 grid files. see:
  http://bugzilla.remotesensing.org/show_bug.cgi?id=834

Fixed by Paul. I have lightly tested; don't know if it has been applied
to the 6.0.x release branch.

It hasn't. I hesitated to do it because it changes the output of
"g.proj -jf" to make it machine-specific (path to gridshift files hard-coded) and someone may be relying on the old behaviour so it may not be a good idea to change it. But when I think about it more, the old behaviour often didn't work so maybe it could be justified to merge the patch.

r.proj works ONLY when source and target mapset names are identical
http://intevation.de/rt/webrt?serial_num=3362&display=History

That has been fixed (revert change to lib/gis/asprintf.c using G_tempfile) I didn't resolve the bug report as there was a discussion about G_tempfile() usage ongoing.

d.where -l is giving wrong results
http://intevation.de/rt/webrt?serial_num=3172&display=History
(Paul said it shouldn't be hard to fix yet the discussion stopped at some
point. Quite important - GIS should handle any coordinates conversion perfect.)

I've looked into this a bit more but still haven't been able to track it down. See comment to bug report CCed to grass5 list.

zooming in v.digit changes resolution in region settings
http://intevation.de/rt/webrt?serial_num=2962&display=History

Just a little comment that I think it is a nice feature that v.digit shares
the region with the location rather than the 5.x and earlier v.digit which by default used the region in the header of the vector map. But obviously more thought needs to go into how the location region and the map region interact and I don't use v.digit any more so am unable to contribute.

r.info displays the '(zone 0)' message in any location
http://intevation.de/rt/webrt?serial_num=3054&display=History
(A lot mess there, sorry! Go to the bottom of the page, there is a fresh
comment by me).

I suppose that dates back to when UTM was the only projection GRASS supported and thus zone was always relevant. I wouldn't like to try fixing it without risking breaking something else. It is a harmless "feature", is it not?

5

I hope it's OK to ask about a few others. I've made a few bug reports in the past, and nothing has been done for them. I don't know how to otherwise get things moving (I've been meaning to ask around):

#2544 SHLIB_LD for darwin (Mac OS X) needs to be fixed. This is the biggest one - I have to patch every CVS snapshot. In the last comment I have in there, the SHLIB_LD setting I give still work gor 6.0, but doesn't for the current CVS (the meaning of LIB_RUNTIME_DIR changed for some reason). This works for both 6.0 and 6.1:

         SHLIB_CFLAGS="-fno-common"
         SHLIB_LD="cc -dynamiclib -flat_namespace -compatibility_version \${GRASS_VERSION_MAJOR}.\${GRASS_VERSION_MINOR} -current_version \${GRASS_VERSION_MAJOR}.\${GRASS_VERSION_MINOR} -install_name \${INST_DIR}/lib/lib\${LIB_NAME}\${SHLIB_SUFFIX}"

#3104 & 3105 Missing $(TIFFLIBPATH) in a couple makefiles (OGSF and NVIZ). I build GRASS with support libraries in a non-standard location (from my GraphicsLibs and GISLibs installers), and these will fail without the path for libtiff. Other Mac OS X users (like Lorenzo) might have libraries in a non-standard location (ie Fink and DarwinPorts). For both 6.0 and 6.1.

Those are the main ones, that I think should get into a 6.0.1 release, and 6.1 of course. There are a few others I haven't checked recently, or that have been quietly fixed or fixed themselves (how can I close them?).

On Jul 2, 2005, at 12:15 AM, Hamish wrote:

I think that it's time to get out GRASS 6.0.1 bugfix release.
The 6.0.1 version should be in a good shape now.

Here a proposed schedule:

Sounds good.

To recall a bug list from a previous email:

--
Subject: [GRASS5] Re: [Pkg-grass-general] update
Date: 2005-05-28 01:01:57 GMT
I wrote:

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

6

On Sat, 2005-07-02 at 16:38 +0100, Paul Kelly wrote:

> r.proj works ONLY when source and target mapset names are identical
> http://intevation.de/rt/webrt?serial_num=3362&display=History

That has been fixed (revert change to lib/gis/asprintf.c using G_tempfile)
I didn't resolve the bug report as there was a discussion about
G_tempfile() usage ongoing.

I'm about 2/3 done with the G_tempfile()/G_local_tempfile() stuff. I
don't think it would be wise to apply my changes at this stage of the
release as it requires modification of many files that need to be
reviewed by the list before they're applied.

I could finish this over the weekend if it is really necessary to deal
with before release.

--
Brad Douglas <rez@touchofmadness.com>

7

On Sat, 2 Jul 2005, Brad Douglas wrote:

On Sat, 2005-07-02 at 16:38 +0100, Paul Kelly wrote:

r.proj works ONLY when source and target mapset names are identical
http://intevation.de/rt/webrt?serial_num=3362&display=History

That has been fixed (revert change to lib/gis/asprintf.c using G_tempfile)
I didn't resolve the bug report as there was a discussion about
G_tempfile() usage ongoing.

I'm about 2/3 done with the G_tempfile()/G_local_tempfile() stuff. I
don't think it would be wise to apply my changes at this stage of the
release as it requires modification of many files that need to be
reviewed by the list before they're applied.

I could finish this over the weekend if it is really necessary to deal
with before release.

Hello Brad
I've just realised---Maciek's bug report related to the 6.1 CVS and so was not relevant to the release as the bug didn't exist in 6.0.
I assume also you'll be making any changes to the CVS HEAD and not the 6.0 release branch, thus this is all irrelevant to the release of 6.0.1 and we can carry on as before!

Paul

8

>> I think that it's time to get out GRASS 6.0.1 bugfix release.
>> The 6.0.1 version should be in a good shape now.

..

> To recall a bug list from a previous email:

..

>> critical bugs to fix:

..

> others?

..

Several.

Of course there are many unfixed bugs that are important to individual
users, I was mostly refering to severe release critical bugs that we
should not release a new version without fixing first. There can always
be a 6.0.2 release with more bug fixes sometime in the future, but don't
hold up the current release to fix every single bug in the software,
otherwise it will never happen.

Not sure if really none of them has been fixed - I've been
using a month old 6.1 CVS and can't grab a fresh one right now
(modem).

cd grass61-source
make distclean
cvs login
cvs -z3 update -dP

That only downloads updated source code in compressed form.
See the GRASS/CVS web page for info on anonymous login.

Besides, none of the comments in the bugtracker proves any
has been fixed thus it would be good to take a look at them and
evantually close.

Yes. (guilty as anyone)

Another important system bug I just remembered -- the help pages and the
GUIs do not use the opt->key_desc descriptions. !!

e.g.
G> d.barscale --help
Usage:
d.barscale [-mflt] [bcolor=name] [tcolor=name] [at=x,y]

d.barscale help page:
SYNOPSIS
d.barscale [-mflt] [bcolor=string] [tcolor=string] [at=float]

all the hinting is lost & "at=x,y" becomes "at=float". Thus the help
pages are less helpful and even misleading as to what option input
should look like. Same with the module GUI frontends (float, optional).

Worse is d.legend where [at=bottom,top,left,right] becomes [at=float]
in the help page and tcltk GUI. Unless the user stumbles across --help,
they are left to guess past the errors. Not good.

thus

"g.module --html-description" is wrong.
"g.module --tcltk" is wrong.

but

"g.module --interface-description" is correct.

I think it is important to fix this before a 6.0.1 release.

Hamish

9

>> Fixed by Paul. I have lightly tested; don't know if it has been
>> applied to the 6.0.x release branch.

It hasn't. I hesitated to do it because it changes the output of
"g.proj -jf" to make it machine-specific (path to gridshift files
hard-coded) and someone may be relying on the old behaviour so it may
not be a good idea to change it. But when I think about it more, the
old behaviour often didn't work so maybe it could be justified to
merge the patch.

I wonder if there was a good reason to put in the full path, perhaps it
is more simple to use ("$GISBASE/etc/nad/%s",nad_file) instead of
("%s/%s",nad_dir,nad_file) ?

Makes the output non-useful for use outside of GRASS but it certainly
makes it easier to read and the output portable across systems (e.g.
bug reports), especially when your $GISBASE is something long like:
/home/user/src/grass/grass61-cvs/dist.i686-pc-linux-gnu.

Hamish

10

#2544 SHLIB_LD for darwin (Mac OS X) needs to be fixed.
#3104 & 3105 Missing $(TIFFLIBPATH) in a couple makefiles (OGSF and
  NVIZ).

(left to someone who knows about such things..)

Those are the main ones, that I think should get into a 6.0.1
release, and 6.1 of course. There are a few others I haven't checked
recently, or that have been quietly fixed or fixed themselves (how
can I close them?).

Add a reply or comment to the bug in the bug tracker of the bug that is
finished saying so, and cc grass5.

Hamish

11

On Sun, 3 Jul 2005, Hamish wrote:

I wonder if there was a good reason to put in the full path, perhaps it
is more simple to use ("$GISBASE/etc/nad/%s",nad_file) instead of
("%s/%s",nad_dir,nad_file) ?

Makes the output non-useful for use outside of GRASS but it certainly
makes it easier to read and the output portable across systems (e.g.
bug reports), especially when your $GISBASE is something long like:
/home/user/src/grass/grass61-cvs/dist.i686-pc-linux-gnu.

Sounds like a promising idea. Perhaps it is unlikely that the output of g.proj would be used outside a GRASS session anyway. The only thing I would worry about is will the GISBASE environment variable always be expanded or might there be quoting arrangments (currently in use by users) where it doesn't expand.

Paul

12

On Sun, Jul 03, 2005 at 09:04:55PM +1200, Hamish wrote:
...

Another important system bug I just remembered -- the help pages and the
GUIs do not use the opt->key_desc descriptions. !!

e.g.
G> d.barscale --help
Usage:
d.barscale [-mflt] [bcolor=name] [tcolor=name] [at=x,y]

d.barscale help page:
SYNOPSIS
d.barscale [-mflt] [bcolor=string] [tcolor=string] [at=float]

all the hinting is lost & "at=x,y" becomes "at=float". Thus the help
pages are less helpful and even misleading as to what option input
should look like. Same with the module GUI frontends (float, optional).

Worse is d.legend where [at=bottom,top,left,right] becomes [at=float]
in the help page and tcltk GUI. Unless the user stumbles across --help,
they are left to guess past the errors. Not good.

thus

"g.module --html-description" is wrong.
"g.module --tcltk" is wrong.

but

"g.module --interface-description" is correct.

I think it is important to fix this before a 6.0.1 release.

I don't think so. We cannot wait longer, there are
*critical* bugfixes already waiting to be published.
We can have 6.0.2 then.

Markus

13

On Sat, Jul 02, 2005 at 05:15:45PM +1200, Hamish wrote:

> I think that it's time to get out GRASS 6.0.1 bugfix release.
> The 6.0.1 version should be in a good shape now.
>
> Here a proposed schedule:

Sounds good.

To recall a bug list from a previous email:

--
Subject: [GRASS5] Re: [Pkg-grass-general] update
Date: 2005-05-28 01:01:57 GMT
I wrote:

> [Pkg-grass-general]
> > > GRASS 6.0.1 has not been released yet.
> >
> > So we should do that!
>
>
> critical bugs to fix:
>
> cs2cs doesn't see GRASS's NTv2 grid files. see:
> http://bugzilla.remotesensing.org/show_bug.cgi?id=834

Fixed by Paul. I have lightly tested; don't know if it has been applied
to the 6.0.x release branch.

> v.in.garmin - add more checks to survive above bug when downloading
> track.

done. Merged.

> r.out.gdal - broken with quoting problem.

done. I don't know if it has been applied to the 6.0.x release branch.

Merged.

To answer such questions, run

     CVSBRANCH=`cat CVS/Entries | grep AUTHORS | cut -d'/'-f6 | cut -b2-`
     sh tools/cvs2cl.pl --follow "$CVSBRANCH"

The resulting ChangeLog file will only contain branch related
messages.

Markus

14

From: "Paul Kelly" <paul-grass@stjohnspoint.co.uk>

r.proj works ONLY when source and target mapset names are identical
http://intevation.de/rt/webrt?serial_num=3362&display=History

Hello Brad
I've just realised---Maciek's bug report related to the 6.1 CVS and so was not relevant to the release as the bug didn't exist in 6.0.

Right, my fault. Sorry for the trouble.

Maciek

15

From: "Hamish" <hamish_nospam@yahoo.com>

>> I think that it's time to get out GRASS 6.0.1 bugfix release.
>> The 6.0.1 version should be in a good shape now.

..

> To recall a bug list from a previous email:

..

>> critical bugs to fix:

..

> others?

..

Several.

Of course there are many unfixed bugs that are important to individual
users,

Oh no, I didn't write this all that just to satisfy my needs.

I don't use v.digit (almost) because it's risky, "d.where -l" bug is not a big problem for me because I know about it and since then do't use it, similar with "invisible errors in GUI", "v.type GUI bug", "v.in.ogr, GUI, fails during "Building areas:" etc..

Maybe only the "r.to.vect - broken pipe" might show out a work-stopper for me when day when I really need to convert few 3" SRTMs to vector points for reprojection and re-interpolation.

So I'm writing about this all to get hopefully fixed and to spare other folks same troubles, first of all. Yes, I can't fix it myself so I realise I might be bothering talking of them over and over again. And I'm very gratefull for all those you mighty coders fixed, which helped us all to use Grass more efficiently and easier.

On the other hand, it is hard for me to advertise Grass to others when I know there are bugs in such an important module as v.digit. Or that if he uses GUI and segfault appears he won't even know about it and will meaybe say instead "Well, I'll leave the computer on till tomorrow and see what happens". Or that "d.where -l" will give him wrong coordinates, (sick!).

I was mostly refering to severe release critical bugs that we
should not release a new version without fixing first.

Few of those I mention are critical, aren't they?

There can always
be a 6.0.2 release

BTW - will there be 5.4.1? I know you are not in charge but could the one please answer?

with more bug fixes sometime in the future, but don't
hold up the current release to fix every single bug in the software,
otherwise it will never happen.

I'm not holding anything because. I'm asking you Guys to fix those critical bugs before releasing bug-fix release. Sorry if you can't.

Here's what I imagine: Say I started using Grass from 6.0. Then 6.0.1 - great bug-fix release! And what? Same old bugs remain. In spite of the fact they have been know for several weeks or months. I wonder what I would have thought of GRASS.

Not sure if really none of them has been fixed - I've been
using a month old 6.1 CVS and can't grab a fresh one right now
(modem).

cd grass61-source
make distclean
cvs login
cvs -z3 update -dP

OK, that was a poor excuse ;). I will need to learn how to use CVS soon anyway. Thanks for the example. And I hope I can find enough time next weekend to test all the bugs I have reported so far which haven't got officialy fixed.

Maciek

16

From: "Hamish" <hamish_nospam@yahoo.com>
To: "William K" <woklist@charter.net>

Those are the main ones, that I think should get into a 6.0.1
release, and 6.1 of course. There are a few others I haven't checked
recently, or that have been quietly fixed or fixed themselves (how
can I close them?).

Add a reply or comment to the bug in the bug tracker of the bug that is
finished saying so, and cc grass5.

Just to spare some the time to coders, I volunteer (ehm, a big word) to be in charge of closing bugs. If nobody minds, I'd like to be CC'ed by the bug-reporter, who doesn't have the bugtracker writing access, when he decides the bug can be closed. If that makes sense to everybody please put my email and the according advertisement on the bugtracker page, or wait until I do it this/next week, when I get the CVS write access (Markus told me I could apply for CVS wite access for fixing website and documentation typos).

Maciek

17

From: "Paul Kelly" <paul-grass@stjohnspoint.co.uk>

zooming in v.digit changes resolution in region settings
http://intevation.de/rt/webrt?serial_num=2962&display=History

Just a little comment that I think it is a nice feature that v.digit
shares
the region with the location rather than the 5.x and earlier v.digit which
by default used the region in the header of the vector map. But obviously
more thought needs to go into how the location region and the map region
interact and I don't use v.digit any more so am unable to contribute.

That's absolutely right that the region extent should be changing along
panning in v.digit, very usefull. Yet the resolution shouldn't change along
zooming. And I can't understand why it does, kill me. It is a bug. With this
bug present, it is impossible to digitize with a given accuracy. The
accuracy must not be changing while digitizing. What's more, I guess that
crashes in v.digit when zooming in/out are related. Disabling this floating
resolution might propably be a cure for crashing as well (correct me if
talking rubbish).

(I'm not addressing this particulary to you Paul; that's a comment for
somebody in charge of v.digit; if there is such).

r.info displays the '(zone 0)' message in any location
http://intevation.de/rt/webrt?serial_num=3054&display=History
(A lot mess there, sorry! Go to the bottom of the page, there is a fresh
comment by me).

I suppose that dates back to when UTM was the only projection GRASS
supported and thus zone was always relevant. I wouldn't like to try fixing
it without risking breaking something else. It is a harmless "feature", is
it not?

Rather a bug I still think. It was really puzzling me when I was starting
learning about projections. GRASS was my first GIS.

I was wondering then "why the hack the '(zone 0)' information when my
projection is, say 'stere'? Well, it's got to be I again don't know another
something". And as it was impossible to sort it out (logically), the conclussion was "I'm stupid. I better wait until I understand it someday."

Please spare this frustration to new GRASS users. When you are a beginner
and don't SO MANY things, another one is the one too much. Besides, it looks unproffessional (however unprofessional it was of me not to know that 'zone (number)' doesn't apply to any projection besides UTM ;).

BTW r.info - there is an information 'Number of Categories' in it's output.
While it should be 'Max category' actually. Example - you have following
categories in your raster: 1, 2, 40. Is the 'Number of categories' 40? No it
isn't, right? But that's what r.info says. Another frustration for
disoriented beginner.

I agree these shouldn't be touched in 6.0, but how about fixing them in 6.1?

Maciek

18

On Jul 3, 2005, at 4:19 AM, Hamish wrote:

#2544 SHLIB_LD for darwin (Mac OS X) needs to be fixed.
#3104 & 3105 Missing $(TIFFLIBPATH) in a couple makefiles (OGSF and
  NVIZ).

(left to someone who knows about such things..)

Maybe Michael?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

19

On Jul 3, 2005, at 4:19 AM, Hamish wrote:

Those are the main ones, that I think should get into a 6.0.1
release, and 6.1 of course. There are a few others I haven't checked
recently, or that have been quietly fixed or fixed themselves (how
can I close them?).

Add a reply or comment to the bug in the bug tracker of the bug that is
finished saying so, and cc grass5.

I've added comments to some in the past. I guess the problem there is that they don't seem to be sent to anyone, even the list (unless you add a cc). And replies are sent to me (the originator of the bug), or so the form says so I didn't bother to try.

I think there was a suggestion on the list once to send email direct to some address instead of using the web forms. Is that possible? If so, maybe some explanation about that on the bug report page?

At least for closing them, Maciek's 'volunteer' request to cc him sounds good (I just tried one).

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

20

On Sun, 3 Jul 2005, Maciek Sieczka wrote:

BTW - will there be 5.4.1? I know you are not in charge but could the one please answer?

Emm - as far as I can remember I am the release co-ordinator for 5.4.x. Recently I did a few more bugfixes on it. However there are still more things to merge between 5.4 release branch and 5.5 HEAD before it will bre ready and unfortunately I only have a little time to devote to it at present.
I'd like to try and fix the 6.x d.where -l bug first and then get back to 5.4.1

Paul