[GRASS5] GRASS 5.1devel code structure

[Markus Neteler]

Hi all,
hi Radim and David,

[short intro as this thread started off-list:
 David and Radim are working on the new vector library, currently
 without CVS support. As we want a totally new structure for
 GRASS 5.1, a new CVS repository is required.

Here some original messages from Radim and David:
On Wed, Nov 01, 2000 at 12:05:26PM +0000, David D Gray wrote:
> Radim Blazek wrote:
[...]
> > > BTW. On the vector upgrades,it's getting difficult to keep track of the
> > > changes now that I think were more extensive than we originally thought.
> > > Perhaps we should ask Markus if we could establish a side-branch to tag
> > > for these updates, and keep it in CVS. If that's OK with you I'll try
> > > and get it set up now.
> > >
> > > David
> > 
> > Do you agree with idea of no support for dig3.0, dig4.0 files in GRASS5.1
> > except one module for conversion? I am working on such module. All support
> > for dig3.0,4.0 would be in this module and library and other modules would support
> > only dig5.0 instead of supporting more versions of dig as I originaly planned for
> > on the fly upgrading.
> > This would lead to more simple library but it would be necessary to prepare
> > upgraded library and all modules upgrade in CVS at one moment (or short time).
>
> Possibly. But it might be more feasible to have dig4 still as the
> default in the next release (5.1), and allow selected modules (those
> updated) to optionally choose dig5, which should be fully working. I'm
> not saying this is desirable, just that it is likely the way things will
> work out in the time scale we want for the 5.1 release. Consider how
> long it has taken the 4.x->5.0 upgrades, tests and bugfixes. This is a
> much more major upgarde to the vector libs we are proposing now (not as
> big as 3->4 though). In the subsequent 5.1->? development cycle, the
> remaining modules could be upgraded, and then dig5 would be the default
> (only) option. Then a dig4 conversion utility would be available, though
> that could be developed now as you propose. I don't want to exclude the
> possibility that we could complete the dig5 conversion by 5.1 as I think
> that would be very desirable if it could be achieved, it's just a big
> task. Perhaps we leave the options open for now.
> 
> Certainly we can start now as soon as the 5.1 branch is available (I
> just see that it is now...) to pull out all the old `portability' stuff
> for dig3 and earlier.
> 
> > I thing that during the process of upgrading we should clean up library and
> > modules also. I have compared vect32/Vlib and vect32_64/Vlib and it seems
> > to be very similar. 
> 
> vect64 compatibility would need input from people with access to at
> least some 64-bit platforms. What do you think. How are you with these
> platforms? I have to admit it's a black box to me.
> 
> > I thing that we could restructure it to something like
> > libes/vect/Vlib, libes/vect/diglib32, libes/vect/diglib32. Some fuctions
> > will be removed (for writting dig_att, converting old type to new)
> > 
> 
> Yes: vect is just an add-on to dig in the upgarde to dig4. They could be
> merged, but I see no need to rename. It's just some functionality would
> be dig_* and some Vect_*.
> 
> > As I understand plans for GRASS5.1 repository it should be new repository with
> > new structure. Most of other libes and modules will be probably commited to new
> > repository at one moment but I thing that we could commit it without vect support
> > and separately commit vect library already upgraded to dig5.0 and then step by step
> > add new upgraded vect modules. In GRASS5.1 repository would never appear vectlib
> > for dig3.0,4.0 and modules working with. 
> 
> Agreed.
> 
> > This would lead to some time without vector
> > support in GRASS5.1 but it will be development version. We need to work on vect library
> > in CVS together already so empty GRASS5.1 repository could be established in advance
> > with new vectlib and vect includes only. We could check out new local copy and create
> > symbolic link from GRASS5.0 so that we could compile with other libes from GRASS5.0.
> > 
> 
> This raises a question of the more general structure of the 5.1 branch.
> On the one hand it is a good opportunity to restructure, but it's
> impossivble to work without a complete working environment. So: perhaps
> the devel branch should contain only new code of _any_ kind. Then each
> developer would have a separate devel installation with it's own source
> tree that consists of source code and symlinks as you suggest.
> 
> Perhaps we should put this to the group?
Done :-)

Yesterday I have started a new repository for grass51. I suggest that
we add in a first step the library stuff only to get a somewhat working
environment. Eric Mitchell may directly update the new makefile/autoconf
system to get the minimum GRASS5.1 running. The library code structure
should be updated to a common structure according to GNU standards
(and/or others). Once we have this "core GRASS" established, modules
might be added (also re-organized). This will require more discussion
on the structure.

But: I strongly propose to concentrate on GRASS5.0 bugfixes!

 
> A developer's local installation would then consist of:
> 
> 1) A frozen/stable installation. This could be for bugfixes only, or
> also for a production environment. Some people might want another for
> production. (I even still have a GRASS4 environment - but by definition
> that should not be necessary by the time of the stable release).
> 
> 2) A development installation. ie. a separate binary tree of GRASS5.
> 
> 3) A frozen/stable source tree which is complete and in sync with the
> CVS stable tree.
>
> 4) A partial devel source tree that uses symlinks to link to unaltered
> stable code. This also is in sync with the devel tree in CVS, and would
> initially be quite small.
> 
> If for some reason the idea of a partial source tree was unacceptable,
> we would have to create a sticky side-branch for the new vector code,
> because we can't work on a functioning tree - it would break too much.
> Also some people are working on unrelated changes, like the XDRIVER
> which nevertheless affect our work.  I prefer, as you do, the first
> option, but we must put it to the group because I think it affects
> either all the code or none of it, not just vector stuff.
> 
> Also, now we see some of the practical problems about calling a freeze
> [Hi Markus]. I think we need to:
> 
> 1) Agree on a structure for CVS[5.1] with everyone.
> 
> 2) Give everyone a chance to work out their own strategies for handling
> their local installation(s).
> 
> 3) Set up 5.1
> 
> 4) Test a couple of things to see that most folk are happy it's working.
> (Minor glitches can be sorted out later).
> 
> 5) Call FREEZE!
> 
> 6A->Bugfix stable.
> 6B->Continue devel.
> 
> Regards
> 
> David

This sounds very good to me. Inofficially the "code freeze" was already
shouted, but we need a definite freeze now.

So: what's missing for GRASS 5.0 stable beside bugfixes? Several things
are already postponed to 5.1 (see ONGOING).

If we agree to close the 5.0 code for new additions, we should announce
"code freeze" asap.

Kind regards

 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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'