[GRASS-dev] d.m/d.gis mysteries..

[Maciej Sieczka]

Moritz Lennert wrote:
> Maciej,
> 
> In no way was what I wrote intended as a personal attack. If this is how
> it came across, I sincerely apologize.

OK, no problem.

> Up to now you are the only one who has raised this issue as a problem.
> Maybe this is because you are the only one conscious of it and many people
> are actually misusing gis.m thinking that they get a precision which they
> are actually not getting. Maybe it is because those who need such level of
> precision have the habit of going through g.region. Or maybe it is because
> those who need it are working on the command line and so don't use gis.m.
> I don't know the reasons...

Who raises a given issue is not a criterion. The only criterion is
wheter the issue is there or not. Since I have started using GRASS I
have found many bugs, including numerous long-standing, which nobody
has raised before. Also other folks have found bugs which I was never
aware of.

> So, the first question to be asked is: does everyone agree that this is a
> bug ?

We don't need to vote on this. There is a functionality which doesn't
do what it designed for, and this results in corrupted region settings.
This is a bug. I'm not going to debate on whether 1=1 anymore.

> If yes, then I agree completely that this needs to be fixed. But as
> always developer time is limited...and there are other bugs in GRASS which
> those who have the skills find more important.
> 
> The current situation definitely is not easy as we are in a transition
> phase between gui's with a very important step being gis.m, but at the
> same time this is already poised to be replaced. This makes the issue more
> difficult, as Michael has to deal with three different GUIs at the same
> time, and it is not always clear which of these should be the priority.
> 
> I am willing to help you try to identify whether there are possible
> solutions to the issue in gis.m,

Thanks for the offer, but you can only help someone able to fix the bug.

> but definitely not before next week and
> as Markus wants to release 6.2 tomorrow, I am afraid it will have to wait
> for a bug fix release.

I didn't even try to say that the 6.2 release should be hold off till
the bug is fixed, because I know this is not realistic. There are many
bugs not fixed and this doens't make me trying to hold of the release
either. Since I remember, GRASS has been always released with known
bugs not fixed, and GRASS developers convinced me that it is inevitable
- too little people working on the project compared to size of the
codebase. Since I can't fix any bug myself I don't even dare to tell
others what to do anymore. But this doesn't mean I should not inform
others about bugs I found, wishing that soemone can fix it. I'm not
going to pretend there is no bug.

There have been many bugs squashed in gis.m recently by Michael.
Encouraged by that, until this another bug has cropped out, I've been
thinking gis.m will really become stable soon and d.m can dropped
altogether. Now that this bug is known and there is no cure for it,
until the bug is fixed, d.m should remain at least as an alternative.
I, personally, would even prefer d.m as the default GUI back, due to
this particular bug - the high risk of corrupted region settings is too
serious for me to bear it. But I'm not going to insist or argue on
that, I'll settle for what others decide for. At least don't remove d.m
until the bug is fixed.

Maciek