[GRASS-user] Query vector type has problems

[Vaclav Petras]

On Wed, Oct 7, 2015 at 11:50 AM, Markus Neteler <neteler at osgeo.org> wrote:
>
> On Wed, Oct 7, 2015 at 3:47 PM, Vaclav Petras <wenzeslaus at gmail.com>
wrote:
> > On Wed, Oct 7, 2015 at 4:19 AM, Markus Neteler <neteler at osgeo.org>
wrote:
> > Why it is a warning and not a message?
>
> Because due to the bug it doesn't work.
> once the bug is fixed, we can "downgrade" to a message or even remove it.
>
> > Does the message really explain to
> > the user what does it mean or what can possible go wrong. I'm not
following
> > the discussion,
>
> Maybe you should :-)

So it seems :)

> > so I don't know what the issue is, but from the diff it
> > looks like user must open the source code to see the comments around and
> > read the manual to understand the consequences.
>
> Not really. And reading the manual is a good idea.

My point is that from the message you don't know why it is important and
why it is a warning without reading the manual. Of course, users should
read the manual, but only advanced users do. The message could say "Please
refer to the manual for explanation" or something like that.

In general, messages, especially warnings should not only state the,
usually low level, issue, but also what to do about it.

> > There is also a typo with Input/Output.
> >
> >> and r66427 (relbr70).
> >
> > Perhaps premature backport.
>
> Please be more specific, I cannot follow.

I'm usually against these immediate backports. I know they are tempting.
However, here again, even when I leave aside the discussion above, there is
a typo:

G_warning(_("Input vector map <%s> is 3D"), opt.from->answer);
G_warning(_("Input vector map <%s> is 3D"), opt.to->answer);

The second should say "Output...". Now you have to change that in both
branches. And that's the problem. It would be better to refine it first in
trunk and then backport it all together.

This happens quite often - list of commits containing these two pairs of
commits (change, its immediate backport, fix of change, its immediate
backport). Sure we make mistakes, but this is unnecessary clutter.
Moreover, then we claim how many commits was done in release branch between
releases, but in fact significant portion of it are just these fixes of
fixes which should have been backported after the code matured in trunk (my
claim is that even simple code needs maturation).

Vaclav

https://trac.osgeo.org/grass/changeset/66426
https://trac.osgeo.org/grass/changeset/66427
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20151007/70bc3b70/attachment.html>