<div dir="ltr"><div><br>On Wed, Oct 7, 2015 at 11:50 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Wed, Oct 7, 2015 at 3:47 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:<br>> > On Wed, Oct 7, 2015 at 4:19 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>> > Why it is a warning and not a message?<br>><br>> Because due to the bug it doesn't work.<br>> once the bug is fixed, we can "downgrade" to a message or even remove it.<br>><br>> > Does the message really explain to<br>> > the user what does it mean or what can possible go wrong. I'm not following<br>> > the discussion,<br>><br>> Maybe you should :-)<br><br></div>So it seems :)<br><div><br>> > so I don't know what the issue is, but from the diff it<br>> > looks like user must open the source code to see the comments around and<br>> > read the manual to understand the consequences.<br>><br>> Not really. And reading the manual is a good idea.<br><br>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.<br><br>In general, messages, especially warnings should not only state the, usually low level, issue, but also what to do about it.<br><br>> > There is also a typo with Input/Output.<br>> ><br>> >> and r66427 (relbr70).<br>> ><br>> > Perhaps premature backport.<br>><br>> Please be more specific, I cannot follow.<br><br></div><div>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:<br><br> G_warning(_("Input vector map <%s> is 3D"), opt.from->answer);<br>G_warning(_("Input vector map <%s> is 3D"), opt.to->answer);<br></div><div><br></div><div>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.<br><br>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).<br><br></div><div>Vaclav<br></div><div><br><a href="https://trac.osgeo.org/grass/changeset/66426">https://trac.osgeo.org/grass/changeset/66426</a><br><a href="https://trac.osgeo.org/grass/changeset/66427">https://trac.osgeo.org/grass/changeset/66427</a><br></div></div>