[GRASS5] Next steps for GRASS

GRASS GRASS developer
1

Dear developers,

although the year is already a few days old:
a happy and prosperous new year to everybody!

The last year was pretty good for GRASS development, looking at
the "NEWS" list we can see the steady maturing into a stable system.
The code is portable now on numerous architectures and operating
systems, GRASS is running on nearly all UNIX derivates as well as
MacOS X and MS-Windows (with Cygwin). Thanks to all for their
contributions! I hope that the users enjoy the ongoing development.

If you allow, I have some suggestions for the next time (to be
discussed):

As also proposed by others, we should release GRASS 5.0pre3
soon. Why another pre? Still some problems are remaining,
especially with v.support and friends. I think that a stable GRASS
release still has to wait. Without a functional basic 2D vector
support an important part of GRASS would be missing. Probably, as
some of the problems in v.support have been identified, it is not
so difficult to get it working.
So many talented programmers are here :slight_smile:

Then: An outcome of the developers meeting in Trento last November
was that a merge back of the release_branch into the experimental
tree is required for synchronization. However, from there we will
create a new release_branch again which only contains the modules
intented for release as stable version.
Glynn and Radim (independently) have looked into this, the merge is
not too difficult.
Radim has prepared a comparison:
  http://www.raz-dva.cz/krakonos/brafra.html

