[GRASS5] Branching for 5.0.0 ahead

GRASS GRASS developer
1

As self-appointed release assistant
(nobody ever commented on me doing this)
I remind you that our plan is to create the release branch this week.

Thus this is your last chance to speak up that you still need
more hours to check in your stuff.

Do not start big additions to grass5 head branch
without asking on the list.

Work in progress that I've noticed:
  - d.zoom Radim
  - m.in.e00 Michel
  - proj Roger

Please finish as soon as you can and let us know.
If you cannot finish this within the next days,
we might have to back the changes out and delay them to later releases.

As for the procedure:
  Markus, as GRASS project coodinator
  can you work with Glynn to actually create the Release branch?
  Glynn, you have done quite some coding lately on GRASS
  and you know a lot about CVS. Thus it would be great,
  if you could assist Markus here.

  You both have to make sure that the release branch only contains
  useful code we want to release and that you know is stable.

2

Markus, did you get and submitted the new r.sun from Jaro? It should be much
better than the old one.

May I ask somebody to run the latest submitted s.surf.rst with your data to
make sure that
we did not break anything when adding the anisotropy? We tested it, but it
would be useful
to have somebody run it independently (you do not have to test the anisotropy
option as
that is a very special case, but just make sure that you are getting the same
results as before
with some "standard" run).

And if somebody really is bored could you also run v.surf.rst and
r.resamp.rst to double check
that they are working (although this is not critical as these two programs
are not used too often).

The cutting planes still crash nviz, but I did not have time to get the data
to Glynn, but this
is not a critical bug as it works most of the time and also most people do
not use cutting planes.
A note should be included into NVIZ manual.

Helena

Bernhard Reiter wrote:

As self-appointed release assistant
(nobody ever commented on me doing this)
I remind you that our plan is to create the release branch this week.

Thus this is your last chance to speak up that you still need
more hours to check in your stuff.

Do not start big additions to grass5 head branch
without asking on the list.

Work in progress that I've noticed:
        - d.zoom Radim
        - m.in.e00 Michel
        - proj Roger

Please finish as soon as you can and let us know.
If you cannot finish this within the next days,
we might have to back the changes out and delay them to later releases.

As for the procedure:
        Markus, as GRASS project coodinator
        can you work with Glynn to actually create the Release branch?
        Glynn, you have done quite some coding lately on GRASS
        and you know a lot about CVS. Thus it would be great,
        if you could assist Markus here.

        You both have to make sure that the release branch only contains
        useful code we want to release and that you know is stable.

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature

3

Bernhard Reiter wrote:

You both have to make sure that the release branch only contains
useful code we want to release and that you know is stable.

I suggest that:

1. Code which is permanently dead (e.g. because it has been
superseded) should be removed from the trunk first.

2. Code which is currently broken, but which might reasonably be
resurrected in the future, should be disabled (in
src/CMD/lists/GRASS), but included in the source tarballs.

