[GRASS5] Code Freeze schedule

GRASS GRASS developer
1

Hi all,

after receiving another request for code freeze to finalize
the GRASS 5 stable I want to propose a schedule (with your
assistance):

Things which should go into GRASS 5.0 stable
- new "init" mechanism (Justin Hickey)
- new env variable management (Justin Hickey)
- new autoconf (Eric Mitchell)
- Datum support for projections (Andreas Lange)
- sockets Xdriver (Carl Anderson)
- extent the test-suite testgrass.sh (all)

-> is this realistic?: please correct me, if not

Things which should go into GRASS 5.1 development
- code restructuring to packages (requires autoconf)
- 3D vectors (David D Gray, Radim Blazek)
- probably replace GRASS i/o routines by "libgrass" (Frank Warmerdam)
- layered XDRIVER (Pierre de Mouveaux)
- full RGB support in all display modules (Pierre de Mouveaux)
- tons of other stuff

Timeline:
- 1. Oct. 2000: Code freeze, split into stable tree and development tree

- start bugfixing only on stable tree, *concentrate* on bugfixes
- exeptional continue meanwhile on development team

- xx.xx.2000: Publish GRASS 5.0stable

What's missing? Any other suggestions? Is code freeze at Oct. 1 too
early/late?

Awaiting your comments

Markus

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

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

2

Hi all,

here a slightly updated schedule proposal:

> after receiving another request for code freeze to finalize
> the GRASS 5 stable I want to propose a schedule (with your
> assistance):

Things which should go into GRASS 5.0 stable
  - new "init" mechanism (Justin Hickey):
     Init means: graphical startup of GRASS instead of script based
                 startup (old method still working)
      -> in my opinion important for wide acceptance of GRASS

  - new env variable management (Justin Hickey)
      -> nothing critical I think (Justin?)

  - new autoconf (Eric Mitchell)
      -> probably critical (Eric?)
      -> this is required for platform independence and later
         split of GRASS into packages

  - Datum support for projections (Andreas Lange)
      -> due to personal communication with Andreas nearly finished
         nothing critical

  - sockets Xdriver (Carl Anderson)
      -> no idea about status, but required for Windows port finalization

  - extent the test-suite testgrass.sh (all)
      -> nothing critical, but important

  - fix all license problems (Bernhard Reiter)
      -> very important
      -> John Huddleston/David Gray are currently implementing a replacement
         for "Numerical recipe" stuff
      -> Helena/Bill B./Jaro Hofierka et al. have released their software
         under GPL

Please correct me, if the proposal is wrong/incomplete.

Frank Warnerdam wrote:

Markus,

I haven't been following things too closely, but how critical do you think
the new init stuff, env variable stuff and autoconf are to the success of
GRASS 5? These seem like significant items, and I am not sure what critically
important role they play.

.. see new comments above.

I think October 1st is pretty close unless these development items are really
close to ready. I also think you should avoid splitting into a stable and
development tree till essentially all known bugs are fixed that you intend
to fix for the release. After a split you will start having management
problems getting bug fixes into both versions.

Yes. Probably we say:

  1. Code freeze, full concentration on bugfixes.
  2. Then split off a development tree

Also, is there a list of bugs classified by severity? I skimmed through
BUGS looking for stuff I would be interested in fixing. I noted a bug in
r.in.tiff, r.out.tiff and would be interested in looking into it, but I
don't know what supporting information there is about the bug.

This could be added. Volunteers?

I think it would be quite useful to setup a bug management system (such
as Bugzilla) for GRASS. Something where more detail and history could be
maintained for bugs compared to the BUGS file. Perhaps Bernhard would be
interested in setting this up on the intevation server. Alternatively we
could easily add a GRASS package to the BugZilla running off remotesensing.org
or even setup a GRASS project at SourceForge primarily for use of the bug
system.

Well, we have discussed this some time ago. The general opinion was not
to use such bug manager. I am not shure - we might discuss again.

Currently I am collecting every information/bugreport I receive in the
BUGS/TODO files. In fact this is extra work for me.

Thanks for your comments, Frank!

Yours

Markus

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

