[GRASS5] GRASS 5.0.1 released

GRASS GRASS developer
1

Dear GRASS community,

GRASS 5.0.1 is finally released. Thanks to all contributors.
Note that GRASS 5.0.1 comes with just a few changes.

For details see:
http://grass.itc.it/grass5/source/NEWS.html

The major part of interesting bugfixes which are already
uploaded to CVS are not included as requested by some
team members. Potential (!) 5.0.2 changes are listed here:
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/NEWS.html

So we may quickly go for 5.0.2.

I have updated for 5.0.1
- source code
- PDF files
- several HTML pages

The CVS tag for the 5.0.1 release is
"release_28_01_2003_grass5_0_1"

Best regards

Markus Neteler

2

Markus,

I did not realize that r.mapcalc fixes are not included 5.0.1
One reason I do not recomend people using 5.0.0 (and why I don't
use it myself - we use either pre3 or the CVS version)
is that r.mapcalc released with 5.0.0 does not write the command
into the history files - that makes r.mapcalc practically unusable
for any bigger project. I hoped that it will be fixed in 5.0.1
Or am I missing something? Why wasn't the updated r.mapcalc included?
What is the point of releasing 5.0.1 - the fixes there are really
minimal (at least accordining to the news) while the important ones
were not included. Would it be better to wait with the release and get
at least
r.mapcalc and datum projections there. What is holding r.mapcalc ?

thanks,

Helena

Neteler wrote:

Dear GRASS community,

GRASS 5.0.1 is finally released. Thanks to all contributors.
Note that GRASS 5.0.1 comes with just a few changes.

For details see:
http://grass.itc.it/grass5/source/NEWS.html

The major part of interesting bugfixes which are already
uploaded to CVS are not included as requested by some
team members. Potential (!) 5.0.2 changes are listed here:
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/NEWS.html

So we may quickly go for 5.0.2.

I have updated for 5.0.1
- source code
- PDF files
- several HTML pages

The CVS tag for the 5.0.1 release is
"release_28_01_2003_grass5_0_1"

Best regards

Markus Neteler

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

On Tue, Jan 28, 2003 at 04:11:43PM +0100, Markus Neteler wrote:

GRASS 5.0.1 is finally released.

Note that GRASS 5.0.1 comes with just a few changes.

Great! Cool!

4

On Tue, Jan 28, 2003 at 10:36:41AM -0500, Helena wrote:

Markus,

I did not realize that r.mapcalc fixes are not included 5.0.1
One reason I do not recomend people using 5.0.0 (and why I don't
use it myself - we use either pre3 or the CVS version)
is that r.mapcalc released with 5.0.0 does not write the command
into the history files - that makes r.mapcalc practically unusable
for any bigger project. I hoped that it will be fixed in 5.0.1
Or am I missing something? Why wasn't the updated r.mapcalc included?

I am not 100% sure how many r.mapcalc3 fixes reached the release_branch.
In general every developer is responsible to submit an important
fix immediately also to the release_branch.
This question can be only answered by Glynn.

What is the point of releasing 5.0.1 - the fixes there are really
minimal (at least accordining to the news) while the important ones
were not included. Would it be better to wait with the release and get
at least
r.mapcalc and datum projections there. What is holding r.mapcalc ?

You are right. There is not much point in releasing 5.0.1 (only when it
were done already in October after finding the MacOSX bugs). But some
team members didn't like that idea - Glynn and me proposed several
times to release it...

See (there are many more, search for 5.0.1 in 'grass5' archives):
http://grass.itc.it/pipermail/grass5/2002-October/004012.html
http://grass.itc.it/pipermail/grass5/2002-October/004152.html
http://grass.itc.it/pipermail/grass5/2002-October/004140.html
http://grass.itc.it/pipermail/grass5/2002-November/004384.html
http://grass.itc.it/pipermail/grass5/2002-December/004431.html
http://grass.itc.it/pipermail/grass5/2002-December/004487.html