The reasoning behind 2 is that a user who wants the program, and who
has downloaded source code rather than binaries, might be inclined to
have a go at getting the program working. Having to retrieve the code
from CVS might prove too much of an obstacle (particularly for users
who can't use CVS due to a firewall).

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

4

On Mon, Apr 22, 2002 at 01:41:33PM +0100, Glynn Clements wrote:

Bernhard Reiter wrote:

> You both have to make sure that the release branch only contains
> useful code we want to release and that you know is stable.

I suggest that:

1. Code which is permanently dead (e.g. because it has been
superseded) should be removed from the trunk first.

Please go ahead.

2. Code which is currently broken, but which might reasonably be
resurrected in the future, should be disabled (in
src/CMD/lists/GRASS), but included in the source tarballs.

We will not fix bugs on it, thus I'm not sure if it should
belong in the release branch. I'm pretty sure that it should not
go into the tarballs.

We can have another tar ball, like grass5.0.0-brokencode.tar.gz.
Even better would be a tarball of this from the dev cvs.

The reasoning behind 2 is that a user who wants the program, and who
has downloaded source code rather than binaries, might be inclined to
have a go at getting the program working.

Having to retrieve the code
from CVS might prove too much of an obstacle (particularly for users
who can't use CVS due to a firewall).

In reality I do not believe that someone who will try to make a
broken source code run will find this a major obstable.
Additional tarballs would archieve both:
A cleaner separation and easy access to the source code of buggy modules.

  Bernhard

5

Bernhard

on the item 2 I really agree with Glynn - For example, there were few times
when we
wanted to look at the 3D stuff and could not find the code - by the time I
got it separately
from Markus I did not have time to look at it anymore. Many people just would
not go through
the hassle of dowloading extra software to fix the code. Essentially when
somebody
is looking at some functionality, finds it in manuals or knows about it , but
it is not compiled but the code is there
it may take just few hours or days to fix it. It is the time needed to figure
out where that code
is located that is the biggest obstacle.

Helena

Reiter wrote:

On Mon, Apr 22, 2002 at 01:41:33PM +0100, Glynn Clements wrote:
> Bernhard Reiter wrote:
>
> > You both have to make sure that the release branch only contains
> > useful code we want to release and that you know is stable.
>
> I suggest that:
>
> 1. Code which is permanently dead (e.g. because it has been
> superseded) should be removed from the trunk first.

Please go ahead.

> 2. Code which is currently broken, but which might reasonably be
> resurrected in the future, should be disabled (in
> src/CMD/lists/GRASS), but included in the source tarballs.

We will not fix bugs on it, thus I'm not sure if it should
belong in the release branch. I'm pretty sure that it should not
go into the tarballs.

We can have another tar ball, like grass5.0.0-brokencode.tar.gz.
Even better would be a tarball of this from the dev cvs.

> The reasoning behind 2 is that a user who wants the program, and who
> has downloaded source code rather than binaries, might be inclined to
> have a go at getting the program working.

> Having to retrieve the code
> from CVS might prove too much of an obstacle (particularly for users
> who can't use CVS due to a firewall).

In reality I do not believe that someone who will try to make a
broken source code run will find this a major obstable.
Additional tarballs would archieve both:
A cleaner separation and easy access to the source code of buggy modules.

        Bernhard

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature

6

On Mon, Apr 22, 2002 at 02:16:43PM +0200, Bernhard Reiter wrote:

As self-appointed release assistant
(nobody ever commented on me doing this)
I remind you that our plan is to create the release branch this week.

Thus this is your last chance to speak up that you still need
more hours to check in your stuff.

Do not start big additions to grass5 head branch
without asking on the list.

Unless we find such severe things as the g.remove bug which just
killed all my raster maps from 8 month in my mapset, we should not
rush for the branch.

Also it is unclear to me who will tag it, I prefer a script with
some logic inside (reading src/CMD/lists/GRASS).

Due to the g.remove bug I have to re-do a lot of work, so I am
a bit busy.

Work in progress that I've noticed:
  - d.zoom Radim
  - m.in.e00 Michel
  - proj Roger

also:
- v.buffer ?
- s.to.rast update
- new r.sun from Jaro
- m.proj[2] needs the datum update to be synchonized with [rsv].proj
   (it is easier to explain to users that datum transform is not there than
    telling them which modules are updated already - which is great indeed)
- html pages need update for the nad2nad
- what about v.in.shape (hi David)

Please finish as soon as you can and let us know.
If you cannot finish this within the next days,
we might have to back the changes out and delay them to later releases.

If so, who would be doing that?

As for the procedure:
  Markus, as GRASS project coodinator
  can you work with Glynn to actually create the Release branch?

mhhh, see above. some work is needed here.

  Glynn, you have done quite some coding lately on GRASS
  and you know a lot about CVS. Thus it would be great,
  if you could assist Markus here.

  You both have to make sure that the release branch only contains
  useful code we want to release and that you know is stable.

Here we need something recursive: we could make a proposal and need opinions
later since nobody will know all 3xx modules. Before really tagging a few
people should review the list of release candidates.

Then: Is everybody willing to work on the release branch? Just to verify, if
it makes sense to create it.

Markus

7

On Mon, Apr 22, 2002 at 06:09:58AM -0500, Helena wrote:

Markus, did you get and submitted the new r.sun from Jaro? It should be much
better than the old one.

Helena, Jaro,

just uploaded! Thanks for the submission.

Note that I have done a few cosmetics:
- Changed flag text:
   -s Incorporate the shadowing effect of terrain
  to be more clear.
- Updated Gmakefile to new style.

May I ask somebody to run the latest submitted s.surf.rst with your data
to make sure that we did not break anything when adding the anisotropy? We
tested it, but it would be useful to have somebody run it independently
(you do not have to test the anisotropy option as that is a very special
case, but just make sure that you are getting the same results as before
with some "standard" run).

And if somebody really is bored could you also run v.surf.rst and
r.resamp.rst to double check that they are working (although this is not
critical as these two programs are not used too often).

The cutting planes still crash nviz, but I did not have time to get the
data to Glynn, but this is not a critical bug as it works most of the time
and also most people do not use cutting planes. A note should be included
into NVIZ manual.

Should be disable the "labels" and other non-existing things from the NVIZ
menu? To reduce user confusion?

Markus

Bernhard Reiter wrote:

> As self-appointed release assistant
> (nobody ever commented on me doing this)
> I remind you that our plan is to create the release branch this week.
>
> Thus this is your last chance to speak up that you still need
> more hours to check in your stuff.
>
> Do not start big additions to grass5 head branch
> without asking on the list.
>
> Work in progress that I've noticed:
> - d.zoom Radim
> - m.in.e00 Michel
> - proj Roger
>
> Please finish as soon as you can and let us know.
> If you cannot finish this within the next days,
> we might have to back the changes out and delay them to later releases.
>
> As for the procedure:
> Markus, as GRASS project coodinator
> can you work with Glynn to actually create the Release branch?
> Glynn, you have done quite some coding lately on GRASS
> and you know a lot about CVS. Thus it would be great,
> if you could assist Markus here.
>
> You both have to make sure that the release branch only contains
> useful code we want to release and that you know is stable.
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature

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

--
Markus Neteler

ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
     Project on Predictive Models for the Environment
Via Sommarive, 18 - 38050 Povo (Trento), Italia
tel +39 0461 314 -520 (fax -591) http://mpa.itc.it

8

On Mon, Apr 22, 2002 at 02:53:08PM +0200, Bernhard Reiter wrote:

On Mon, Apr 22, 2002 at 01:41:33PM +0100, Glynn Clements wrote:
> Bernhard Reiter wrote:
>
> > You both have to make sure that the release branch only contains
> > useful code we want to release and that you know is stable.
>
> I suggest that:
>
> 1. Code which is permanently dead (e.g. because it has been
> superseded) should be removed from the trunk first.

Please go ahead.

> 2. Code which is currently broken, but which might reasonably be
> resurrected in the future, should be disabled (in
> src/CMD/lists/GRASS), but included in the source tarballs.

We will not fix bugs on it, thus I'm not sure if it should
belong in the release branch. I'm pretty sure that it should not
go into the tarballs.

We can have another tar ball, like grass5.0.0-brokencode.tar.gz.
Even better would be a tarball of this from the dev cvs.

I strongly recommend to keep even (currently) broken code in the
source tarball for some reasons:

- too much work to maintain another tarball
- keep barriers low to access source code
- keep code in one place, makes borrowing from other code more easy
   as if the code is spreaded elsewhere

We have the src/CMD/lists/GRASS list which is working fine for
decades. I do not suggest to keep it forever, but for 5.0. And
from that list it is easy to retrieve the code which is considered
to be functional.

> The reasoning behind 2 is that a user who wants the program, and who
> has downloaded source code rather than binaries, might be inclined to
> have a go at getting the program working.

> Having to retrieve the code
> from CVS might prove too much of an obstacle (particularly for users
> who can't use CVS due to a firewall).

In reality I do not believe that someone who will try to make a
broken source code run will find this a major obstable.
Additional tarballs would archieve both:
A cleaner separation and easy access to the source code of buggy modules.

I am not sure we the additional workload is more that what could be gained
from a separation. An example:
Some time ago I created a src.todo, also there is a notyetuploaded/ in
grass51/. These directories are as dead a possible (although interesting code is
there). They are just out of view. That's why we should not change the
method now just for cosmetics reasons.

Markus

9

Several people seem to favour to keep old or broken code
in the release tar ball and disable the build for it.
Then this will be the case for the 5.0.0 release.

I do not fully buy into the arguments,
but if most people think that it is worth keeping, we keep it.

Some arguments for the sake of arguments are following: :slight_smile:

On Mon, Apr 22, 2002 at 07:38:06PM +0200, Markus Neteler wrote:

On Mon, Apr 22, 2002 at 02:53:08PM +0200, Bernhard Reiter wrote:
> On Mon, Apr 22, 2002 at 01:41:33PM +0100, Glynn Clements wrote:

I strongly recommend to keep even (currently) broken code in the
source tarball for some reasons:

- too much work to maintain another tarball
- keep barriers low to access source code
- keep code in one place, makes borrowing from other code more easy
   as if the code is spreaded elsewhere

This is all a matter of organising this right.

I am not sure we the additional workload is more that what could
be gained from a separation. An example: Some time ago I created a
src.todo, also there is a notyetuploaded/ in grass51/. These
directories are as dead a possible (although interesting code is
there). They are just out of view. That's why we should not change
the method now just for cosmetics reasons.

For me this arguments works the other ways round:
  If everybody know that more code can be obtained,
  they will go and search for it.

10

On Mon, Apr 22, 2002 at 07:14:26PM +0200, Markus Neteler wrote:

On Mon, Apr 22, 2002 at 02:16:43PM +0200, Bernhard Reiter wrote:

Also it is unclear to me who will tag it, I prefer a script with
some logic inside (reading src/CMD/lists/GRASS).

If Glynn would be willing to tag it,
I would appreciate it.

I do not think that a script is needed.
He can just check on a fully tree, delete the stuff we do not want,
modify some files and create the branch.

> Work in progress that I've noticed:
> - d.zoom Radim
> - m.in.e00 Michel
> - proj Roger

also:

The next two seem to be subprojects of the proj update:

- m.proj[2] needs the datum update to be synchonized with [rsv].proj
   (it is easier to explain to users that datum transform is not there than
    telling them which modules are updated already - which is great indeed)
- html pages need update for the nad2nad

The next are probably too late,
they did not react to the warnings.

- v.buffer ?
- s.to.rast update
- what about v.in.shape (hi David)

Note that there will be 5.0.1 as soon as we manage.

> Please finish as soon as you can and let us know.
> If you cannot finish this within the next days,
> we might have to back the changes out and delay them to later releases.

If so, who would be doing that?

Backing out will be on the people who checked this in.
Otherwise you, me or Glynn.

> You both have to make sure that the release branch only contains
> useful code we want to release and that you know is stable.

Here we need something recursive: we could make a proposal and need opinions
later since nobody will know all 3xx modules. Before really tagging a few
people should review the list of release candidates.

In my eyes everybody is constantly reviewing this for the last month.

Then: Is everybody willing to work on the release branch?

Except release critical bug fixes, there will be no "work"
for the release branch. This time we just get it out and will create it.
We had this over and over again.

11

Bernhard Reiter wrote:

> Also it is unclear to me who will tag it, I prefer a script with
> some logic inside (reading src/CMD/lists/GRASS).

If Glynn would be willing to tag it,
I would appreciate it.

I do not think that a script is needed.
He can just check on a fully tree, delete the stuff we do not want,
modify some files and create the branch.

Yes. When creating a branch, tag the entire tree.

The next are probably too late,
they did not react to the warnings.

> - v.buffer ?
> - s.to.rast update
> - what about v.in.shape (hi David)

Note that there will be 5.0.1 as soon as we manage.

A note about version numbers: an increased release number (the third
number) normally indicates a bug-fix release which entirely supersedes
the previous version. IOW, 5.0.1 should be 100% compatible with 5.0.0;
upgrading should not create any new problems, only fix existing ones.

It may be necessary to reserve the minor version number (the second
number) for small but incompatible fixes. That would mean that a
substantially revised version would have to be 6.x.

If 5.1/5.2 were to incorporate fundamental changes, there would be no
reasonable numbering scheme available for an intermediate version,
with less significant, but incompatible, changes.

> Then: Is everybody willing to work on the release branch?

Except release critical bug fixes, there will be no "work"
for the release branch. This time we just get it out and will create it.
We had this over and over again.

Yes. The bottom line is that, once the release branch is created,
5.0.x becomes a specific "product". Anything other than
straightforward bug fixes has to go into 5.1/6.0.

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

12

There is one more issue related to d.rast that was discussed on the list and
I am not sure whether and how
it was resolved . I am not sure whether I am interpreting this correctly but
d.rast does not erase the previously
displayed maps so for example when you run d.what.rast it would query all
raster files previously displayed,
which is quite annoying if you have a lot of them. So one has to run d.erase
first. I think that d.zoom displays all the files too.
Is this behavior still true? (we have it in pre3)
Is it desirable (or too difficult to change)?

thanks,

Helena

13

On Monday 22 April 2002 17:08, Helena wrote:

There is one more issue related to d.rast that was discussed on the list
and I am not sure whether and how
it was resolved . I am not sure whether I am interpreting this correctly
but d.rast does not erase the previously
displayed maps so for example when you run d.what.rast it would query all
raster files previously displayed,
which is quite annoying if you have a lot of them. So one has to run
d.erase first. I think that d.zoom displays all the files too.
Is this behavior still true? (we have it in pre3)
Is it desirable (or too difficult to change)?

Helena,

Sometimes that is a desirable behavior and sometimes it isn't. What the
documentation says is

"if the -o flag is not set by the user, d.rast will (by default) completely
overwrite whatever appears in the active graphics display frame."

I suppose one could argue over what "completely" means, but I get the
impression that a newly displayed raster map should displace any other raster
map already in the display so that it would be no longer visible and no
longer available to queries. The -o option overrides that behavior.

Fixing that is another matter entirely.

Roger Miller

14

We've decided some time ago to try to adapt the Linux kernel
version numbering scheme.

Thus we have a stable line: 5.0.x
and a development line: 5.1.x
Next stable line will be 5.2.x

On Mon, Apr 22, 2002 at 08:37:45PM +0100, Glynn Clements wrote:

Bernhard Reiter wrote:

> Note that there will be 5.0.1 as soon as we manage.

A note about version numbers: an increased release number (the third
number) normally indicates a bug-fix release which entirely supersedes
the previous version. IOW, 5.0.1 should be 100% compatible with 5.0.0;
upgrading should not create any new problems, only fix existing ones.

In general this is true, but we also can have small enhancement in 5.0.1.
We will create a new release branch and so on.

> > Then: Is everybody willing to work on the release branch?
>
> Except release critical bug fixes, there will be no "work"
> for the release branch. This time we just get it out and will create it.
> We had this over and over again.

Yes. The bottom line is that, once the release branch is created,
5.0.x becomes a specific "product". Anything other than
straightforward bug fixes has to go into 5.1/6.0.

The plan is to have the release branch only for the 5.0.0 release.
Then we will merge back.
The grass5 tree will be 5.0.x.

I know that you reasoning is good, but
let's stick to the plan for a while and try it. :slight_smile:

  Bernhard

15

Well, I think a default behavior of displaying raster maps in monitor window should be the monitor "remembers" just current map. So when I use d.what.rast, or resize the monitor window I get just the last map, not last 10-15 maps. Usually then I have to use d.erase and repeat it again.
But I have to say that it is not wrong to have such behavior of d.rast or d.what.rast. But I would add such a option (querying multiple recently displayed maps) as the option explicitly requested by a user (e.g. using -m option in d.what.rast).

Jaro

Roger Miller wrote:

On Monday 22 April 2002 17:08, Helena wrote:

There is one more issue related to d.rast that was discussed on the list
and I am not sure whether and how
it was resolved . I am not sure whether I am interpreting this correctly
but d.rast does not erase the previously
displayed maps so for example when you run d.what.rast it would query all
raster files previously displayed,
which is quite annoying if you have a lot of them. So one has to run
d.erase first. I think that d.zoom displays all the files too.
Is this behavior still true? (we have it in pre3)
Is it desirable (or too difficult to change)?

Helena,

Sometimes that is a desirable behavior and sometimes it isn't. What the documentation says is

"if the -o flag is not set by the user, d.rast will (by default) completely overwrite whatever appears in the active graphics display frame."

I suppose one could argue over what "completely" means, but I get the impression that a newly displayed raster map should displace any other raster map already in the display so that it would be no longer visible and no longer available to queries. The -o option overrides that behavior.

Fixing that is another matter entirely.

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

16

Jaro Hofierka wrote:

Well, I think a default behavior of displaying raster maps in monitor
window should be the monitor "remembers" just current map. So when I use
d.what.rast, or resize the monitor window I get just the last map, not
last 10-15 maps. Usually then I have to use d.erase and repeat it again.
But I have to say that it is not wrong to have such behavior of d.rast
or d.what.rast. But I would add such a option (querying multiple
recently displayed maps) as the option explicitly requested by a user
(e.g. using -m option in d.what.rast).

The problem is that the monitor doesn't really know what a "map" is.
The monitor maintains a set of "pads", which are basically just lists
of strings. The redraw code just traverses specific pads (which are
known to contain display commands), and executes those commands. It
doesn't know that certain commands will obscure the output from other
commands.

Most of the display management is a hack, and is bound to have rough
edges. The only solution is to actually design the interface
architecture, rather than just tacking on features on an ad-hoc basis.

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

17

On Apr 23, Bernhard Reiter wrote:
> We've decided some time ago to try to adapt the Linux kernel
> version numbering scheme.
>
> Thus we have a stable line: 5.0.x
> and a development line: 5.1.x
> Next stable line will be 5.2.x

Bernhard,

Let me summarize things the way I see it to make sure I've got the
plan straight:

1) If users stick to a release that has an even number as the second
   component in the version, they can rest assured that upgrading
   across minor versions, (eg. 5.0.1 to 5.0.2), will not cause
   incompatibilities to be introduced.

2) If a developer wants to introduce and incompatible change, the
   change must take place on the development line with an odd-numbered
   second component, (eg. 5.1).

Am I correct? As far as a system for naming what code gets released,
this seems like a good, working system.

Now, a separate issue entirely, is the system used to develop/manage
the code base, (as opposed to naming it). I think we need some
discussion here, so I'll write something up in a separate email.

-Carl

--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725

18

On Tue, Apr 23, 2002 at 02:55:36PM +0000, Carl Worth wrote:

On Apr 23, Bernhard Reiter wrote:
> We've decided some time ago to try to adapt the Linux kernel
> version numbering scheme.
>
> Thus we have a stable line: 5.0.x
> and a development line: 5.1.x
> Next stable line will be 5.2.x

1) If users stick to a release that has an even number as the second
   component in the version, they can rest assured that upgrading
   across minor versions, (eg. 5.0.1 to 5.0.2), will not cause
   incompatibilities to be introduced.

Basically, but with no major incompatibilities.
Like the kernel, they've had _some_ incompatibilities which cannot
be avoided.

2) If a developer wants to introduce and incompatible change, the
   change must take place on the development line with an odd-numbered
   second component, (eg. 5.1).