3

Markus

This schedule is OK by me.

David

Markus Neteler wrote:

Hi all,

after receiving another request for code freeze to finalize
the GRASS 5 stable I want to propose a schedule (with your
assistance):

Things which should go into GRASS 5.0 stable
- new "init" mechanism (Justin Hickey)
- new env variable management (Justin Hickey)
- new autoconf (Eric Mitchell)
- Datum support for projections (Andreas Lange)
- sockets Xdriver (Carl Anderson)
- extent the test-suite testgrass.sh (all)

-> is this realistic?: please correct me, if not

Things which should go into GRASS 5.1 development
- code restructuring to packages (requires autoconf)
- 3D vectors (David D Gray, Radim Blazek)
- probably replace GRASS i/o routines by "libgrass" (Frank Warmerdam)
- layered XDRIVER (Pierre de Mouveaux)
- full RGB support in all display modules (Pierre de Mouveaux)
- tons of other stuff

Timeline:
- 1. Oct. 2000: Code freeze, split into stable tree and development tree

- start bugfixing only on stable tree, *concentrate* on bugfixes
- exeptional continue meanwhile on development team

- xx.xx.2000: Publish GRASS 5.0stable

What's missing? Any other suggestions? Is code freeze at Oct. 1 too
early/late?

Awaiting your comments

Markus

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

4

The schedule overall is fine,
though I cannot guarentee any timeframe on the licensing problems.
That is because they depend on me getting (positive) answers.
  Bernhard

On Wed, Sep 20, 2000 at 06:50:10PM +0100, Markus Neteler wrote:

Things which should go into GRASS 5.0 stable

  - sockets Xdriver (Carl Anderson)
      -> no idea about status, but required for Windows port finalization

I am not sure here, but getting this to work reliably and tested probably
is beyond the scope of the next stable GRASS version.

Therefore I suggest calling the Windows port code which can be in the
next stable source code release: experimental or alpha quality code.
We can make it an option in the configure script but turn
sockets Xdriver off by default.

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

5

Hello Markus

If all goes well, I will probably get back to the environment code next
week. It is almost done so there should be no problem there.

As for the new init code, I may need more time on that. If we really
want to press for a stable release, then we may need to postpone the new
init until later. If people feel it is better to release without it,
then I have no problems with that.

--
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!!!

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

6

On Thu, Sep 21, 2000 at 06:35:35PM +0700, Justin Hickey wrote:

Hello Markus

If all goes well, I will probably get back to the environment code next
week. It is almost done so there should be no problem there.

As for the new init code, I may need more time on that. If we really
want to press for a stable release, then we may need to postpone the new
init until later. If people feel it is better to release without it,
then I have no problems with that.

Hello Justin,

believe that I am far from putting pressure on you! But I think
that a graphical login to GRASS 5 is very important. So it would
be a nice feature to have it in the first stable release and
a good signal for GRASS' future. Probably you can get assistance
from other developers here?

Yours

Markus

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

7

Markus Neteler wrote:

- new autoconf (Eric Mitchell)

I'd save this for 5.1. The current build system works
fine, it's just not as "standard" as it could be. There
has been talk of reorganizing the source tree for some
time, and integrating my proposed (and prototyped) build
system with that new layout would make more sense than
putting it on top of the current system, and moving things
around later.