[Sidenote: IMHO the definition of "critical bug" does not apply to
GRASS 5.0.x. As we have modular commands, what means "critial"?
Maybe when talking about library bugs, we can call them critial.
But commands cannot be in a critial state in general, it much
depends on personal preference/needs. If my prefered command(s)
do not work, that's critical, but just for me.
This definition seems to somewhat slow down the release frequency!
See e.g.
  http://grass.itc.it/pipermail/grass5/2002-October/004152.html
]

Also part of the NVIZ updates are missing (etc). I released 5.0.1 in order
to avoid that these minimal changes are published even later which were
ridiculous. After the revert of the d.legend changes I became careful in
sync'ing the release_branch.

At time 5.0.1 and the CVS experimental differ quite a bit, a somewhat
unpleasant situation. And understanding the 'diffs' between 5.0.1 exp and
release is getting really complicated now (at least for me).

It won't make much sense to build all the various binaries (waste of time),
this will become interesting only for 5.0.2.

Conclusion: Please *test* the current experimental version, e.g. r.mapcalc,
  e.g. the new datum transform feature etc. And please post your experiences
  here (or we never know whether a change was successful or not).

  Unfortunately most discussions on improvements (such as changing the
  raster storage to some useful directly structure, 5.1 issues etc.) die
  quickly without results.

Just my 0.02 Euro,

Markus

5

It was always the idea to stablise the 5.0 HEAD branch,
and release 5.0.1 from a fresh release branch.
We still should do this.

Thus 5.0.1 from the old release branch was just intermediate
and for critical bugs. Thus we should go for 5.0.2 from 5.0 CVS HEAD.

And it is okay to fix real non-critical bugs for a
in a 5.0.x release, but not if a release branch has been created.

So if all bugs are fixed, make a release branch for 5.0.2.
On this release branch, please only fix critical_bugs.

On Tue, Jan 28, 2003 at 05:01:20PM +0100, Markus Neteler wrote:

On Tue, Jan 28, 2003 at 10:36:41AM -0500, Helena wrote:
> What is the point of releasing 5.0.1 - the fixes there are really
> minimal (at least accordining to the news) while the important ones
> were not included.

You are right. There is not much point in releasing 5.0.1 (only when it
were done already in October after finding the MacOSX bugs). But some
team members didn't like that idea - Glynn and me proposed several
times to release it...

[Sidenote: IMHO the definition of "critical bug" does not apply to
GRASS 5.0.x. As we have modular commands, what means "critial"?
Maybe when talking about library bugs, we can call them critial.
But commands cannot be in a critial state in general, it much
depends on personal preference/needs. If my prefered command(s)
do not work, that's critical, but just for me.
This definition seems to somewhat slow down the release frequency!
See e.g.
  http://grass.itc.it/pipermail/grass5/2002-October/004152.html
]

The rule to only fix release critical bugs on a release branch
in itself is fine.
We just have to go for a fresh release from the CVS HEAD sooner
which should be about bug fixes and minor feature enhancements only
anyway.

Also part of the NVIZ updates are missing (etc). I released 5.0.1 in order
to avoid that these minimal changes are published even later which were
ridiculous. After the revert of the d.legend changes I became careful in
sync'ing the release_branch.

At time 5.0.1 and the CVS experimental differ quite a bit, a somewhat
unpleasant situation.

Well that should be fine as 5.0 CVS HEAD continued development.
Now that has to be made stable.

Conclusion: Please *test* the current experimental version, e.g. r.mapcalc,
  e.g. the new datum transform feature etc. And please post your experiences
  here (or we never know whether a change was successful or not).

You mean the 5.0 CVS HEAD. :slight_smile:
That is not entirely experimental as this 5.0 CVS tree
should be the more stable CVS tree.
5.1 CVS should be real experimental.

  Unfortunately most discussions on improvements (such as changing the
  raster storage to some useful directly structure, 5.1 issues etc.) die
  quickly without results.

This mostly means that the improvement can be delayed,
because most people don't care.

6

On Tue, Jan 28, 2003 at 07:46:19PM +0100, Bernhard Reiter wrote:

