[GRASS-dev] GRASS 6.3.0RC1 released

Markus,

I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?

Michael

Post by Markus Neteler
http://grass.itc.it/grass63/source/
-> grass-6.3.0RC1.tar.gz
An initial announcement has been drafted at
http://grass.itc.it/announces/announce_grass630.html
(state April 2007, further fixes need to be merged in)
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
Release candidate management at
http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan
Please test, test, test...
A big thanks to all contributors!
Markus

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Glynn Clements

2007-10-24 06:03:23 UTC

Post by Michael Barton
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?

Add them to the head first, then back-port to the release branch after
testing.

The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.

To sync changes from the trunk to a branch, use "cvs update" with two
-j switches, e.g.:

cvs update -j releasebranch_6_3 -j HEAD

This is roughly equivalent to:

cvs diff -r releasebranch_6_3 -r HEAD | patch -p0

--
Glynn Clements <***@gclements.plus.com>

Carlos Dávila

2007-10-24 16:20:54 UTC

Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0

I followed your instructions to send some changes to both head and
release branch. Files were updated in my local releasebranch copy, but
doesn't seem to have changed in repository (or I'm looking in the wrong
place). You can check for example /display/d.extract/main.c:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.extract/?only_with_tag=
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/display/d.extract/?only_with_tag=releasebranch_6_3

Glynn Clements

2007-10-24 20:14:28 UTC

Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0

Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.

--
Glynn Clements <***@gclements.plus.com>

Carlos Dávila

2007-10-24 21:19:55 UTC

Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0

Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.

Yes, but the problem is I did "cvs ci" from releasebranch copy and it
did nothing.

Glynn Clements

2007-10-25 00:16:52 UTC

Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
cvs update -j releasebranch_6_3 -j HEAD
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0

Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.

Yes, but the problem is I did "cvs ci" from releasebranch copy and it
did nothing.

First, check that your local copy is of the release branch, not the
trunk (or a specific release), by looking at the CVS/Tag and
CVS/Entries files for the directory in question. The former should
contain Treleasebranch_6_3, while the latter should have that tag at
the end of each entries.

Also, using "cvs update -j ... -j ..." assumes that you have already
committed the changes to the trunk. To clarify:

1. Make changes to the local copy of the trunk.
2. Commit the changes.
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
5. Commit the changes.

--
Glynn Clements <***@gclements.plus.com>

Markus Neteler

2007-10-24 11:05:05 UTC

Post by Michael Barton
Markus,
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?

Michael
I have backported it for you.

Markus

Hamish

2007-10-25 03:41:15 UTC

Some pedantic but by my experience useful steps added below,
(lessons learned as I messed things up at each one of these steps in the past)
0. 'cvs update' to be sure you are working with the latest version.

Post by Glynn Clements
1. Make changes to the local copy of the trunk.

1.5 'cvs diff' to check for left over temporary debug messages, unnecessary
whitespace changes, etc.

Post by Glynn Clements
2. Commit the changes.

2.5. Decide if the change is suitable for backporting.

Post by Glynn Clements
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.

4.5 'cvs diff' check again.

Post by Glynn Clements
5. Commit the changes.

As to deciding what is suitable for backporting, I am of two minds. On one hand
it is very useful to have some sort of deadline to motivate us to fix as many
old lingering bugs as possible before the release. On the other hand even small
modifications to critical modules like g.region and r.out.gdal days before
release are very dangerous. Those need maximum testing time in the development
branch to avoid nasty unintentional side effects. It has been typical for that
sort of mistake not to be spotted even in the well tested CVS/HEAD version for
months.

A good rule seems to be only backport important bug fixes and well-tested
important updates. Leave anything else to a future release. 6.3.0 is not
intended to be as stable as 6.2, so I wouldn't worry so much about that here,
for 6.3 it becomes more a question of if the backporting justifies the double
effort.

The stable branch CVS mostly goes untested before release, so any change there
has to be very carefully done.

Hamish

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Carlos Dávila

2007-10-25 20:37:53 UTC

Post by Hamish
Some pedantic but by my experience useful steps added below,
(lessons learned as I messed things up at each one of these steps in the past)
0. 'cvs update' to be sure you are working with the latest version.

Post by Glynn Clements
1. Make changes to the local copy of the trunk.

1.5 'cvs diff' to check for left over temporary debug messages, unnecessary
whitespace changes, etc.

Post by Glynn Clements
2. Commit the changes.

2.5. Decide if the change is suitable for backporting.

Post by Glynn Clements
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.

4.5 'cvs diff' check again.

Post by Glynn Clements
5. Commit the changes.

Perfectly clear now, thanks both of you

Post by Hamish
As to deciding what is suitable for backporting, I am of two minds. On one hand
it is very useful to have some sort of deadline to motivate us to fix as many
old lingering bugs as possible before the release. On the other hand even small
modifications to critical modules like g.region and r.out.gdal days before
release are very dangerous. Those need maximum testing time in the development
branch to avoid nasty unintentional side effects. It has been typical for that
sort of mistake not to be spotted even in the well tested CVS/HEAD version for
months.
A good rule seems to be only backport important bug fixes and well-tested
important updates. Leave anything else to a future release. 6.3.0 is not
intended to be as stable as 6.2, so I wouldn't worry so much about that here,
for 6.3 it becomes more a question of if the backporting justifies the double
effort.

My changes only affect internationalized messages, so they neither fix
important bugs nor should create them, so the effort is the only thing
in mind.
Thanks again for the information.
Carlos

Wolf Bergenheim

2007-10-25 06:41:01 UTC

Hi!

I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?

Ideally I'd have liked to wait for the gmath changes (since v.generalize
can be optimized after that), but I think it is more important to get
the SoC project in our next release (simply so that we can show next
year to the students that if they do good, their code ends up in the
next release).

--Wolf

--
<:3 )---- Wolf Bergenheim ----( 8:>

Paolo Cavallini

2007-10-25 06:44:19 UTC

Post by Wolf Bergenheim
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?

+1 for me.
pc

--
Paolo Cavallini, see: http://www.faunalia.it/pc

Helena Mitasova

2007-10-25 13:45:43 UTC

Post by Wolf Bergenheim
Hi!
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?

I am very much in support of that - but has anybody besides Wolf and
me tested them?
Especially with some other data than spearfish or the new nc data set?
(e.g. latlong, very small scale etc.).

Helena

Post by Wolf Bergenheim
Ideally I'd have liked to wait for the gmath changes (since
v.generalize
can be optimized after that), but I think it is more important to get
the SoC project in our next release (simply so that we can show next
year to the students that if they do good, their code ends up in the
next release).
--Wolf

--
<:3 )---- Wolf Bergenheim ----( 8:>
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

Maris Nartiss

2007-10-25 13:57:49 UTC