Hi,
what is the current release branch? I thought that
release_25_06_2002_grass5_0_0_pre5 was branch and
release_30_08_2002_grass5_0_0 is only tag on that branch.
Is that true? How can I get more info about tags (tag x branch etc.)?
Radim
Radim Blazek wrote:
what is the current release branch? I thought that
release_25_06_2002_grass5_0_0_pre5 was branch and
release_30_08_2002_grass5_0_0 is only tag on that branch.
Is that true?
No.
The branch is called "releasebranch_26_april_2002_5_0_0".
"release_25_06_2002_grass5_0_0_pre5" is the non-branch tag
corresponding to -pre5. "release_30_08_2002_grass5_0_0" is the
non-branch tag corresponding to the final 5.0.0 release.
How can I get more info about tags (tag x branch etc.)?
"cvs status -v file" gives a list of all tags which exist for that
file; the tags will be followed by "(branch: ...)" for a branch tag
and "(revision: xxx)" for a non-branch tag.
--
Glynn Clements <glynn.clements@virgin.net>
On Wed, Oct 09, 2002 at 07:03:40PM +0200, Radim Blazek wrote:
what is the current release branch?
Thanks for Glynns explainations.
I'd like to add
that our original plan was
to now have a time period with open development on HEAD.
And then make a fresh branch with a fix critical bugs only freeze
for an upcoming 5.0.1 release.
The only strong reason to deviate from this plan would be
that we've found some _grave_ misstakes in the 5.0.0 release
and need to make a quick 5.0.1 release to only fix these _grave_
errors from the current (old) release branch.
Markus: What do you think?
So the original question strictly would be answered:
There is no active release branch for grass50,
because work should currently be done in HEAD.
Bernhard Reiter wrote:
I'd like to add
that our original plan was
to now have a time period with open development on HEAD.And then make a fresh branch with a fix critical bugs only freeze
for an upcoming 5.0.1 release.The only strong reason to deviate from this plan would be
that we've found some _grave_ misstakes in the 5.0.0 release
and need to make a quick 5.0.1 release to only fix these _grave_
errors from the current (old) release branch.
A couple of the r.mapcalc bugs are pretty important. Also, it would be
nice to fix some of the Mac issues sooner rather than later (some of
them aren't actually Mac-specific, e.g. the round() problem).
Markus: What do you think?
So the original question strictly would be answered:
There is no active release branch for grass50,
because work should currently be done in HEAD.
Actually, I was about to commit a batch of fixes to the release
branch. Basically these either fix significant problems, or fix minor
problems but are so trivial as to have no potential drawbacks.
These are:
configure[.in]
check for keypad() in lib[n]curses
look for freetype/freetype.h, not ft2build.h
Makefile.in
srcdist target has code relative to grass-${VERSION}
move removal of version.h/winname.h from clean to distclean
src/include/config.h.in
Add HAVE_KEYPAD
mk/mid.mk
mk/mid.mk.shlib
src/CMD/generic/make.mid
lib*edit -> lib*gedit
html/html/r.stats.html
Remove -z
src.contrib/GMSL/g3d/src3d/sites/s.vol.rst/*
Get malloc() prototype from <stdlib.h>
src/display/devices/PNGdriver/Gmakefile
Add to monitorcap unconditionally
src/imagery/i.pca/cmd/main.c
round() -> round_c() (C9X fix)
src/display/d.zoom/cmd/set.c
round() -> round_to() (C9X fix)
src/libes/gis/get_row.c
Make G_get_map_row() respect the mask
src/libes/vask/V_exit.c
src/libes/vask/V_init.c
Only use keypad() if it exists
src/libes/vect32/georef/Gmakefile
src/libes/vect32/georef/geo_file.c
src/libes/vect32/georef/vars.c (removed)
Move globals from vars.c to geo_file.c (Mac linker issue)
src/raster/r.mapcalc3/evaluate.c
src/raster/r.mapcalc3/expression.c
src/raster/r.mapcalc3/map.c
src/raster/r.mapcalc3/mapcalc.h
src/raster/r.mapcalc3/mapcalc.y
src/raster/r.mapcalc3/mapcalc.l
Fix for fully-qualified mapnames
Fix arity of not() function
Fix/improve end-of-input handling
Improve error handling
src/raster/r.sun/main.c
Don't include (bogus) <malloc.h>
Key_value -> Key_Value
html/imagery.html
remove i.tape.tm3
src/scripts/contrib/grassmirrorsmap/grass.sites.mirror
Fix Taiwan URL
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, Oct 10, 2002 at 05:24:54PM +0100, Glynn Clements wrote:
A couple of the r.mapcalc bugs are pretty important.
Actually, I was about to commit a batch of fixes to the release
branch. Basically these either fix significant problems, or fix minor
problems but are so trivial as to have no potential drawbacks.
Can I take this as pledge for a relatively fast non-critical
release of 5.0.1 based on the release branch?
The alternative would be to finish 5.0.1 up more properly.
We would have one month open development (minor new features,
minor bugfixes) on HEAD than create the 5.0.1 release branch
and go to bugfixing only on this branch and release after a month.
Really important bugs to 5.0.0 could be distributed as patches
in the meantime. So commiting them on the release branch in addition
to HEAD is not a mistake. 
With the arguments presented to me so far
I still tend to favour the latter approach.
Bernhard Reiter wrote:
> A couple of the r.mapcalc bugs are pretty important.
> Actually, I was about to commit a batch of fixes to the release
> branch. Basically these either fix significant problems, or fix minor
> problems but are so trivial as to have no potential drawbacks.Can I take this as pledge for a relatively fast non-critical
release of 5.0.1 based on the release branch?
I would like to see 5.0.1 released sooner rather than later, as we
already have an initial "batch" of bug reports to process.
The alternative would be to finish 5.0.1 up more properly.
We would have one month open development (minor new features,
minor bugfixes) on HEAD than create the 5.0.1 release branch
and go to bugfixing only on this branch and release after a month.
I wouldn't do a "5.0.1 release branch". The more logical course is to
merge the fixes into the generic "release branch", so 5.0.0 and 5.0.1
would just be two different snapshots of the same branch.
IMHO, all "development" should be moved to 5.1. But first we need to
sort out the specifics of the transition.
One issue which should be settled first is to choose a common coding
convention. That way, we can populate the 5.1 tree with files which
have already been formatted, so that everyone doesn't end up
downloading the same files twice (reformatting tends to change every
line, so "cvs update" will retrieve the entire file).
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, Oct 10, 2002 at 07:50:16PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> Can I take this as pledge for a relatively fast non-critical
> release of 5.0.1 based on the release branch?
I would like to see 5.0.1 released sooner rather than later, as we
already have an initial "batch" of bug reports to process.
Each release needs to have a test period.
I think a two month plan which usually gets executed in three month
is pretty fast to have another stable release.
> The alternative would be to finish 5.0.1 up more properly.
> We would have one month open development (minor new features,
> minor bugfixes) on HEAD than create the 5.0.1 release branch
> and go to bugfixing only on this branch and release after a month.I wouldn't do a "5.0.1 release branch". The more logical course is to
merge the fixes into the generic "release branch", so 5.0.0 and 5.0.1
would just be two different snapshots of the same branch.
We've deceided against a "generic" release branch a while ago
and I hope we stick for the plan at least for a couple of releases
to see how that works out. The release branch will only be for
testing and fixing release critical bugs.
IMHO, all "development" should be moved to 5.1. But first we need to
sort out the specifics of the transition.
Again we have a special situation with GRASS here.
Some development must be allowed on 5.0 and this is basically
possible on HEAD all the time. However we want encourage people to
help move GRASS over to 5.1 and mainly improve the structure.
So radically new things should not go on 5.0 only bug fixes and
_minor_ feature development.
So goal is to get GRASS 5.0.x a very stable line
in the current structure (including the structural drawbacks).
One issue which should be settled first is to choose a common coding
convention. That way, we can populate the 5.1 tree with files which
have already been formatted, so that everyone doesn't end up
downloading the same files twice (reformatting tends to change every
line, so "cvs update" will retrieve the entire file).
The file structure should come first and library normalisation second.
This goes along with a proper makefile system.
Coding convention is third.
[I have separated below from the original branch thread]
On Fri, Oct 11, 2002 at 12:19:32PM +0200, Bernhard Reiter wrote:
On Thu, Oct 10, 2002 at 07:50:16PM +0100, Glynn Clements wrote:
> One issue which should be settled first is to choose a common coding
> convention. That way, we can populate the 5.1 tree with files which
> have already been formatted, so that everyone doesn't end up
> downloading the same files twice (reformatting tends to change every
> line, so "cvs update" will retrieve the entire file).The file structure should come first and library normalisation second.
This goes along with a proper makefile system.
Coding convention is third.
Let us start to develop a "road-map" for the 5.0 to 5.1 migration.
Bernhard's proposal is (slightly modified):
1. select important modules (perhaps 5-10 per function class r.*, d.* etc.)
2. run code reformatting software (below is from Apache):
indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 <files>
3. add them reformatted to grass51/ in CVS, using new directory structure
4. apply new Makefile system
5. start library clean up, clone elimination etc. on these modules/libs
6. release
7. add more modules etc.
-----
Suggestion for (1.): could we modify "front_end" to generate statistics
how often which module was used? Then it will be pretty easy to identify
the most wanted modules without digging in .bash_history etc.
Markus
On Fri, Oct 11, 2002 at 02:23:35PM +0200, Markus Neteler wrote:
[I have separated below from the original branch thread]
On Fri, Oct 11, 2002 at 12:19:32PM +0200, Bernhard Reiter wrote:
> On Thu, Oct 10, 2002 at 07:50:16PM +0100, Glynn Clements wrote:
> > One issue which should be settled first is to choose a common coding
> > convention. That way, we can populate the 5.1 tree with files which
> > have already been formatted, so that everyone doesn't end up
> > downloading the same files twice (reformatting tends to change every
> > line, so "cvs update" will retrieve the entire file).
>
> The file structure should come first and library normalisation second.
> This goes along with a proper makefile system.
> Coding convention is third.Let us start to develop a "road-map" for the 5.0 to 5.1 migration.
Bernhard's proposal is (slightly modified):
Not really mime, but something that I've had in mind.
1. select important modules (perhaps 5-10 per function class r.*, d.* etc.)
2. run code reformatting software (below is from Apache):
indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 <files>
Does that help much? The complete file has to be reread and controlled
by a human than. I'd rather not use such a tool.
The formatting might be bad, but on the other important information
can get lost with the new formatting.
3. add them reformatted to grass51/ in CVS, using new directory structure
4. apply new Makefile system
5. start library clean up, clone elimination etc. on these modules/libs
6. release
You mean release GRASS 5.2
or a development version?
7. add more modules etc.
An important improvement has to be to distinquish between GRASS modules
(core and for tasts) and add-on modules and thus the ability to split
GRASS development up further.
Suggestion for (1.): could we modify "front_end" to generate statistics
how often which module was used? Then it will be pretty easy to identify
the most wanted modules without digging in .bash_history etc.
I hope that we cen get rid of front_end soon anyway.
Just counting would not help much. There is also the matter of importance.
On Fri, Oct 11, 2002 at 02:23:35PM +0200, Markus Neteler wrote:
Let us start to develop a "road-map" for the 5.0 to 5.1 migration.
It is more a "transition" of the development.
I would reserve the word migration for producation software with
data.
Bernhard Reiter wrote:
> > Can I take this as pledge for a relatively fast non-critical
> > release of 5.0.1 based on the release branch?> I would like to see 5.0.1 released sooner rather than later, as we
> already have an initial "batch" of bug reports to process.Each release needs to have a test period.
I think a two month plan which usually gets executed in three month
is pretty fast to have another stable release.
Bear in mind that the only things which I have committed to the
release branch have been bug fixes.
> > The alternative would be to finish 5.0.1 up more properly.
> > We would have one month open development (minor new features,
> > minor bugfixes) on HEAD than create the 5.0.1 release branch
> > and go to bugfixing only on this branch and release after a month.
>
> I wouldn't do a "5.0.1 release branch". The more logical course is to
> merge the fixes into the generic "release branch", so 5.0.0 and 5.0.1
> would just be two different snapshots of the same branch.We've deceided against a "generic" release branch a while ago
and I hope we stick for the plan at least for a couple of releases
to see how that works out. The release branch will only be for
testing and fixing release critical bugs.
Which is all that I've been committing. 5.0.1 ought to just be bug
fixes, so that it entirely supersedes 5.0.0. Any incompatible change,
however minor and however much it is considered an "improvement",
needs to be kept separate, so that users who value stability over all
else can still get bug fixes.
> One issue which should be settled first is to choose a common coding
> convention. That way, we can populate the 5.1 tree with files which
> have already been formatted, so that everyone doesn't end up
> downloading the same files twice (reformatting tends to change every
> line, so "cvs update" will retrieve the entire file).The file structure should come first and library normalisation second.
This goes along with a proper makefile system.
Coding convention is third.
The advantage of performing the reformatting at the outset is that
developers don't have to download every file twice.
--
Glynn Clements <glynn.clements@virgin.net>
Bernhard Reiter wrote:
> 2. run code reformatting software (below is from Apache):
> indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 <files>
I personally don't care about the exact style chosen, but I
definitely feel that we should solicit comments first.
Does that help much? The complete file has to be reread and controlled
by a human than. I'd rather not use such a tool.
The formatting might be bad, but on the other important information
can get lost with the new formatting.
Yes, it matters. If you are making a change to dozens of files which
are spread across the entire tree (and I expect to be doing a lot of
that), you don't want to have to manually change your editor's
formatting style on every single file.
Similarly, if you are analysing or eliminating "cloned" code, it's a
lot easier if you can just use "diff" (which won't work if the two
instances are formatted differently).
For any large software project, a single formatting style is
essential. It really doesn't matter what that style is, so long as its
the same for every file.
--
Glynn Clements <glynn.clements@virgin.net>
I agree that a common code style is important.
My point was that automatic reformatting has to be followed
by human inspection. If there is no human inspection I'd not
recommend a massive automatic reformatting.
Thus when you actually do development you can do the reformatting.
Also possible as preprocessing step for automatic clone detection.
We could look into the GNU coding styles...
On Fri, Oct 11, 2002 at 07:06:16PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> > 2. run code reformatting software (below is from Apache):
> > indent -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1 <files>I personally don't care about the exact style chosen, but I
definitely feel that we should solicit comments first.> Does that help much? The complete file has to be reread and controlled
> by a human than. I'd rather not use such a tool.
> The formatting might be bad, but on the other important information
> can get lost with the new formatting.Yes, it matters. If you are making a change to dozens of files which
are spread across the entire tree (and I expect to be doing a lot of
that), you don't want to have to manually change your editor's
formatting style on every single file.Similarly, if you are analysing or eliminating "cloned" code, it's a
lot easier if you can just use "diff" (which won't work if the two
instances are formatted differently).For any large software project, a single formatting style is
essential. It really doesn't matter what that style is, so long as its
the same for every file.
On Fri, Oct 11, 2002 at 06:55:39PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> > > Can I take this as pledge for a relatively fast non-critical
> > > release of 5.0.1 based on the release branch?
>
> > I would like to see 5.0.1 released sooner rather than later, as we
> > already have an initial "batch" of bug reports to process.
>
> Each release needs to have a test period.
> I think a two month plan which usually gets executed in three month
> is pretty fast to have another stable release.Bear in mind that the only things which I have committed to the
release branch have been bug fixes.
I know, still it needs a test period before release.
> We've deceided against a "generic" release branch a while ago
> and I hope we stick for the plan at least for a couple of releases
> to see how that works out. The release branch will only be for
> testing and fixing release critical bugs.Which is all that I've been committing. 5.0.1 ought to just be bug
fixes, so that it entirely supersedes 5.0.0. Any incompatible change,
however minor and however much it is considered an "improvement",
needs to be kept separate, so that users who value stability over all
else can still get bug fixes.
Our plan was to only have "critical bug" fixes on the release branch.
Minor improvements have to possible in the 5.0.x line.
Otherwise we paralize development too much. At least this was feared.
And then there are bugs that basically somewhere in between
a real bug and an improvement.
Additionally, even if we come up with new arguments,
we should stick with this plan at least for a while for consistancy
reasons before trying new schemes.
> > One issue which should be settled first is to choose a common coding
> > convention. That way, we can populate the 5.1 tree with files which
> > have already been formatted, so that everyone doesn't end up
> > downloading the same files twice (reformatting tends to change every
> > line, so "cvs update" will retrieve the entire file).
>
> The file structure should come first and library normalisation second.
> This goes along with a proper makefile system.
> Coding convention is third.The advantage of performing the reformatting at the outset is that
developers don't have to download every file twice.
Well true, but I think of this as a minor advantage.
Bernhard Reiter wrote:
> > We've deceided against a "generic" release branch a while ago
> > and I hope we stick for the plan at least for a couple of releases
> > to see how that works out. The release branch will only be for
> > testing and fixing release critical bugs.
>
> Which is all that I've been committing. 5.0.1 ought to just be bug
> fixes, so that it entirely supersedes 5.0.0. Any incompatible change,
> however minor and however much it is considered an "improvement",
> needs to be kept separate, so that users who value stability over all
> else can still get bug fixes.Our plan was to only have "critical bug" fixes on the release branch.
Minor improvements have to possible in the 5.0.x line.
So, if the 5.0.x versions are going to include minor improvements,
what will the bugfix-only versions be called? 5.0.0.x?
There isn't much point adding code to a release branch unless it
actually gets "released"; at which point, you need to pick a version
number.
> > > One issue which should be settled first is to choose a common coding
> > > convention. That way, we can populate the 5.1 tree with files which
> > > have already been formatted, so that everyone doesn't end up
> > > downloading the same files twice (reformatting tends to change every
> > > line, so "cvs update" will retrieve the entire file).
> >
> > The file structure should come first and library normalisation second.
> > This goes along with a proper makefile system.
> > Coding convention is third.
>
> The advantage of performing the reformatting at the outset is that
> developers don't have to download every file twice.Well true, but I think of this as a minor advantage.
It's probably only a minor advantage for those who pay a flat-rate
charge, or whose bandwidth is supplied by their employer, or who
derive some form of revenue from GRASS. However, none of those apply
to me, so I consider it a more substantial advantage.
Apart from bandwidth, there's also the issue that it complicates the
processes of performing "cvs diff" between pre- and post-formatted
versions, or performing "cvs diff" between two pre-formatted versions
and comparing the output to a post-formatted version.
--
Glynn Clements <glynn.clements@virgin.net>
Bernhard Reiter wrote:
I agree that a common code style is important.
My point was that automatic reformatting has to be followed
by human inspection.
Why? indent understands enough of C not to change the semantics of the
code. Outside of string literals and preprocessor directives, all
whitespace is equal.
If there is no human inspection I'd not
recommend a massive automatic reformatting.Thus when you actually do development you can do the reformatting.
Also possible as preprocessing step for automatic clone detection.We could look into the GNU coding styles...
indent understands the GNU, K&R, and Berkely predefined styles;
these are documented in the indent manpage.
More generally, I do think that the reformatting should be done
"aggressively", i.e. wherever you have a choice of "--foo" or
"--no-foo", you should choose one of them.
--
Glynn Clements <glynn.clements@virgin.net>
On Fri, Oct 11, 2002 at 08:56:39PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> > > We've deceided against a "generic" release branch a while ago
> > > and I hope we stick for the plan at least for a couple of releases
> > > to see how that works out. The release branch will only be for
> > > testing and fixing release critical bugs.
> >
> > Which is all that I've been committing. 5.0.1 ought to just be bug
> > fixes, so that it entirely supersedes 5.0.0. Any incompatible change,
> > however minor and however much it is considered an "improvement",
> > needs to be kept separate, so that users who value stability over all
> > else can still get bug fixes.
>
> Our plan was to only have "critical bug" fixes on the release branch.
> Minor improvements have to possible in the 5.0.x line.So, if the 5.0.x versions are going to include minor improvements,
what will the bugfix-only versions be called? 5.0.0.x?
This comes down on what a bug fix is.
There isn't much point adding code to a release branch unless it
actually gets "released"; at which point, you need to pick a version
number.
Yep, there is not much point to add code the the branch now.
5.0.1 will be basically a bug-fix release in about three month.
But this does not mean it won't have any improvements in.
As written above if we want to make a critical bugfix-only release
fast (next week) we could utilise the old release branch once more
and call that release 5.0.1. But _only_ if we have major critical bugs.
The whole issue is about how critical a bug or improvement is
and what the time frames are. Of course I do appreciate your efforts
to speed GRASS releases up again, but we still have chew on
having a stable and a development line. We just did the first stable
release of GRASS 5!
[ about reformatting ]
> Well true, but I think of this as a minor advantage.
Apart from bandwidth, there's also the issue that it complicates the
processes of performing "cvs diff" between pre- and post-formatted
versions, or performing "cvs diff" between two pre-formatted versions
and comparing the output to a post-formatted version.
If we stick with reformatting when a human will control it,
which basically means relaxed reformatting you will not
have to download all files a second time a once.
On Fri, Oct 11, 2002 at 09:08:35PM +0100, Glynn Clements wrote:
Bernhard Reiter wrote:
> I agree that a common code style is important.
>
> My point was that automatic reformatting has to be followed
> by human inspection.Why? indent understands enough of C not to change the semantics of the
code. Outside of string literals and preprocessor directives, all
whitespace is equal.
Some content is hidden in the structure of code and non-code.
Not a lot, though but it might be decisive.
> If there is no human inspection I'd not
> recommend a massive automatic reformatting.
>
> Thus when you actually do development you can do the reformatting.
> Also possible as preprocessing step for automatic clone detection.
>
> We could look into the GNU coding styles...indent understands the GNU, K&R, and Berkely predefined styles;
these are documented in the indent manpage.More generally, I do think that the reformatting should be done
"aggressively", i.e. wherever you have a choice of "--foo" or
"--no-foo", you should choose one of them.
Actually I'm beginning to agree with you that we should do as much
reformatting as we can before inserting files in the Grass 5.1 cvs.
Bernhard Reiter wrote:
On Fri, Oct 11, 2002 at 09:08:35PM +0100, Glynn Clements wrote:
[...]
Actually I'm beginning to agree with you that we should do as much
reformatting as we can before inserting files in the Grass 5.1 cvs.
I just read the indent manual page and this let me think that we should
also agree on the style (there is so many options in indent that you
can format each file differently 
Michel.
can't we use the kde development tools to port whole of the grass into a
good looking GUI( prepared by the gui tools available in linux)
so that we have a better ERDAs IMAGINE type interface.
-ojaswa