Basically correct with the same restriction as above.
You could do some changes in the grass5(0) normal branch,
when development is open.

Am I correct? As far as a system for naming what code gets released,
this seems like a good, working system.

Now, a separate issue entirely, is the system used to develop/manage
the code base, (as opposed to naming it). I think we need some
discussion here, so I'll write something up in a separate email.

Fair enough. :slight_smile:

19

On Mon, Apr 22, 2002 at 09:16:33PM +0200, Bernhard Reiter wrote:

On Mon, Apr 22, 2002 at 07:14:26PM +0200, Markus Neteler wrote:
> On Mon, Apr 22, 2002 at 02:16:43PM +0200, Bernhard Reiter wrote:

If Glynn would be willing to tag it,
I would appreciate it.

> > Work in progress that I've noticed:
> > - d.zoom Radim
> > - m.in.e00 Michel
> > - proj Roger

The next two seem to be subprojects of the proj update:

From what Roger wrote, "proj" and the two subproject seems to be finished.
Please correct me, if I'm wrong.

What about the other two?

Radim?
Michel?
Last E-Mail from Michel was that he wanted time until wednesday.

I did not hear from the other ones below.
Thus we have to delay them.

The next are probably too late,
they did not react to the warnings.

> - v.buffer ?
> - s.to.rast update
> - what about v.in.shape (hi David)

Note that there will be 5.0.1 as soon as we manage.

Glynn, is it possible for you to create a release branch in the next days?
You seem to have a good overview about what you can call compileable.

Calling it something like
  releasebranch_24_April_2002_5_0_0
seems to be consistant with what we've used before.

20

Bernhard Reiter wrote:

Glynn, is it possible for you to create a release branch in the next days?
You seem to have a good overview about what you can call compileable.

Calling it something like
  releasebranch_24_April_2002_5_0_0
seems to be consistant with what we've used before.

Sure. Just say when.

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