It was always the idea to stablise the 5.0 HEAD branch,
and release 5.0.1 from a fresh release branch.
We still should do this.

This is probably to late. Do you mean 5.0.2?

Thus 5.0.1 from the old release branch was just intermediate
and for critical bugs.

Several important bugfixes didn't reach 5.0.1 due to the restrictions.

Thus we should go for 5.0.2 from 5.0 CVS HEAD.

Right.

And it is okay to fix real non-critical bugs for a
in a 5.0.x release, but not if a release branch has been created.

In my opinion we should avoid subsubversions such as
5.0.0.x.

So if all bugs are fixed, make a release branch for 5.0.2.

Ok, who is doing that? Please keep in mind that this reuqires
quite some work and time. Volunteers... :wink:

On this release branch, please only fix critical_bugs.

On Tue, Jan 28, 2003 at 05:01:20PM +0100, Markus Neteler wrote:

[...]

> [Sidenote: IMHO the definition of "critical bug" does not apply to
> GRASS 5.0.x. As we have modular commands, what means "critial"?
> Maybe when talking about library bugs, we can call them critial.
> But commands cannot be in a critial state in general, it much
> depends on personal preference/needs. If my prefered command(s)
> do not work, that's critical, but just for me.
> This definition seems to somewhat slow down the release frequency!
> See e.g.
> http://grass.itc.it/pipermail/grass5/2002-October/004152.html
> ]

The rule to only fix release critical bugs on a release branch
in itself is fine.
We just have to go for a fresh release from the CVS HEAD sooner
which should be about bug fixes and minor feature enhancements only
anyway.

This is not clear to me, sorry. When creating a new branch from HEAD,
all fixes including new features such as the long awaited datum
transformation etc will reach it (or not?). Or do we count all
as bug fixes and minor feature enhancements?

> Also part of the NVIZ updates are missing (etc). I released 5.0.1 in order
> to avoid that these minimal changes are published even later which were
> ridiculous. After the revert of the d.legend changes I became careful in
> sync'ing the release_branch.

> At time 5.0.1 and the CVS experimental differ quite a bit, a somewhat
> unpleasant situation.

Well that should be fine as 5.0 CVS HEAD continued development.
Now that has to be made stable.

> Conclusion: Please *test* the current experimental version, e.g. r.mapcalc,
> e.g. the new datum transform feature etc. And please post your experiences
> here (or we never know whether a change was successful or not).

You mean the 5.0 CVS HEAD. :slight_smile:

Yes.

That is not entirely experimental as this 5.0 CVS tree
should be the more stable CVS tree.
5.1 CVS should be real experimental.

> Unfortunately most discussions on improvements (such as changing the
> raster storage to some useful directly structure, 5.1 issues etc.) die
> quickly without results.

This mostly means that the improvement can be delayed,
because most people don't care.

Here we have to distinguish between
- developers who don't have time or who don't care
- users who care and are not able to compile CVS HEAD. Especially
   for the users the slow release frequency is a problem:

   E.g. r.mapcalc was fixed weeks ago as well as NVIZ for tcl8.4. But
   only a few people can benefit from this bugfix.

This problem we should resolve soon,

Markus

7

On Wed, Jan 29, 2003 at 10:44:05AM +0100, Markus Neteler wrote:

On Tue, Jan 28, 2003 at 07:46:19PM +0100, Bernhard Reiter wrote:
> It was always the idea to stablise the 5.0 HEAD branch,
> and release 5.0.1 from a fresh release branch.
> We still should do this.

This is probably to late. Do you mean 5.0.2?

Yes, because it is the same idea.

> Thus 5.0.1 from the old release branch was just intermediate
> and for critical bugs.

Several important bugfixes didn't reach 5.0.1 due to the restrictions.

Well if they are really "important"
as a maintainer you could declare them critical.

> Thus we should go for 5.0.2 from 5.0 CVS HEAD.
Right.

> And it is okay to fix real non-critical bugs for a
> in a 5.0.x release, but not if a release branch has been created.

In my opinion we should avoid subsubversions such as
5.0.0.x.

