[GRASS5] The status of 5.0

[Helena]

> On the bugtracker:
> There are many bugs in there. We need people to
> evalutate them, reproduce them, fix or delay them.

I tried to go through the bug tracker and while there are some real bugs
there
only very few seem to be release critical.
Most of them seem more like lack of capabilities (974,975,973,914, part of
912, .....
or annoyancies which have a way around it (e.g. my #970,)
So it would be really useful  if release critical bugs could have
their own priority, I have identified maybe 2-3

Some problems listed just need better explanation in the
documentation/instructions
I am looking into INSTALL and small modifications may help -
e.g. there is a sentence ....some modules won't be compiled" right at the
beginning
of the document.Adding "(for example PostgresSQL or fftw, see section on
CONFIGURE OPTIONS)"
may help reduce number of people complaining about Postgres giving errors
because most people do not read it far enough to learn about it.
(everybody here who has compiled GRASS was puzzled by Postgres error as many
people do not even know what it is)

> I guess PostgreSQL isn't standard enough yet, configure couldn't find
   > /usr/include/postgresql by itself for libpq-fe.h (I think that's what it

   > looks for).

   configure deliberately does *not* attempt to guess directories. Any
   include/library directories which aren't in the compiler's/linker's
   default path have to be explicitly specified using --with-*-includes
   and --with-*-libs.

-------------------------------------------------------------------------
concrete comments, suggestions for removals from the list

905
really is not a bug, to me putting a space between + 18 actually makes sense
what do we do with "bugs" like this - keep them there with low priority
(there is plenty of them there) or vote whether they should be removed?

912 r.mapcalc
was anybody able to reproduce that bug?
    I tried all kinds of combinations on various types of files
    and did not get "no result" problem. Markus, wasn't there something wrong

    with your file?

Both of the following "problems" are issues related to the question whether
anybody should use r.mapcalc without reading the man page and how much of
instructions should be put into the messages given by the program -
Markus are you suggesting that if r.mapcalc finds that it has a map with
NULLs
it should give a warning? Similarly should there be a warning for division of
two INT maps?
(that should reduce number of confused people, but on the other hand people
should really read manual before using r.mapcalc)

- r.mapcalc *silently* does not operate on NULL values (there should be
      a warning)
- does not print a message about the file type (INT,FCELL) when doing
      a calculation (e.g. when dividing two INT maps, the result is INT.
      but many users may not realize this and don't know that they have to
      multiply with 1.0 to receive a FCELL)

913 looks like the users problem

897 r.slope.aspect is indeed a GRASS4* story when 0 was no-data and rasters
were mostly classes.
Labeling 360 classes as it is there now does not really make much sense so to

make it meaningful it would require to create maybe 12 ranges and label those
or
skip labeling altogether. But this is more like a wish than a critical bug.
r.param.scale is probably similar case

895 - more likely a wish? lack of capability?

889 same as 836 - nvizOsx has a note that it may be closed but it is still
there

888 is not a bug - should be removed

878 not a bug

877 not abug

873 should be given low priority

870 seems to be resolved

868 not release critical?

858 does Radim's answer solve the problem at vector support GRASS5.0 level?
or is this release critical Markus?

855 Any news about v.trim? Release critical?

853 sounds like release critical?

756 can be removed - I was never able to reproduce it and never got
confirmation
about the problem from the submitter

256 s.surf.krig - kriging is much better served by linking with geostats
packages
as you need lots of additional tools to make it really useful - GSTATS and
R-stats
would be much better  for that. Unless somebody wants to undertake major
geostatistics developments fully integrated with GRASS (inclding s.sv and
other tools)
I suggest retiring it and rather work on improvements and education for
R-stats bridge and GSTATS link

251 - isn't this listed as an issue for GRASS5.1 milestone?



>
>
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature