Discussion on 4.2.1 update frequency

GRASS GRASS user
1

Dear GRASS Community,

you may have realized that the update frequency for
GRASS 4.2.1 is very high. I would like to ask you
(start a discussion on this point), what way do you
prefer for future development:

Sceneries (all ways certainly with publishing of small
            update packages beside the full code package):

  a) update with high frequency (all 2 weeks depending
                         on input like today)

  b) update with medium frequency (monthly for example)
   
  c) update with less frequency (e.g. collecting changes for
                                 half a year)

I expect that the base package of GRASS 5.0 will be
published in late summer 1998. Because all functions could
not yet be included in that distribution, GRASS 4.2.1 will
survive for some time in parallel to allow a "soft migration".
Later this year (or next year) the other functionality of
4.2 will be migrated to 5.0.
Therefore I need your opinion on future development of 4.2.1.

Hope to hear from you soon (I suggest to discuss on this topic
through the mailing list to make it most public),

   Markus Neteler

---------------------------------------------------------------------
Geographisches Institut | Institute of Geography
   Physische Geographie Physical Geography
& Landschaftsoekologie & Landscape Ecology
Universitaet Hannover University of Hannover, Germany
                     neteler@geog.uni-hannover.de
             http://www.geog.uni-hannover.de/users/neteler/
----------------------------------------------------------------------

2

MN> Dear GRASS Community, you may have realized that the update
MN> frequency for GRASS 4.2.1 is very high. I would like to ask you
MN> (start a discussion on this point), what way do you prefer for
MN> future development:
What 's the number of current GRASS contributors ?

If there'is suffisant contributors it's possible to make a Linux like
developpment courses :
make a developper serie and an user serie. And like Linus T, you can
choose whem you want to make a feature free and a bug hunting for
the developer version.
But in the other hand, due to the modular structure of GRASS theres
little interaction between different fonctionnality : one can improve
a module without trouble with other module.
Perhaps better separing grass in different package : a core, and different
fonctionnality brings by several distinct package.

MN> I expect that the base package of GRASS 5.0 will be published in
MN> late summer 1998. Because all functions could not yet be included
MN> in that distribution, GRASS 4.2.1 will survive for some time in
MN> parallel to allow a "soft migration". Later this year (or next
MN> year) the other functionality of 4.2 will be migrated to 5.0.
MN> Therefore I need your opinion on future development of 4.2.1.

Another question : what kind of help a person can bring to the GRASS
community without programming ?
(documentation, translation [about translation
what kind of internationalisation can be made with grass ? here's plan
to use tool like gnugetext to help this process?])

Last question I search people using GRASS in Medical application.
Great Job !!!
Excuse me for my poor english.

--
Hervé Dréau Interne en Médecine
hdreau@worldnet.fr dreau@b3e.jussieu.fr
Médecine Linux Java

3

Hi All!

I am totally for option a (frequent updates) but would prefer patches
instead of downloading full code. This proved to be the best model for
the free-source software (for some insights see this wonderful article
by Eric S. Raymond
http://earthspace.net/~esr/writings/cathedral-bazaar/index.html). I
understand that there will be users preferring not to bother themselves
with weekly updates but they can apply sets of patches at their
connivance.

Technically there are many ways to manage frequent updates. For example,
we can follow Mozilla's path and establish somewhere anonymous read-only
CVS server with GRASS source tree.

--
Alexandre Sorokine, GIS specialist
Regional Science Institute 4-13 Kita-24 Nishi-2, Kita-ku
                                          Sapporo 001-0024 JAPAN
mailto:sorokin@vtt.co.jp Tel +81-11-717-6660
http://www.vtt.co.jp/staff/sorokin Fax +81-11-757-3610

4

On Jun 19, 11:30am, Markus Neteler wrote:

Subject: Discussion on 4.2.1 update frequency
Dear GRASS Community,

you may have realized that the update frequency for
GRASS 4.2.1 is very high. I would like to ask you
(start a discussion on this point), what way do you
prefer for future development:

Sceneries (all ways certainly with publishing of small
            update packages beside the full code package):

  a) update with high frequency (all 2 weeks depending
                         on input like today)

  b) update with medium frequency (monthly for example)

  c) update with less frequency (e.g. collecting changes for
                                 half a year)

I expect that the base package of GRASS 5.0 will be
published in late summer 1998. Because all functions could
not yet be included in that distribution, GRASS 4.2.1 will
survive for some time in parallel to allow a "soft migration".
Later this year (or next year) the other functionality of
4.2 will be migrated to 5.0.

My view on this is that since GRASS consists of several separate and "mostly"
independent programs, as opposed to a single large program, it is generally
safe to include frequent updates to the source code. Most of the time, any
changes will not affect the general operation of GRASS. Therefore, I think that
the rate of updates should depend on the rate of changes submitted to Markus.
Of course if someone submits a change to a library (like libgis) or a major
header file (like gis.h) then the changes should be scrutinized a little more
carefully before adding them to the source code and issuing a new update.

Ultimately, it is up to the GRASS users to decide whether they will download a
new update or not. To facilitate this, providing a list of new features and bug
fixes for each update should be made available. Although Markus does this with
each new announcement of a new upgrade, I think it would be convenient for
users to have a "history of changes" web page for each of the upgrades. The
reason for this is that suppose I downloaded version 10, and so far I haven't
had time to upgrade to the latest release. Now that I have time, I would like
to be able to determine if it is worthwhile upgrading or not. A web page with a
list of changes for each upgrade would be the perfect place for me to make this
determination.

Markus, do you think having such a page is feasible? Any other comments from
the rest of the list?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!