Agreed.

> So if all bugs are fixed, make a release branch for 5.0.2.

Ok, who is doing that? Please keep in mind that this reuqires
quite some work and time. Volunteers... :wink:

We would need somebody to coordinate the release.

> On Tue, Jan 28, 2003 at 05:01:20PM +0100, Markus Neteler wrote:

> The rule to only fix release critical bugs on a release branch
> in itself is fine.
> We just have to go for a fresh release from the CVS HEAD sooner
> which should be about bug fixes and minor feature enhancements only
> anyway.

This is not clear to me, sorry. When creating a new branch from HEAD,
all fixes including new features such as the long awaited datum
transformation etc will reach it (or not?). Or do we count all
as bug fixes and minor feature enhancements?

Once you create a release branch from the CVS HEAD,
that should only exist a short period of time
and only get critical bugfixes.
It contains all bug fixes and minor feature enhancements
which were done after the last release branch was branched.

Further bug fixes and minor features enhancements
will continue to go into HEAD and be contained in the next release branch.

This scheme will motivate us to keep the release branches short lived,
because we want the bug fixes and features with the next releases.

> This mostly means that the improvement can be delayed,
> because most people don't care.

Here we have to distinguish between
- developers who don't have time or who don't care
- users who care and are not able to compile CVS HEAD. Especially
   for the users the slow release frequency is a problem:

   E.g. r.mapcalc was fixed weeks ago as well as NVIZ for tcl8.4. But
   only a few people can benefit from this bugfix.

This problem we should resolve soon,

We should make it more easy and educate more interesting users
to help testing prereleases and possible (still experimental) bug fixes.

8

On Wed, Jan 29, 2003 at 11:06:42AM +0100, Bernhard Reiter wrote:

On Wed, Jan 29, 2003 at 10:44:05AM +0100, Markus Neteler wrote:
> On Tue, Jan 28, 2003 at 07:46:19PM +0100, Bernhard Reiter wrote:

[...]

> > Thus 5.0.1 from the old release branch was just intermediate
> > and for critical bugs.
>
> Several important bugfixes didn't reach 5.0.1 due to the restrictions.

Well if they are really "important"
as a maintainer you could declare them critical.

Please note that I am *one of* the maintainers. It's not possible
for me to maintain 3xx modules. I can only dedicate some fraction of
a day to GRASS code maintenance like most developers.
I have also to control the numerous mailing lists (grass-commit
grass5, grassgui, nvizlist, sqlgrass, statsgrass, weblist, winGRASS)
including spam protection, a bit of RT maintenance, the regular
updates of the web pages (volunteers wanted also here!), the docs,
the grass site, several cronjobs to generate snapshots, find bugs etc.
I do not intend to complain, but time is really limited.

[...]

> > The rule to only fix release critical bugs on a release branch
> > in itself is fine.
> > We just have to go for a fresh release from the CVS HEAD sooner
> > which should be about bug fixes and minor feature enhancements only
> > anyway.
>
> This is not clear to me, sorry. When creating a new branch from HEAD,
> all fixes including new features such as the long awaited datum
> transformation etc will reach it (or not?). Or do we count all
> as bug fixes and minor feature enhancements?

Once you create a release branch from the CVS HEAD,

...someone, not me at time unless it is a single cvs command (which?).

that should only exist a short period of time
and only get critical bugfixes.
It contains all bug fixes and minor feature enhancements
which were done after the last release branch was branched.

We should be careful with opening and closing branches.
Once we already had come confusion in 2001:
http://grass.itc.it/pipermail/grass5/2001-August/000701.html
when two branches were used in parallel.

I just feel that most of the branch sync'ing has been done
by Glynn so far. And we don't know if he wants to continue with
that (he did a great job!).

Further bug fixes and minor features enhancements
will continue to go into HEAD and be contained in the next release branch.

This scheme will motivate us to keep the release branches short lived,
because we want the bug fixes and features with the next releases.

