<html><head></head><body>Markus,<br>
<br>
I had a quick look at the release rules that you identified. One thing that
stood out (from my experience) is that in the pre-release testing and fixes
only critical bugs should be addressed. These are bugs that stop the system,
or major parts of the system from functioning correctly. At that point the
updates should be limited to only those fixes - not to feature enhancements.
Someone, in this case you or your delegate(s), should be given the responsibility
of identifying the critical bugs, verifying the fixes and applying the updates
to the source tree. <br>
<br>
Overall, I think the development model being used is a good one. There were
a huge number of improvements made over the last few months. In an open
development model it is obvious that user needs and wishes can be quickly
met. As we've seen with some of the key changes in GRASS some significant
changes can be made in a short time. This is a huge testament to the developers.<br>
<br>
As I said above, the only thing that I (try to) do differently in my development
projects is to stop feature creep once we've gone into pre-release testing.
This usually upsets some people, but I think that in the end it results in
a better product. This is easier in the more structured development groups
that I have usually worked with, but I think can be applied here as well.<br>
<br>
Rich mentioned the Linux development model, but I don't think that he described
it completely enough. As he said, Linus controlled the changes to the kernal,
but all of the other Linux "system" changes were made by a much larger circle
and these were then packaged together into what we think of as Linux (all
of the different flavors of Linux). The kernel development is (now) split
into two cycles. Once a stable kernel is reached, it is used for distributions,
while additional development continues on for the development kernel. Other
packages continue on in development mode - but have to work with the stable
kernel. Using this model, maybe some of the "key" pieces of grass should
each be updated by only one person - who would have to maintain a stable
version of that piece. You (Markus) would have to decide who that person
was for each piece. While this may sound limiting, if it was applied in
the pre-release/bug-fixing stage it might be manageable. Hopefully, it won't
curb the enthusiasm of the developers or overtax the people maintaining the
"key" code.<br>
<br>
(Those of us who have used Linux since the early/mid 90's know that it was
not a smooth process in the Linux world. Hindsight may have smoothed those
curves, but it took a long time to get from the experimental stage - I think
it was release .95 I first tried - to the current 2.4 release. And it took
a lot of work. Early releases of Linux did not usually work as well as grass
does today, and since version 5 is the first open source version of grass,
that says a lot about the work you (Markus) have done to organize the development
process.) <br>
<br>
To date, I have been routing my changes through other developers and have
had extremely good response. Especially with core functionality, I would
rather have someone reject my suggestions than break something that works
for other users. I hope that others feel the same way. <br>
<br>
I am very impressed with the improvements in grass over the last year or
so (on Linux and on Windows/Cygwon). A year ago I factored grass into my
business plan as a future possibility. Today, I consider grass to be a viable
alternative to commercial GIS. While I'm not using it on current projects,
I will consider it as an option on future projects. I also plan on contributing
when I can.<br>
<br>
Markus: I'll take a look around the Web and see if I can find information
on how some of the other open source initiatives manage the testing/release
cycle. There should be existing models that can be applied here to make
a good system better. If I find anything of use I'll send a link or comments
to you.<br>
<br>
Also, I don't think that Rich should feel he was flamed. Although there
were a few defensive comments, I thinks that most of the points raised were
valid and most responses were on the mark. I expect that everyone wants to
improve the situation. As a newcomer to the grass development group, I hope
that I can help. As an experienced developer, I know that you can expect
to hear negative comments quicker and louder than positive comments. It's
when people stop commenting that you should really get worried.<br>
<br>
<br>
Adding my .02 CAN,<br>
<br>
Malcolm<br>
<br>
<br>
<br>
<br>
Markus Neteler wrote:<br>
<blockquote type="cite" cite="mid:20010219191422.M10546@hgeo02.geog.uni-hannover.de"><pre wrap="">On Mon, Feb 19, 2001 at 08:58:00AM -0800, Rich Shepard wrote:<br>[...]<br></pre>
<blockquote type="cite"><pre wrap="">What I intended to be a constructive dialog (dia == 2) has<br>become the general ego-generated flame. I'm both disappointed and disgusted.<br></pre></blockquote>
<pre wrap=""><!----><br>I have been writing personally to Rich to calm down this discussion.<br>In fact I should be more careful in future to cc to the grass5<br>list, means to get the o.k. from the opposite side of the email line.<br>The reasons for me were the "anarchy" Rich sees in current development model<br>which sounded rather offending to me. <br><br>Well...<br><br>My recent suggestion to Rich is to prepare a *detailed* list of things to <br>be improved in GRASS development model. Rich is right that the last<br>two releases weren't lucky. Therefore I have prepared a step-by-step<br>"ruleset":<br><br><a class="moz-txt-link-freetext" href="http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/documents/release_rules.txt">http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/documents/release_rules.txt</a><br><br>which still needs to be improved. Like that stupid problems shouldn't happen<br>any more. We definitly need to improve the pre-testing phase (hi volunteers,<br>we need more testers).<br><br>Hopefully we can come back to a pieceful and rational discussion here on<br>GRASS development model.<br><br>Regards<br><br> Markus Neteler<br><br>---------------------------------------- <br>If you want to unsubscribe from GRASS Development Team mailing list write to:<br><a class="moz-txt-link-abbreviated" href="mailto:minordomo@geog.uni-hannover.de">minordomo@geog.uni-hannover.de</a> with<br>subject 'unsubscribe grass5'<br><br><br><br></pre>
</blockquote>
<br>
</body></html>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'