Also, I recently purchased a house that needs a lot of
work, and my free time (what little there was of it) is
pretty much non-existent. I'll continue to poke at it
here and there, but I don't see this new system finished
on the 5.0 schedule unless someone else can do a lot of
the grunt work for me. (volunteers? =) I can put what
I have currently in CVS, as it doesn't interfere with
the current system, and offer advice to those wishing to
extend it, though. Unfortunately, I won't be able to
put much work into it myself, at least, until we get the
floors sanded and refinished in the house... =)

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emitchell@altaira.com |
| tel: (301) 809 - 3534 Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR 4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122 Bowie, MD 20716 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\ / o=\ /"""---===/
         / \_/ \__/ ---===/
         | //\ || /""TT""/ //\ || ||""\
         | // \ || || // \ || ||__/
         | //--==\ |L--/ || //--==\ || || "=,
          \ ---===/
           \____---===/

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

8

Markus Neteler a écrit :

believe that I am far from putting pressure on you! But I think
that a graphical login to GRASS 5 is very important. So it would

I will like a graphical login, but there should also be a command-line login :
sometimes, you just want to run some long command or run batches (with the
unix "at" command) in background. This work well because "at" takes care of
environment variables, so you can run some time consuming computation while
you sleep (or watch olympic games at home in your armchair :-). I think you
have to take care of that in the design of a new login interface...

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

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

9

Hi Michel

Michel Wurtz wrote:

Markus Neteler a écrit :
> believe that I am far from putting pressure on you! But I think
> that a graphical login to GRASS 5 is very important. So it would

I will like a graphical login, but there should also be a command-line
login :

You're right, and we already included this in the design. The user will
have a choice to use either the old interface or the new GUI one. By
default the GUI will pop up, but by passing a command line argument to
the grass5 script, the user can use the old interface. Another option I
am thinking of is using an environment variable to indicate which
interface to start, but I haven't decided on that one yet.

Thanks for your input.

--
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!!!

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

10

Oops. I think I misunderstood you the first time. I think you meant to
have a command line program that would simply run a batch process in
grass. Is that right? If so I don't see the need for such a thing since
all you need to do is enter grass and then run your batch command. Even
though the startup will be graphical, you will still be able to open a
grass shell. Thus, the bacth command processing will still be available.

Sorry for the confusion.

Justin Hickey wrote:

Hi Michel

Michel Wurtz wrote:
>
> Markus Neteler a écrit :
> > believe that I am far from putting pressure on you! But I think
> > that a graphical login to GRASS 5 is very important. So it would
>
> I will like a graphical login, but there should also be a command-line
> login :

You're right, and we already included this in the design. The user will
have a choice to use either the old interface or the new GUI one. By
default the GUI will pop up, but by passing a command line argument to
the grass5 script, the user can use the old interface. Another option I
am thinking of is using an environment variable to indicate which
interface to start, but I haven't decided on that one yet.

Thanks for your input.

--
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!!!

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

--
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!!!

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

11

Justin Hickey a écrit :

Oops. I think I misunderstood you the first time. I think you meant to
have a command line program that would simply run a batch process in
grass. Is that right? If so I don't see the need for such a thing since
all you need to do is enter grass and then run your batch command. Even
though the startup will be graphical, you will still be able to open a
grass shell. Thus, the bacth command processing will still be available.

No, your first reading was the good one. I agree with the rest of your
comment : once grass is started in "command line" mode, it's easy to
run any shell script in batch mode (some of mines take more than 9 hours,
runing more than 10000 grass command).

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

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

12

On Fri, Sep 22, 2000 at 10:46:28AM +0200, Michel Wurtz wrote:

Markus Neteler a écrit :
> believe that I am far from putting pressure on you! But I think
> that a graphical login to GRASS 5 is very important. So it would

I will like a graphical login, but there should also be a command-line login :
sometimes, you just want to run some long command or run batches (with the
unix "at" command) in background. This work well because "at" takes care of
environment variables, so you can run some time consuming computation while
you sleep (or watch olympic games at home in your armchair :-). I think you
have to take care of that in the design of a new login interface...

Justin will take care of this (certainly the script login will be kept!)

Markus

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

13

Code Freeze schedule for GRASS 5 stable
documents/code_freeze.txt

$Id: code_freeze.txt,v 1.1 2000/09/22 13:07:16 markus Exp $

Things to focus on for GRASS 5.0 stable
1) new "init" mechanism (Justin Hickey) with session manager:
    Init means: graphical startup of GRASS (default) aditionally to
                 script based startup (option)
      -> important for wide acceptance of GRASS
      -> may allow location change on-the-fly
      -> not critical, but time consuming

2) Datum support for projections (Andreas Lange)
      -> due to personal communication with Andreas nearly finished
         nothing critical

3) new env variable management (Justin Hickey)
      -> nothing critical, rather completed

4) extent the test-suite testgrass.sh (all)
      -> nothing critical, but important

5) fix all license problems (Bernhard Reiter)
      -> very important
      -> John Huddleston/David Gray are currently implementing a replacement
         for "Numerical recipe" stuff
      -> Helena/Bill B./Jaro Hofierka et al. have released their software
         under GPL
      -> time consuming to reach involved people (former programmers)

6) sockets Xdriver (Carl Anderson)
      -> no idea about status, but required for Windows port finalization

Things to go into GRASS 5.1 development (after Oct. 15th):

1) New code directory structure:
    * required for new autoconf implementation (Eric Mitchell)
      -> critical change
    * required to split GRASS into packages, probably online-update
      option (like PERL)
    * the next stable release should be built on re-structured code.
      Therefore a split into stable/development tree should take place
      after restructuring and before applying new features/autoconf

2) 3D vector support (David D Gray, Radim Blazek)
    * needs modification of all vector modules

3) replace GRASS i/o routines by "libgrass" (Frank Warmerdam)

4) layered XDRIVER (Pierre de Mouveaux)
  
5) full RGB support in all display modules (Pierre de Mouveaux)

X) tons of other stuff (see TODO file)

Timeline:
- 15. Oct. 2000:
       a) Code freeze announce
       b) new directory structure
       c) based on this split into stable tree and development tree
- then:
       - start bugfixing only on stable tree, *concentrate* on bugfixes

- xx.xx.2000: - release GRASS 5.0stable
               - continue work on development tree

This is the revised schedule from recent discussion.

Obviously it makes sense to go for code-restructuring *before* releasing
GRASS 5 stable as the split into stable/development branch and the new
autoconf system will depend on it. As the code-restructuring does not affect
the binary packages it is less critical to the common user, so we should
take that "risk".

Comments are welcome.

Markus

PS: Carl, please send a comment on XDRIVER/sockets.
    Is there anyone else familiar with sockets? I have the 1994 R. Wiemer
    code available (he implemented sockets for GRASS 4.1).

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

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

14

Markus Neteler wrote:

3) replace GRASS i/o routines by "libgrass" (Frank Warmerdam)

Markus,

It isn't clear to me that it is desirable for GRASS to directly use
libgrass. Instead I would state the following objectives.

o While restructing the build environment and source tree consider
   our options to build various component libraries as shared libraries
   to reduce the size of resulting command executables.

o Migrate some (or all?) of the extended APIs in libgrass back into
   libgis.

Also, on the 3D vectors. A change of vector format is a big change. While
it might be doable by 5.1, I don't think it is a forgone conclusion that it
could or should be. A vector/DBMS overhaul might instead be what defines
a GRASS 6.0. Is this one of the areas that Baylor has been experimenting?

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerda@home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

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

15

Frank,

On Fri, Sep 22, 2000 at 09:42:38AM -0500, Frank Warmerdam wrote:

Markus Neteler wrote:
> 3) replace GRASS i/o routines by "libgrass" (Frank Warmerdam)

Markus,

It isn't clear to me that it is desirable for GRASS to directly use
libgrass.

My main intention is to keep it in sync.

Instead I would state the following objectives.

o While restructing the build environment and source tree consider
   our options to build various component libraries as shared libraries
   to reduce the size of resulting command executables.

Sounds good. As far as I know Michel Wurtz developed such concept for
GRASS 4.x once.

o Migrate some (or all?) of the extended APIs in libgrass back into
   libgis.

That's of course even better. Shall I just remove this point from the
list?

Also, on the 3D vectors. A change of vector format is a big change. While
it might be doable by 5.1, I don't think it is a forgone conclusion that it
could or should be. A vector/DBMS overhaul might instead be what defines
a GRASS 6.0. Is this one of the areas that Baylor has been experimenting?

We have no ideas about Baylor "GRASS 6.0" ideas. But they hopefully explain
it here. As Radim has developed the new independent DBMS driver he and
David will have this vector/DBMS link in mind.

Thanks for your comments

Markus

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

16

On Fri, Sep 22, 2000 at 03:08:49PM +0100, Markus Neteler wrote:

Things to focus on for GRASS 5.0 stable

6) sockets Xdriver (Carl Anderson)
      -> no idea about status, but required for Windows port finalization

I vote against this one. As explained in my last mail.

Things to go into GRASS 5.1 development (after Oct. 15th):

1) New code directory structure:
Obviously it makes sense to go for code-restructuring *before* releasing
GRASS 5 stable as the split into stable/development branch and the new
autoconf system will depend on it.

I also think that we can keep the old struture for the stable release.
We should get a stable release out as fast as we can and then get
another one out. (This is what I am suggesting, making small but more
steps.)

  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

17

Frank Warmerdam wrote:

[...]
Also, on the 3D vectors. A change of vector format is a big change. While
it might be doable by 5.1, I don't think it is a forgone conclusion that it
could or should be. A vector/DBMS overhaul might instead be what defines
a GRASS 6.0. Is this one of the areas that Baylor has been experimenting?

Best regards,

Hi Frank,

The changes that Radim and myself are planning to make to the current
vector (dig) library are really only minimal changes, to allow some very
basic features. These features, like immediate multi-category
availability and a third field for some very basic 3d capabilities, like
projected TINs, are necessary things that the vector engine really limps
without.

But I do agree that a vector engine overhaul is needed, to enable more
sophistaicated capabilities - arbitrary surface and volume elements,
more efficient spatial data handling and wider projection and geometry
features. There has also been talk of CAD-like extensions. I think
development should start on this soon, if it hasn't already, and the
development sequence would take its own time - but yes, I think it
unlikely that this would be stable and integrated before GRASS6.

David

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

18

Hi all,

the date of code freeze is quite close! I suggest to directly
start with bug fixes. Then I will put a GRASS 5 tarball onto
the server after Oct. 15th. This is our release candidate which
should be tested heavily and, if required changes are implemented,
will be released as GRASS5.0stable.
Then we can go for the new development version with re-organization
etc etc. (as roughly planned in documents/code_freeze.txt)

I will comment the buggy modules this evening in src/CMD/lists/GRASS.
All modules we can manage to fix (see BUGS file) can certainly be
uncommented before releasing the stable version. But the stable version
should be limited to stable modules.

Is that alright with all developers?

Sidenote: The NVIZ core dumps with tcl/tk 8.3 on SGI and on Linux.
This should be fixed as tcl/tk8.3 is part of many fresh Linux
distributions nowadays.

Justin, not to bother you: But can we get in the *simple* graphical
login procedure? Without session manager? This would be a good signal
for the first stable release...

Thanks for listening

Markus

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

19

Hello Markus

Markus Neteler wrote:

Is that alright with all developers?

It's OK with me.

Justin, not to bother you: But can we get in the *simple* graphical
login procedure? Without session manager? This would be a good signal
for the first stable release...

I'll look into it.

--
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!!!

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

20

Hi Markus, Hi all,

i am still struggeling with some testing issues for the datum library.
But i hope/plan to check in the library until the weekend.

As only m.datum.shift is currently using the library no general
stability problems are to expect.

How did you compile NVIZ on IRIX? Are the required changes in CVS?

cu,

Andreas

Markus Neteler wrote:

Hi all,

the date of code freeze is quite close! I suggest to directly
start with bug fixes. Then I will put a GRASS 5 tarball onto
the server after Oct. 15th. This is our release candidate which
should be tested heavily and, if required changes are implemented,
will be released as GRASS5.0stable.
Then we can go for the new development version with re-organization
etc etc. (as roughly planned in documents/code_freeze.txt)

I will comment the buggy modules this evening in src/CMD/lists/GRASS.
All modules we can manage to fix (see BUGS file) can certainly be
uncommented before releasing the stable version. But the stable version
should be limited to stable modules.

Is that alright with all developers?

Sidenote: The NVIZ core dumps with tcl/tk 8.3 on SGI and on Linux.
This should be fixed as tcl/tk8.3 is part of many fresh Linux
distributions nowadays.

Justin, not to bother you: But can we get in the *simple* graphical
login procedure? Without session manager? This would be a good signal
for the first stable release...

Thanks for listening

Markus

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

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