> > This mostly means that the improvement can be delayed,
> > because most people don't care.
>
> Here we have to distinguish between
> - developers who don't have time or who don't care
> - users who care and are not able to compile CVS HEAD. Especially
> for the users the slow release frequency is a problem:
>
> E.g. r.mapcalc was fixed weeks ago as well as NVIZ for tcl8.4. But
> only a few people can benefit from this bugfix.
>
> This problem we should resolve soon,

We should make it more easy and educate more interesting users
to help testing prereleases and possible (still experimental) bug fixes.

Well, we'll see.

More comments are welcome!

Markus

9

More thoughts on this.

If we discuss features for development
than we might miss real developers time.

On the other hand the frequency of releases
do not always depend on developers time.

Every user should know that:

  - Bugs are in the code,
  because we do not get enough help with testing

  - Time is missing for core development,
  because we do not get enough help with non-core develpment tasks

Every interested user can learn non-development tasks:

  - help with the webpages
  
    Knowledge (can be aquired subsequently):
      - HTML-basics (easy)
      - checkout web source via CVS (easy)
      - use diff and send a patch
      - use CVS write access

    Steps:
      - subscribe to weblist
        => Can start answering questions

      - send patches to weblist
      - get CVS write access for webpages

  - help answering user questions

  - help testing intermediate versions

On Wed, Jan 29, 2003 at 11:06:42AM +0100, Bernhard Reiter wrote:

On Wed, Jan 29, 2003 at 10:44:05AM +0100, Markus Neteler wrote:
> On Tue, Jan 28, 2003 at 07:46:19PM +0100, Bernhard Reiter wrote:

> > This mostly means that the improvement can be delayed,
> > because most people don't care.
>
> Here we have to distinguish between
> - developers who don't have time or who don't care
> - users who care and are not able to compile CVS HEAD. Especially
> for the users the slow release frequency is a problem:
>
> E.g. r.mapcalc was fixed weeks ago as well as NVIZ for tcl8.4. But
> only a few people can benefit from this bugfix.
>
> This problem we should resolve soon,

We should make it more easy and educate more interesting users
to help testing prereleases and possible (still experimental) bug fixes.

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

10

On Wed, Jan 29, 2003 at 11:30:59AM +0100, Markus Neteler wrote:

On Wed, Jan 29, 2003 at 11:06:42AM +0100, Bernhard Reiter wrote:
> On Wed, Jan 29, 2003 at 10:44:05AM +0100, Markus Neteler wrote:
> > On Tue, Jan 28, 2003 at 07:46:19PM +0100, Bernhard Reiter wrote:
[...]
> > > Thus 5.0.1 from the old release branch was just intermediate
> > > and for critical bugs.
> >
> > Several important bugfixes didn't reach 5.0.1 due to the restrictions.
>
> Well if they are really "important"
> as a maintainer you could declare them critical.

Please note that I am *one of* the maintainers.

Somebody should be the last to make or finalise decisions.
For GRASS 5.x that certainly is you. :slight_smile:

It's not possiblefor me to maintain 3xx modules.

It does not mean that you need to take all decisions yourself
or maintain each module, but you do know who to ask the right questions.

I can only dedicate some fraction of
a day to GRASS code maintenance like most developers.
I have also to control the numerous mailing lists (grass-commit
grass5, grassgui, nvizlist, sqlgrass, statsgrass, weblist, winGRASS)
including spam protection, a bit of RT maintenance, the regular
updates of the web pages (volunteers wanted also here!), the docs,
the grass site, several cronjobs to generate snapshots, find bugs etc.
I do not intend to complain, but time is really limited.

It is good that you again tell people
how many fine things you do for GRASS!

But I'm not targeting your time,
we need more helping hands!

> Once you create a release branch from the CVS HEAD,

...someone, not me at time unless it is a single cvs command (which?).

It can easily be done,
but I have to look it up to be precise.

> that should only exist a short period of time
> and only get critical bugfixes.
> It contains all bug fixes and minor feature enhancements
> which were done after the last release branch was branched.

We should be careful with opening and closing branches.

A branch is "declared" closed, not physically closed.
The commits should be watched by developers,
and reverted if they go on the wrong branch.

