[GRASS5] GRASS development model Was: A private conversation

[Markus Neteler]

Hi Malcolm,

[please always post in ASCII, not in HTML... ]

On Mon, Feb 19, 2001 at 10:30:55PM -0400, Malcolm Blue wrote:

> 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.
I agree, this was what we have to learn from the beta11 release.

> 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>
>
> 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>
Here I agree as well. Maybe myself I try "feature creep" as well which
should be strictly avoided. We simply need some discipline :-)

> 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. 
We need some "release managers" for the several binary distributions.
And we'll start with branching asap. This will need some time to learn
how to branch with CVS, but should lead to a clear structure.

> (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.)
:-) BTW: I have been starting to try Linux with 0.13, stopped, came back
with 0.95 and removed Windows when 0.99p1 was out. Of course I was real
novice that time.

> 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.
> 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.&nbsp; While I'm not using it on
> current projects, I will consider it as an option on future projects.&nbsp;
> I also plan on contributing when I can.
Thanks, Malcolm. We need your input!

> Markus: &nbsp; 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.&nbsp; There should be existing models that can be
> applied here to make a good system better.&nbsp; If I find anything of use
> I'll send a link or comments to you.
Yes, great. Please post to the list for discussion.

> Also,&nbsp; I don't think that Rich should feel he was flamed.&nbsp;
> 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.&nbsp; As a newcomer to the
> grass development group, I hope that I can help.&nbsp; As an experienced
> developer, I know that you can expect to hear negative comments quicker
> and louder than positive comments.&nbsp; It's when people stop commenting
> that you should really get worried.<br>
>
> Adding my .02 CAN,
> Malcolm

We need this development model discussion and should continue it from time
to time.

Kind regards

 Markus Neteler

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'