On Fri, Dec 19, 2008 at 1:03 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2008/12/19 Martin Landa <landa.martin@gmail.com>:
>>> Call it nviz2?
>>
>> nviz -> TCL/TK GUI
>> nviz2 -> cmd line based module
>>
>> seems to be confusing for me...
>>
>> I vote for d.3d.
>
> or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...considering d.nviz which should be also renamed (in 7.0)
6.4
d.nviz
nviz_cmd -> d.3d7.0
d.nviz -> d.3d.fly
nviz_cmd -> d.3d
This is a good compromise for me.
Markus
Hi,
2008/12/19 Markus Neteler <neteler@osgeo.org>:
>>> Call it nviz2?
>>
>> nviz -> TCL/TK GUI
>> nviz2 -> cmd line based module
>>
>> seems to be confusing for me...
>>
>> I vote for d.3d.
>
> or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...considering d.nviz which should be also renamed (in 7.0)
6.4
d.nviz
nviz_cmd -> d.3d7.0
d.nviz -> d.3d.fly
nviz_cmd -> d.3dThis is a good compromise for me.
Question:
in the case of renaming to d.3d should be also
visualization/nviz2/cmd/
moved to
display/3.3d
I guess no.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Fri, 19 Dec 2008, Markus Neteler wrote:
On Fri, Dec 19, 2008 at 1:03 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2008/12/19 Martin Landa <landa.martin@gmail.com>:
Call it nviz2?
nviz -> TCL/TK GUI
nviz2 -> cmd line based moduleseems to be confusing for me...
I vote for d.3d.
or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...
considering d.nviz which should be also renamed (in 7.0)
6.4
d.nviz
nviz_cmd -> d.3d7.0
d.nviz -> d.3d.fly
nviz_cmd -> d.3dThis is a good compromise for me.
I don't like last minute changes so I think it is fine too. Not sure if d.nviz is present in 6.4? But that's irrelevant at this point.
Are we ready to go with the tagging 6.4.0RC1 then? A new branch isn't absolutely necessary at the minute - but as I see it there's no reason not to do it now either if it's not too much extra work.
Paul
On Fri, Dec 19, 2008 at 4:25 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:
On Fri, 19 Dec 2008, Markus Neteler wrote:
On Fri, Dec 19, 2008 at 1:03 PM, Martin Landa <landa.martin@gmail.com>
wrote:Hi,
2008/12/19 Martin Landa <landa.martin@gmail.com>:
Call it nviz2?
nviz -> TCL/TK GUI
nviz2 -> cmd line based moduleseems to be confusing for me...
I vote for d.3d.
or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...
considering d.nviz which should be also renamed (in 7.0)
6.4
d.nviz
nviz_cmd -> d.3d7.0
d.nviz -> d.3d.fly
nviz_cmd -> d.3dThis is a good compromise for me.
I don't like last minute changes so I think it is fine too. Not sure if
d.nviz is present in 6.4? But that's irrelevant at this point.
Sure it is there:
[neteler@markus grass64]$ ls display/d.nviz/
description.html local.h main.c Makefile
Are we ready to go with the tagging 6.4.0RC1 then? A new branch isn't
absolutely necessary at the minute - but as I see it there's no reason not
to do it now either if it's not too much extra work.
I think that a branch is commonly done in the GRASS
project, so we should continue. And with SVN merging
is easier (and G7 moves away so that at least I rarely
backport things).
Markus
Hi,
2008/12/19 Markus Neteler <neteler@osgeo.org>:
Call it nviz2?
nviz -> TCL/TK GUI
nviz2 -> cmd line based moduleseems to be confusing for me...
I vote for d.3d.
or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...
considering d.nviz which should be also renamed (in 7.0)
6.4
d.nviz
nviz_cmd -> d.3d7.0
d.nviz -> d.3d.fly
nviz_cmd -> d.3dThis is a good compromise for me.
I don't like last minute changes so I think it is fine too. Not sure if
d.nviz is present in 6.4? But that's irrelevant at this point.Sure it is there:
[neteler@markus grass64]$ ls display/d.nviz/
description.html local.h main.c Makefile
well, after some discussion with Markus I would suggest creating new
group of modules
nviz
in GRASS6:
nviz_cmd becomes nviz.cmd
in GRASS7:
nviz_cmd becomes nviz.cmd
d.nviz becomes nviz.fly
Are we ready to go with the tagging 6.4.0RC1 then? A new branch isn't
absolutely necessary at the minute - but as I see it there's no reason not
to do it now either if it's not too much extra work.I think that a branch is commonly done in the GRASS
project, so we should continue. And with SVN merging
is easier (and G7 moves away so that at least I rarely
backport things).
+1 for branch
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Fri, 19 Dec 2008, Martin Landa wrote:
Hi,
2008/12/19 Markus Neteler <neteler@osgeo.org>:
Call it nviz2?
nviz -> TCL/TK GUI
nviz2 -> cmd line based moduleseems to be confusing for me...
I vote for d.3d.
or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...
considering d.nviz which should be also renamed (in 7.0)
6.4
d.nviz
nviz_cmd -> d.3d7.0
d.nviz -> d.3d.fly
nviz_cmd -> d.3dThis is a good compromise for me.
I don't like last minute changes so I think it is fine too. Not sure if
d.nviz is present in 6.4? But that's irrelevant at this point.Sure it is there:
[neteler@markus grass64]$ ls display/d.nviz/
description.html local.h main.c Makefile
Ah I thought it was a script. No wonder I couldn't find it.
well, after some discussion with Markus I would suggest creating new
group of modulesnviz
in GRASS6:
nviz_cmd becomes nviz.cmd
Well as I said above I feel it is a bad idea to make any last minute changes now if we're intending to tag 6.4.0RC1 imminently, so I'd vote for keeping everything as-is for 6.4 now.
in GRASS7:
nviz_cmd becomes nviz.cmd
d.nviz becomes nviz.fly
My comments before about the name nviz being inherently meaningless still stand here. Yes it's instantly recognisable to GRASS users as the 3-D visualisation command, similarly to r.in.gdal being instantly recognisable as an import command. But the reasons Markus gave for renaming r.in.gdal to r.import (which I eventually came round to agreeing with) stand here also for renaming nviz_cmd to something more meaningful. I think we need to sit back and look at the functionality and the GUI integration and come up with a nice meaningful name for 7.x.
Are we ready to go with the tagging 6.4.0RC1 then? A new branch isn't
absolutely necessary at the minute - but as I see it there's no reason not
to do it now either if it's not too much extra work.I think that a branch is commonly done in the GRASS
project, so we should continue. And with SVN merging
is easier (and G7 moves away so that at least I rarely
backport things).
Yes - I mean if a branch is not created now it would be in the next week or two. It just might save some merging work not to create it until it is really needed. But there is no harm in creating it now.
Paul
On Fri, Dec 19, 2008 at 6:37 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:
...
Yes - I mean if a branch is not created now it would be in the next week or
two. It just might save some merging work not to create it until it is
really needed. But there is no harm in creating it now.
It is needed for the QGIS people. They won't use a moving target.
In the past, they used the branch and due to that they didn't even
had to wait for releases but just took the current branch.
Additionally, basically Martin, Hamish and me are suffering from
backporting 
If those guys are ok...
Markus
Hi,
2008/12/19 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
[...]
group of modules
nviz
in GRASS6:
nviz_cmd becomes nviz.cmd
Well as I said above I feel it is a bad idea to make any last minute changes
now if we're intending to tag 6.4.0RC1 imminently, so I'd vote for keeping
everything as-is for 6.4 now.
OK, on the other side, I don't see any reason why to postpone the decision.
in GRASS7:
nviz_cmd becomes nviz.cmd
d.nviz becomes nviz.flyMy comments before about the name nviz being inherently meaningless still
stand here. Yes it's instantly recognisable to GRASS users as the 3-D
visualisation command, similarly to r.in.gdal being instantly recognisable
as an import command. But the reasons Markus gave for renaming r.in.gdal to
r.import (which I eventually came round to agreeing with) stand here also
for renaming nviz_cmd to something more meaningful. I think we need to sit
back and look at the functionality and the GUI integration and come up with
a nice meaningful name for 7.x.
Sorry for possible misunderstanding, would be option to name a new
group of modules as '3d' instead of 'nviz'. In the result:
3d.cmd
3d.fly
?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
Hi,
2008/12/19 Martin Landa <landa.martin@gmail.com>:
[...]
Sorry for possible misunderstanding, would be option to name a new
group of modules as '3d' instead of 'nviz'. In the result:3d.cmd
3d.fly
or
d3.*
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Fri, 19 Dec 2008, Martin Landa wrote:
Hi,
2008/12/19 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
[...]
group of modules
nviz
in GRASS6:
nviz_cmd becomes nviz.cmd
Well as I said above I feel it is a bad idea to make any last minute changes
now if we're intending to tag 6.4.0RC1 imminently, so I'd vote for keeping
everything as-is for 6.4 now.OK, on the other side, I don't see any reason why to postpone the decision.
Just so we have time to discuss it all properly. I get the impression Markus wants to create the release branch and tag 6.4.0RC1 this evening, and when creating a new group of modules under pressure like this I worry that we might miss something obvious - when giving it a few days and allowing other developers to read and comment might come up with some clever insight that we have missed.
So I don't mean to hold up creating the release branch with this discussion (sorry if it is doing that), nor to try to force a decision on new module names. But I feel we can give this a little while to come to a consensus on the list, *and* get 6.4.0RC1 tagged right now?
Paul
On Fri, Dec 19, 2008 at 7:32 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:
On Fri, 19 Dec 2008, Martin Landa wrote:
OK, on the other side, I don't see any reason why to postpone the
decision.Just so we have time to discuss it all properly.
Well, the RC1 was planned for end of October.
I get the impression Markus
wants to create the release branch and tag 6.4.0RC1 this evening, and when
creating a new group of modules under pressure like this I worry that we
might miss something obvious - when giving it a few days and allowing other
developers to read and comment might come up with some clever insight that
we have missed.
I don't see pressure but observe a very long (me slowy annoying)
discussion.
Apparently many GRASS developers don't care if thousand of QGIS
users get an outdated GRASS shipped (Windows, Mac). I do care
and don't support this.
So I don't mean to hold up creating the release branch with this discussion
(sorry if it is doing that), nor to try to force a decision on new module
names. But I feel we can give this a little while to come to a consensus on
the list, *and* get 6.4.0RC1 tagged right now?
Why a little while? The discussion is stuck. Things have been said
over and over again, many developers and power users remain
silent.
If even in 2008 GFOSS software projects are unable to slightly sync
their releases, it is painful for the user communities.
Well, no idea.
Markus
Hi,
2008/12/19 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
OK, on the other side, I don't see any reason why to postpone the
decision.Just so we have time to discuss it all properly. I get the impression Markus
wants to create the release branch and tag 6.4.0RC1 this evening, and when
creating a new group of modules under pressure like this I worry that we
might miss something obvious - when giving it a few days and allowing other
developers to read and comment might come up with some clever insight that
we have missed.
yes, Markus is going to create new branch this evening.
Sorry, but I am not sure what I can say more about this topic. Anyway,
I will follow the discussion and I hope at the end the new names/group
will be chosen (I just wonder *when*).
I don't see this point as blocking for creating release branch.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Friday 19 December 2008, Markus Neteler wrote:
On Fri, Dec 19, 2008 at 7:32 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:
> On Fri, 19 Dec 2008, Martin Landa wrote:
>> OK, on the other side, I don't see any reason why to postpone the
>> decision.
>
> Just so we have time to discuss it all properly.Well, the RC1 was planned for end of October.
> I get the impression Markus
> wants to create the release branch and tag 6.4.0RC1 this evening, and
> when creating a new group of modules under pressure like this I worry
> that we might miss something obvious - when giving it a few days and
> allowing other developers to read and comment might come up with some
> clever insight that we have missed.I don't see pressure but observe a very long (me slowy annoying)
discussion.Apparently many GRASS developers don't care if thousand of QGIS
users get an outdated GRASS shipped (Windows, Mac). I do care
and don't support this.> So I don't mean to hold up creating the release branch with this
> discussion (sorry if it is doing that), nor to try to force a decision on
> new module names. But I feel we can give this a little while to come to a
> consensus on the list, *and* get 6.4.0RC1 tagged right now?Why a little while? The discussion is stuck. Things have been said
over and over again, many developers and power users remain
silent.
If even in 2008 GFOSS software projects are unable to slightly sync
their releases, it is painful for the user communities.Well, no idea.
Markus
Markus and others:
I have been mostly lurking on this discussion. Are there any reasons why we
can't get the RC1 out today, besides the diverging comments? Do the module
names really matter in an RC? I think that it should be a top priority to get
*something* based on 6.4 into QGIS 1.0.
Let me know if there is something I can do to make this happen.
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Fri, 19 Dec 2008, Martin Landa wrote:
Hi,
2008/12/19 Paul Kelly <paul-grass@stjohnspoint.co.uk>:
OK, on the other side, I don't see any reason why to postpone the
decision.Just so we have time to discuss it all properly. I get the impression Markus
wants to create the release branch and tag 6.4.0RC1 this evening, and when
creating a new group of modules under pressure like this I worry that we
might miss something obvious - when giving it a few days and allowing other
developers to read and comment might come up with some clever insight that
we have missed.yes, Markus is going to create new branch this evening.
Sorry, but I am not sure what I can say more about this topic. Anyway,
I will follow the discussion and I hope at the end the new names/group
will be chosen (I just wonder *when*).I don't see this point as blocking for creating release branch.
Me neither. Please go ahead (Markus) and do it - you have my full support. Sorry if my minor comments have been misinterpreted as objections (especially about the release branch). Do it do it do it...
Happy Christmas
Paul
Hi,
2008/12/19 Dylan Beaudette <debeaudette@ucdavis.edu>:
[...]
I have been mostly lurking on this discussion. Are there any reasons why we
can't get the RC1 out today, besides the diverging comments? Do the module
names really matter in an RC? I think that it should be a top priority to get
*something* based on 6.4 into QGIS 1.0.
RC1 has higher priority at this point. On the other side, if we leave
nviz_cmd we will remain with this name in grass 6.x. It was main
reason why I have tried to get this issue resolved before RC1.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
Hi,
2008/12/19 Dylan Beaudette <debeaudette@ucdavis.edu>:
[...]
I have been mostly lurking on this discussion. Are there any reasons why we
can't get the RC1 out today, besides the diverging comments? Do the module
names really matter in an RC? I think that it should be a top priority to get
*something* based on 6.4 into QGIS 1.0.
RC1 has higher priority at this point. On the other side, if we leave
nviz_cmd we will remain with this name in grass 6.x. It was main
reason why I have tried to get this issue resolved before RC1.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
Martin Landa wrote:
>> in GRASS7:
>>
>> nviz_cmd becomes nviz.cmd
>> d.nviz becomes nviz.fly
>
> My comments before about the name nviz being inherently meaningless still
> stand here. Yes it's instantly recognisable to GRASS users as the 3-D
> visualisation command, similarly to r.in.gdal being instantly recognisable
> as an import command. But the reasons Markus gave for renaming r.in.gdal to
> r.import (which I eventually came round to agreeing with) stand here also
> for renaming nviz_cmd to something more meaningful. I think we need to sit
> back and look at the functionality and the GUI integration and come up with
> a nice meaningful name for 7.x.Sorry for possible misunderstanding, would be option to name a new
group of modules as '3d' instead of 'nviz'. In the result:3d.cmd
3d.fly
viz.*? vis.*?
OTOH, it may be better to just use the m.* grouping for programs which
use GRASS but don't fit into any overall structure.
--
Glynn Clements <glynn@gclements.plus.com>