Once we already had come confusion in 2001:
http://grass.itc.it/pipermail/grass5/2001-August/000701.html
when two branches were used in parallel.

That was a special condition araising
because we were not watching closely
and developers did not know.

I just feel that most of the branch sync'ing has been done
by Glynn so far. And we don't know if he wants to continue with
that (he did a great job!).

I also applaud Glynn's work!

11

On Wed, Jan 29, 2003 at 01:13:44PM +0100, Bernhard Reiter wrote:

On Wed, Jan 29, 2003 at 11:30:59AM +0100, Markus Neteler wrote:
> On Wed, Jan 29, 2003 at 11:06:42AM +0100, Bernhard Reiter wrote:
> > On Wed, Jan 29, 2003 at 10:44:05AM +0100, Markus Neteler wrote:
> > > On Tue, Jan 28, 2003 at 07:46:19PM +0100, Bernhard Reiter wrote:

[...]

> > > > Thus 5.0.1 from the old release branch was just intermediate
> > > > and for critical bugs.
> > >
> > > Several important bugfixes didn't reach 5.0.1 due to the restrictions.
> >
> > Well if they are really "important"
> > as a maintainer you could declare them critical.
>
> Please note that I am *one of* the maintainers.

Somebody should be the last to make or finalise decisions.
For GRASS 5.x that certainly is you. :slight_smile:

Mmh, you are maybe expecting too much from me. Do evaluate every
change is not possible for me, neither by time nor by programming
knowledge.
Then it sometimes happened that my personal opinion and opinions of
other developers which good programming background differ (why not!).
In this case I trust them. But not always there is a result, there
are many open issues in the mailing list archives.

[...]

> > that should only exist a short period of time
> > and only get critical bugfixes.
> > It contains all bug fixes and minor feature enhancements
> > which were done after the last release branch was branched.
>
> We should be careful with opening and closing branches.

A branch is "declared" closed, not physically closed.
The commits should be watched by developers,

I am only aware of one/two developer(s) + me who are actively following
this commit mailing list and sometimes comment on submissions.
That's not sufficient to keep control.

and reverted if they go on the wrong branch.

Who will do that?

> Once we already had come confusion in 2001:
> http://grass.itc.it/pipermail/grass5/2001-August/000701.html
> when two branches were used in parallel.

That was a special condition araising
because we were not watching closely
and developers did not know.

Well, the current situation is rather identical, as only a very few
developers watch the commits. IMHO that "special condition" could occur
easily again.

Also several developers with granted CVS write access do not use it (for
personal or technical or other reasons), I am mostly committing for them
(sometimes also Glynn). That means that only a few contributors actively
work with CVS. One reason I have heard from a few potential CVS writers
is that they found CVS already too complicated or had too many troubles
to set up the ssh-CVS etc. When now increasing the frequency of closing
and opening new release branches, these potential CVS writers will probably
not start to actively use CVS.
We should keep things simple and clearly arranged.

Again just my personal impression,

Markus

12

On Wed, Jan 29, 2003 at 01:44:54PM +0100, Markus Neteler wrote:

Also several developers with granted CVS write access do not use it (for
personal or technical or other reasons),

I'd like to hear more of that reasons in detail.

CVS is a lot less difficult than coding itself.
I've personally helped everybody who asked me to set write access up.

I am mostly committing for them (sometimes also Glynn).

Maybe you should resist in more cases. :slight_smile:

That means that only a few contributors actively
work with CVS. One reason I have heard from a few potential CVS writers
is that they found CVS already too complicated or had too many troubles
to set up the ssh-CVS etc.

Please report CVS difficulties like this to me or the list.
CVS and setting up the access is not overly complicated
and we are happy to explain it.

When now increasing the frequency of closing
and opening new release branches, these potential CVS writers will probably
not start to actively use CVS.
We should keep things simple and clearly arranged.

GRASS already is a huge project.
Keeping a stable and maintained code base
with several active developers is complicated and requires some disciplin.
Our CVS approach is quite simple compared to the task.