Then: As preparing a binary release of GRASS is not a really exciting
job, I want to set up a script for this. Here at Irst we can provide
Linux and SUN (some Solaris, don't know right now). But an IRIX machine
is not available. Probably someone is willing to provide some IRIX
computational power to also build a release for that platform. And
for Windows/Cygwin I propose to release the new generic driver
as an add-on package (if possible) to encourage more users to
test it.

Best regards

Markus

2

On Sun, Jan 06, 2002 at 06:44:03PM +0100, Markus Neteler wrote:

If you allow, I have some suggestions for the next time (to be
discussed):

As also proposed by others, we should release GRASS 5.0pre3
soon. Why another pre? Still some problems are remaining,
especially with v.support and friends. I think that a stable GRASS
release still has to wait. Without a functional basic 2D vector
support an important part of GRASS would be missing. Probably, as
some of the problems in v.support have been identified, it is not
so difficult to get it working.
So many talented programmers are here :slight_smile:

There is a saying that Free Software releases happen,
when they are ready.
Even if we had planned otherwise, we have to delay a stable
grass 5.0.0 release if we find grave weaknesses.

On the other hand: We have to "release" tar balls at a contant rate.
Conclusion: We need another pre release, this might not be the last.

Then: An outcome of the developers meeting in Trento last November
was that a merge back of the release_branch into the experimental
tree is required for synchronization. However, from there we will
create a new release_branch again which only contains the modules
intented for release as stable version.

Yes.
The strategy should be to _only_ fix "critical" bugs on that branch.
All other fixes, enhancements and so on have to go in the grass50 trunk!

After the release we merge branch back on the trunk.

Then: As preparing a binary release of GRASS is not a really exciting
job, I want to set up a script for this. Here at Irst we can provide
Linux and SUN (some Solaris, don't know right now). But an IRIX machine
is not available. Probably someone is willing to provide some IRIX
computational power to also build a release for that platform. And
for Windows/Cygwin I propose to release the new generic driver
as an add-on package (if possible) to encourage more users to
test it.

If we have a stable release which will only contain modules that
are known to are stable, we can release add-on tarballs.
These add-ons can have various qualities attached.
We just have to mark them clearly.

  Bernhard

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

3

Markus Neteler wrote:

Then: An outcome of the developers meeting in Trento last November
was that a merge back of the release_branch into the experimental
tree is required for synchronization. However, from there we will
create a new release_branch again which only contains the modules
intented for release as stable version.

I'm a little confused by release branch and main trunk of Grass5.0.
I made all the changes (bug fixes and some code enhancement) on the
branch "releasebranch_11_april_2001_5_0_0".

Does this mean that I should do that on "MAIN" and must only fix
bugs on release_branch ?

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

4

On Mon, Jan 07, 2002 at 03:05:08PM +0000, Michel Wurtz wrote:

Markus Neteler wrote:
>
> Then: An outcome of the developers meeting in Trento last November
> was that a merge back of the release_branch into the experimental
> tree is required for synchronization. However, from there we will
> create a new release_branch again which only contains the modules
> intented for release as stable version.

I'm a little confused by release branch and main trunk of Grass5.0.
I made all the changes (bug fixes and some code enhancement) on the
branch "releasebranch_11_april_2001_5_0_0".

A lot of people did, you are not alone... :slight_smile:
Another stragety was not explained enough.

Does this mean that I should do that on "MAIN" and must only fix
bugs on release_branch ?

That is the idea.
As it obviously did not happen as envisioned,
we have to do the merge first,
before we can branch again.

If you think about a code change, which is

  Completly experimental and not of immediate relevance:
    Consider adding it to grass51

  If a critical bug: consider release branch
         Ask Markus.

  Default: MAIN

Bernhard

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

5

Bernhard Reiter wrote:

On Mon, Jan 07, 2002 at 03:05:08PM +0000, Michel Wurtz wrote:

> Does this mean that I should do that on "MAIN" and must only fix
> bugs on release_branch ?

That is the idea.
As it obviously did not happen as envisioned,
we have to do the merge first,
before we can branch again.

How to merge ? should I create another grasss directory for that and
copy all my changes in it, then check-in ?
I believe that simply changing the tag will only replace all the files
in release_branch by the one in main trunk... I don't want to loose
the modification I've not uploaded until now !

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

6

On Mon, Jan 07, 2002 at 05:34:10PM +0000, Michel Wurtz wrote:

Bernhard Reiter wrote:
>
> On Mon, Jan 07, 2002 at 03:05:08PM +0000, Michel Wurtz wrote:
>
> > Does this mean that I should do that on "MAIN" and must only fix
> > bugs on release_branch ?
>
> That is the idea.
> As it obviously did not happen as envisioned,
> we have to do the merge first,
> before we can branch again.

How to merge ?

AFAIK Markus and Glynn (maybe radim) are working on this merge.

should I create another grasss directory for that and
copy all my changes in it, then check-in ?
I believe that simply changing the tag will only replace all the files
in release_branch by the one in main trunk... I don't want to loose
the modification I've not uploaded until now !

Make a copy of your working tree with modifications.
Thus you can be sure when doing cvs operations.

7

Bernhard Reiter wrote:

> Does this mean that I should do that on "MAIN" and must only fix
> bugs on release_branch ?

That is the idea.
As it obviously did not happen as envisioned,
we have to do the merge first,
before we can branch again.

If you think about a code change, which is

  Completly experimental and not of immediate relevance:
    Consider adding it to grass51

  If a critical bug: consider release branch
         Ask Markus.

  Default: MAIN

Right now, the CVS trunk is a bit of a mess; it hasn't been actively
maintained since the branch was created in April.

I'd like to merge the changes back into the trunk ASAP, but I'm still
waiting on confirmation.

Until then, keep local copies of anything which isn't committed to the
release branch. Code which is added to the trunk may inadvertently get
removed or reverted by the merge (it should still be in CVS, but it
might not be straightforward to determine what's what).

--
Glynn Clements <glynn.clements@virgin.net>

8

On Tue, Jan 08, 2002 at 12:16:42AM +0000, Glynn Clements wrote:

Bernhard Reiter wrote:

> > Does this mean that I should do that on "MAIN" and must only fix
> > bugs on release_branch ?
>
> That is the idea.
> As it obviously did not happen as envisioned,
> we have to do the merge first,
> before we can branch again.
>
> If you think about a code change, which is
>
> Completly experimental and not of immediate relevance:
> Consider adding it to grass51
>
> If a critical bug: consider release branch
> Ask Markus.
>
> Default: MAIN

Right now, the CVS trunk is a bit of a mess; it hasn't been actively
maintained since the branch was created in April.

I'd like to merge the changes back into the trunk ASAP, but I'm still
waiting on confirmation.

Before we merge back, we should clean old stuff from the experimental
trunk. Example:

Do we need
documents/grass6vector_api/
? In a file which I can't find now (but Glynn has a copy) those delete
candidates are identified. We may have to discuss those, delete them
or a subsecion and finally merge back.

[...]

Markus

9

On Tue, Jan 08, 2002 at 12:18:33PM -0500, Robert Lagacé wrote:
[...]

> Before we merge back, we should clean old stuff from the experimental
> trunk. Example:
>
> Do we need
> documents/grass6vector_api/

I would like to get a copy of it.

No problem to send it, but: it's not used. The text is from 1995
or earlier, describing a draft implementation of which the code
is lost.

Still interested?

Markus

PS: The real 5.1 docs are here:
http://grass.itc.it/grass51/index.html