Rich,
On Sun, Feb 18, 2001 at 06:46:54PM -0800, Rich Shepard wrote:
Markus,
I'm not posting this to the list for several very good reasons. I want to
discuss the progress and status of GRASS-5 with you, and not have you feel
that I'm putting you on the spot or embarrassing you in front of the
development team. But, I have some very serious concerns, and I would like
to offer some suggestions to resolve them.
Well, I don't mind to discuss below in public. So I am putting myself into
the spot now. I would like to hear other opinions if we can continue as
we do or if the GRASS development model needs to be changed/modified.
Luckily there are software engineers in the team who have much experience
from other projects.
First, GRASS-5 has become a fun toy for folks to hack on; fiddling with
the program is the purpose. However, there are many folks like me who need
it as a tool, a means to an end. And we're not being given equal
consideration. Here is what I think is the problem: the use of CVS.
I know your opinion on GRASS development. If you think that we all
just try to destroy GRASS, you are wrong. If you think we don't use
GRASS for our (payed) work, this is wrong as well.
If a project is being developed in one shop (such as something you and
your students are working on together), then CVS is a good way to maintain
the code in one place while letting everyone work on his or her own piece.
However, there is still one, overall program manager who makes the
decisions. And, no code is placed in the working system until it has been
thoroughly tested to ensure that it doesn't break something else. For an
international project such as GRASS, CVS is not the right tool. My
experience this weekend with the beta-11.2 is a perfect example. Not all the
pieces were there, but some were in 10.
Please note: Beta means beta. And CVS means: Continuing development, so
it might become instable from time to time.
My recommendation is this: take all the code out of the CVS system and
maintain it yourself.
Simple question: Will you pay me for this? I have maintained GRASS 4.2.1
for many month without CVS. Development was *much* slower and *much* more
(stupid) work for me. Maintaining 1.5 million lines of code manually is
not the best way. CVS was invented to maintain large projects.
No new code gets added to a working version until it's
been tested very hard.
Well, where are the testers? Could you provide testers? If you have,
please involve them as we need more. I definitly agree that GRASS
still needs more testers.
You may decide to assign sub-managers to coordinate
major chunks (e.g., testing on different platforms, compilation/install,
data translation, vector modules, and so on), but this anarchy is hurting
the whole GRASS image. You may not see this from your position in academia
and as project manager for the 5.0 release, but we see it out here in user
land. I'm not insulting you or suggesting that you are not qualified or
capable. At least, I do not intend to.
Probably I am not qualified. However, the overall acceptance of GRASS
is much better than in past. Even if you disagree, functionality is
getting back into GRASS. Simply try beta1..6 to see of what their quality
was. We are not forcing you to use beta11.
I suggest that rather than working on a Mac or Win port simultaneously
with everything else, you direct all efforts to fixing the existing bugs for
linux. solaris and, perhaps, irix. Make sure that all files are there to be
properly installed and run. Ensure that the standard permissions are used so
I can define a group of users and have them all work on the same mapset (but
not simultaneously).
Please provide some money to do this... I am working hard (60..70 hours per
week). Note that there is the "Real life thing (tm)", GRASS is not what
I am payed for here.
David tells me that v.in.mif got left out of beta-11 although it was in
10.
He will have his reasons to comment for beta11. A few minutes ago he
has been activating it again in CVS (you can watch that in CVS-commit
mailing list).
He just sent it to me. My installation didn't make a
/usr/local/grass5/dev/ directory and make the fifos, or even put in the
create_fifos.sh script. No, I have a shell script called
/usr/local/grass5/dev, and it doesn't do anything useful.
Of course such bugs are annoying. I don't enjoy them, I don't try to
destroy GRASS. However, it's impossible to supervised every change.
There have been > 3000 changes last year.
This is what I mean about a broken product -- even for a beta version
that's almost ready for release. IMO, it's because anyone and everyone can
commit new (or changed) code to the CVS tree and they haven't bothered to
test it completely. Candidly, we should never see a Beta-11.2 unless we're
Microsoft. With centralized control, we would have had a stable 5.0
production relase after only a few beta versions.
It would be interesting if you could provide support. What I get from you
are always complaints about me, the development team, the code structure
etc. Baylor doesn't commit anything to GRASS 5 (they even have CVS access as
they never asked). Perhaps you or your company can provide a part/full time
programmer to help us. That would be a really good thing.
Please, Markus, take control back. Last year, Bruce told me that the best
estimate is 40,000-45,000 GRASS users world-wide. That's too large a user
base to get upset. Take control away from those who apparently either get
paid to hack on GRASS or haven't a life outside of GRASS hacking. The
purpose of the development process is to produce a working version for the
end user. Quickly and efficiently. Then, other platforms and other tweaks or
features can be added (say, in 6 months) after the value of the new request
has been carefully considered.
Again, we need:
- money
- testers
- programmers
Can you help us here?
Example for current hacks: The XDRIVER update to sockets will (partly
already does) allow:
- speed up (finished)
- map scale on window's top
- automated redraw after resizing
- close monitor by clicking (finished)
- fixed backing store problem with overlapping windows (finished)
- real platform independence
Shall we really miss this? Implementing such complex issues will
take some days. However, why not.
Another example: Huidae Cho has been implementing my "reclass wish":
In all past GRASS versions you could delete the parent map of
a reclassed map. In that case the reclassed map is unusable as it
is simply a table. So such operations were dangerous. Now this
cannot happen any more. At least from my point of view a good improvement.
Another example: The non-intuitive control field in NVIZ has got a compass
now. This makes view control intuitive. Why miss that?
Another example: d.zoom auto-redraws maps after zooming. We could remove
the d.rast.zoom, d.vect.zoom as d.zoom does everything now. I like that.
Another example: I have added s.in.dbf to read in dBase tables. This doesn't
break anything else.
Another example: The HTMLMAP driver was fixed to produce maps being accepted
by MS-IE5 explorer. As IE5 doesn't meet the W3 recommendations it was
necessary. The new GRASS mirrors map is a result of that:
http://www.geog.uni-hannover.de/grass/
(btw: Baylor is tiring slow with their web updates. They still have the old
map).
See more improvements here:
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/NEWS.html
The improvements have been done because of our experience, users
recommendations, bugs being detected, users convenience etc.
Is there really any improvement which bothers the user? Please tell me about
that, then we can revert it (thanks to CVS to provide the revert function).
What I don't understand, Rich: Why don't you use GRASS 4.x? You
like 4.x, you think it's error free (it's not) etc.
Why do you take the hassle to use GRASS 5? This I simply don't
understand.
Thanks, and please feel free to continue the dialog,
It seems we are going in circles as we have a different opinions
on GRASS development. My wish to you is: Please send more than
comments: donate money, donate programmers and testers.
Regards
Markus Neteler
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'