13

Markus Neteler wrote:

On Tue, Jan 28, 2003 at 10:36:41AM -0500, Helena wrote:
It won't make much sense to build all the various binaries (waste of time),
this will become interesting only for 5.0.2.

Conclusion: Please *test* the current experimental version, e.g. r.mapcalc,
  e.g. the new datum transform feature etc. And please post your experiences
  here (or we never know whether a change was successful or not).

So what should I do with grass in Mandrake contribs? It needs to be
rebuilt anyway (some bot told me so ;-)), and I decided to wait and see
if 5.0.1 would be out.

Should I rebuild 5.0.0, or build 5.0.1 (no difference in the time it
takes), or build 5.0.1 with a patch (which I would get where?) for
r.mapcalc?

Contribs will probably be in freeze in about 4-6 weeks, so waiting for
the next release probably isn't practical.

Regards,
Buchan

--
|--------------Another happy Mandrake Club member--------------|
Buchan Milne Mechanical Engineer, Network Manager
Cellphone * Work +27 82 472 2231 * +27 21 8828820x121
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7

14

Markus Neteler wrote:

> The rule to only fix release critical bugs on a release branch
> in itself is fine.
> We just have to go for a fresh release from the CVS HEAD sooner
> which should be about bug fixes and minor feature enhancements only
> anyway.

This is not clear to me, sorry. When creating a new branch from HEAD,
all fixes including new features such as the long awaited datum
transformation etc will reach it (or not?). Or do we count all
as bug fixes and minor feature enhancements?

The problem with creating a new release branch from HEAD is that it
will contain *everything* which has been committed to HEAD. Anything
which isn't suitable for release would have to be explicitly reverted.

IMHO, anything which breaks backward compatibility with the previous
version shouldn't go in without a compelling reason.

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

15

On Wed, Jan 29, 2003 at 03:52:32PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> > The rule to only fix release critical bugs on a release branch
> > in itself is fine.
> > We just have to go for a fresh release from the CVS HEAD sooner
> > which should be about bug fixes and minor feature enhancements only
> > anyway.
>
> This is not clear to me, sorry. When creating a new branch from HEAD,
> all fixes including new features such as the long awaited datum
> transformation etc will reach it (or not?). Or do we count all
> as bug fixes and minor feature enhancements?

The problem with creating a new release branch from HEAD is that it
will contain *everything* which has been committed to HEAD. Anything
which isn't suitable for release would have to be explicitly reverted.

Exactly. That's why creating a new release branch is plenty of
work.

IMHO, anything which breaks backward compatibility with the previous
version shouldn't go in without a compelling reason.

Do you mean things like datum transformation etc.?

Markus

16

Markus Neteler wrote:

> IMHO, anything which breaks backward compatibility with the previous
> version shouldn't go in without a compelling reason.

Do you mean things like datum transformation etc.?

The usefulness of datum transformation might be considered a
compelling reason for including it. However, it might be worth
requiring the user to set a flag to enable datum transformation.
Failing that, at least the release notice should contain a warning.

In general, any change which would result in a given sequence of
commands producing a different result should be avoided.

OTOH, adding new commands, adding new options, handling cases which
would previously resulted in an error, or "trivial" changes (such as
changing an error message or generating an error rather than a
segfault) are OK.

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

17

Dear GRASS community,

GRASS 5.0.1 is finally released. Thanks to all contributors.

It compiles fine, except for two modules:

1) r.mapcalc3:

/home/mlennert/SRC/grass5.0.1/src/raster/r.mapcalc3
  make -f OBJ.i686-pc-linux-gnu/make.rules

bison -y -d mapcalc.y
mapcalc.y:75.8: parse error, unexpected ":", expecting ";" or "|"
make: *** [y.tab.c] Erreur 1

2) r.weight:

make[1]: Entering directory
`/home/mlennert/SRC/grass5.0.1/src/raster/r.weight/inter'
bison -y -d gis_pars.y
gis_pars.y:71.10: parse error, unexpected ":", expecting ";" or "|"

followed by a bunch of

gis_pars.y:74.6-19: $3 of `weight_cmnd' has no declared type
gis_pars.y:76.6-19: $2 of `weight_cmnd' has no declared type
gis_pars.y:81.6-24: $2 of `weight_cmnd' has no declared type
gis_pars.y:87.6-23: $2 of `weight_cmnd' has no declared type

which I suppose are probably follow-ups of the first error (although I
don't know bison at all.

I start testing...

Moritz

18

Moritz Lennert wrote:

> GRASS 5.0.1 is finally released. Thanks to all contributors.

It compiles fine, except for two modules:

1) r.mapcalc3:

/home/mlennert/SRC/grass5.0.1/src/raster/r.mapcalc3
  make -f OBJ.i686-pc-linux-gnu/make.rules

bison -y -d mapcalc.y
mapcalc.y:75.8: parse error, unexpected ":", expecting ";" or "|"
make: *** [y.tab.c] Erreur 1

2) r.weight:

make[1]: Entering directory
`/home/mlennert/SRC/grass5.0.1/src/raster/r.weight/inter'
bison -y -d gis_pars.y
gis_pars.y:71.10: parse error, unexpected ":", expecting ";" or "|"

followed by a bunch of

gis_pars.y:74.6-19: $3 of `weight_cmnd' has no declared type
gis_pars.y:76.6-19: $2 of `weight_cmnd' has no declared type
gis_pars.y:81.6-24: $2 of `weight_cmnd' has no declared type
gis_pars.y:87.6-23: $2 of `weight_cmnd' has no declared type

which I suppose are probably follow-ups of the first error (although I
don't know bison at all.

Damn. This is fixed in the CVS head, but obviously haven't been merged
into the release branch yet.

Using byacc (Berkeley yacc) or an older version of bison will work.

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

19

Moritz Lennert wrote:

> GRASS 5.0.1 is finally released. Thanks to all contributors.

It compiles fine, except for two modules:

1) r.mapcalc3:

/home/mlennert/SRC/grass5.0.1/src/raster/r.mapcalc3
  make -f OBJ.i686-pc-linux-gnu/make.rules

bison -y -d mapcalc.y
mapcalc.y:75.8: parse error, unexpected ":", expecting ";" or "|"
make: *** [y.tab.c] Erreur 1

2) r.weight:

make[1]: Entering directory
`/home/mlennert/SRC/grass5.0.1/src/raster/r.weight/inter'
bison -y -d gis_pars.y
gis_pars.y:71.10: parse error, unexpected ":", expecting ";" or "|"

followed by a bunch of

gis_pars.y:74.6-19: $3 of `weight_cmnd' has no declared type
gis_pars.y:76.6-19: $2 of `weight_cmnd' has no declared type
gis_pars.y:81.6-24: $2 of `weight_cmnd' has no declared type
gis_pars.y:87.6-23: $2 of `weight_cmnd' has no declared type

which I suppose are probably follow-ups of the first error (although I
don't know bison at all.

Damn. This is fixed in the CVS head, but obviously haven't been merged
into the release branch yet.

Using byacc (Berkeley yacc) or an older version of bison will work.

Could I just copy the relevant files from the HEAD branch ?

Moritz

20

Moritz Lennert wrote:

>> > GRASS 5.0.1 is finally released. Thanks to all contributors.
>>
>> It compiles fine, except for two modules:
>>
>> 1) r.mapcalc3:

>> 2) r.weight:

> Damn. This is fixed in the CVS head, but obviously haven't been merged
> into the release branch yet.
>
> Using byacc (Berkeley yacc) or an older version of bison will work.

Could I just copy the relevant files from the HEAD branch ?

For r.weight, yes.

r.mapcalc has undergone more substantial changes, so the HEAD version
of mapcalc.y isn't compatible with the r.mapcalc source from 5.0.1.

However, the necessary fix to mapcalc.y is trivial; you just need to
add a line containing nothing but an (indented) semicolon after line
73:

program : stmts { $$ = result = $1; }
    ;

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