[GRASS5] Release Management (10 days to go before Freeze)

GRASS GRASS developer
1

Attention: Here speaks the self elected release assisstant!

To all developers. This is a roadmap reminder.

  The code freeze for grass 5.0.0 release is coming up.
  =====================================================

We plan to create the release branch early in the calender week 17
(starting with monday the 22th of april).
Then we will release grass5.0.0pre4 shortly after leading to grass5.0.0.
Only release critical bugs can be fixed on this cvs branch then.
All other have to wait for grass5.0.1.

  This leaves you ten more days to make sure the code you care about
  =================================================================
  is in shape for release.
  ========================

If you wonder what you can do, please help to fix bugs or
classify bugs from the bugtracker.
We have 25 open bugs right now.

We will release GRASS 5.0.0 this way. You've been warned!

2

Bernhard Reiter wrote:

If you wonder what you can do, please help to fix bugs or
classify bugs from the bugtracker.
We have 25 open bugs right now.

That's down to 21 now; I've closed:

#809 [cygwin] s.in.shape dumps core
#903 g.manual on cygwin
#992 g.region Vask problem in lat/long
#998 Vask (curses) problems with KDE terminal

Also, I'm not sure that this one really belongs in the RT:

#942 GRASS 5.1: prequisites for compiling

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

3

On Sat, Apr 13, 2002 at 01:34:28PM +0100, Glynn Clements wrote:

Bernhard Reiter wrote:
> We have 25 open bugs right now.
That's down to 21 now;

Great! I declare Glynn GRASS programmer of the week! :slight_smile:

Also, I'm not sure that this one really belongs in the RT:
#942 GRASS 5.1: prequisites for compiling

You are right in that it is not a GRASS5.0.x bug.
To reflect this I've downgraded its priority.

We have to think if we want to create areas in this queue
for GRASS5.1.x issues. Or maybe an entirely new queue?
We could also have people mail issues about the development versions
directly to the list.

  Bernhard

4

Bernhard Reiter wrote:

> > We have 25 open bugs right now.
> That's down to 21 now;

Great! I declare Glynn GRASS programmer of the week! :slight_smile:

That was easy :wink: I didn't say that I fixed them, just that I closed
the RT entries.

#903 was actually fixed by Andreas around a month ago, and #998 was
closed due to not being a GRASS bug. Also, I fixed #992 back on March
28, but only just closed it.

OTOH, after fixing #809, I found another bug in s.in.shape, namely
that the timestamp wasn't written because the from/to fields weren't
being set. Upon fixing that, I noticed a further bug, that the year
was written as "102", i.e. failing to add 1900 to the tm_year.

On a hunch, I ran a grep for "tm_year", and found a bug in r.topmodel
(which assumed that tm_year was "year % 100", when it's actually
"year - 1900"), so any files generated by r.topmodel will have
reported the year as 2102.

So that's three unreported bugs fixed as well.

BTW, I've also fixed (AFAICT):

#103 s.info crashes if empty "labels|" field present

So, we're down to 20 open bugs. Of those, half are v.* or i.* programs
(which I'm not at all familiar with), and the rest are cases where I
either don't understand the problem, or can't reproduce it. Except
for:

#873 monitor resizing does not work on SOlaris/X11R6.4

which will probably be resolved by the removal of the resize/redraw
code. For more fundamental reasons than #873, which is just due to
some WMs not liking the the WM_NORMAL_HINTS setting.

Basically, a command which works when run by the user from the shell
won't necessarily work (or produce the same result) when run by the
monitor. Particularly if the session handling gets changed in any way.

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

5

Hi Bernhard, hi all,
as you may know some months ago I performed some maintainance
on s.voronoi a s.delaunay... they were just small bug fixes and
feature enhancementes, but the central "Fortune alghorithm" was
not modified. The problem is that this alghoritm doesn't take into
account some border cases, that may appear only with very particular
geometric configurations (four or more cocircular points and the like):
the result is a voronoi diagram or a triangulation that's completely
screwed up... unfortunately I haven't managed to understard Fortune's
source code, so I set up to write a new implementation, but then
I got stuck due to my imminent wedding. So, I think that we should
either remove these modules or inform the user that they may
fail. I'd prefer the latter, since these bug are hard to reproduce
with real data and these modules can't be easily substituted,
but I leave the decision up to you...
Best regards
Andrea Aime

Bernhard Reiter wrote:

Attention: Here speaks the self elected release assisstant!

To all developers. This is a roadmap reminder.

        The code freeze for grass 5.0.0 release is coming up.
        =====================================================

We plan to create the release branch early in the calender week 17
(starting with monday the 22th of april).
Then we will release grass5.0.0pre4 shortly after leading to grass5.0.0.
Only release critical bugs can be fixed on this cvs branch then.
All other have to wait for grass5.0.1.

        This leaves you ten more days to make sure the code you care about
        =================================================================
        is in shape for release.
        ========================

If you wonder what you can do, please help to fix bugs or
classify bugs from the bugtracker.
We have 25 open bugs right now.

We will release GRASS 5.0.0 this way. You've been warned!

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

6

On Mon, Apr 15, 2002 at 08:19:58AM +0200, Andrea Aime wrote:

as you may know some months ago I performed some maintainance
on s.voronoi a s.delaunay... they were just small bug fixes and
feature enhancementes, but the central "Fortune alghorithm" was
not modified.

Yes this was good.

The problem is that this alghoritm doesn't take into
account some border cases, that may appear only with very particular
geometric configurations (four or more cocircular points and the like):
the result is a voronoi diagram or a triangulation that's completely
screwed up...

So, I think that we should
either remove these modules or inform the user that they may
fail. I'd prefer the latter, since these bug are hard to reproduce
with real data and these modules can't be easily substituted,
but I leave the decision up to you...

Can you add a description of these problems to the documentation
so that it ends up in the manpage under BUGS?

If you can then we should leave them in.

Would it be possible to add checks for these border cases so
that a warning could be spit out when running the programs?

Andrea: thanks for the important information.
Please note that I'm not a GRASS user which uses
or knows all GRASS commands or uses GRASS every day.
I'm just the release assisstant to Mr. Neteler (:))
helping him to keep a schedule.
We need your input about what is good or bad to release.

  Bernhard

7

On Sat, Apr 13, 2002 at 06:47:46PM +0100, Glynn Clements wrote:

Bernhard Reiter wrote:

> Great! I declare Glynn GRASS programmer of the week! :slight_smile:

That was easy :wink: I didn't say that I fixed them, just that I closed
the RT entries.

Well you did follow up on all this
and continued working on it.

But you are right: Everybody can become GRASS programmer of the week!
       Just help with a couple of bugs!

OTOH, after fixing #809, I found another bug in s.in.shape, ...
Upon fixing that, I noticed a further bug,
... and found a bug in r.topmodel

So that's three unreported bugs fixed as well.

Good work. Hard to squash all that small little bugs.

So, we're down to 20 open bugs. Of those, half are v.* or i.* programs
(which I'm not at all familiar with), and the rest are cases where I
either don't understand the problem, or can't reproduce it.

You should ask bach the bug reporters on unreproducable problems.
If they stay unreproducable, they are bound to be closed.

#873 monitor resizing does not work on SOlaris/X11R6.4

which will probably be resolved by the removal of the resize/redraw
code. For more fundamental reasons than #873, which is just due to
some WMs not liking the the WM_NORMAL_HINTS setting.

Basically, a command which works when run by the user from the shell
won't necessarily work (or produce the same result) when run by the
monitor. Particularly if the session handling gets changed in any way.

Can be make this code conditional and add a --solaris-resize-fix
to the configure? AFAIK this would please everybody, right?

  Bernhard

8

Bernhard Reiter wrote:

> #873 monitor resizing does not work on SOlaris/X11R6.4
>
> which will probably be resolved by the removal of the resize/redraw
> code. For more fundamental reasons than #873, which is just due to
> some WMs not liking the the WM_NORMAL_HINTS setting.
>
> Basically, a command which works when run by the user from the shell
> won't necessarily work (or produce the same result) when run by the
> monitor. Particularly if the session handling gets changed in any way.

Can be make this code conditional and add a --solaris-resize-fix
to the configure? AFAIK this would please everybody, right?

The bug title isn't necessarily accurate. The problem is actually with
dtwm (and also, IIRC, the BlackBox WM), not Solaris.

Also, it isn't sufficiently serious, IMHO, to warrant messing up
either the XDRIVER code or the configure script with workarounds. If
the WM won't allow you to resize the monitor, you can still use
"d.resize".

Basically, the redraw code was a quick hack, which I now consider to
have been a mistake. It's a poor substitute for genuine display
management, and if it ever causes a non-trivial problem for other
programs, it will be gone.

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

9

Bernhard Reiter wrote:

...

> So, I think that we should
> either remove these modules or inform the user that they may
> fail. I'd prefer the latter, since these bug are hard to reproduce
> with real data and these modules can't be easily substituted,
> but I leave the decision up to you...

Can you add a description of these problems to the documentation
so that it ends up in the manpage under BUGS?

Mmm, I can provide the description but now I have some network
problems at home, where I have the cvs write access... if I provide
the updated man page can someone check it in for me?

If you can then we should leave them in.

Would it be possible to add checks for these border cases so
that a warning could be spit out when running the programs?

Complicated and time consuming, can't do it now (it's just a bit
easier than writing the program again, since I already have
the laid down the new alghoritm in pseudo-code). Anyway it's easy
to spot the problem just by looking at the output... these border
cases are highly destabilizing, the result diagram is really different
from a sane case...

Andrea: thanks for the important information.
Please note that I'm not a GRASS user which uses
or knows all GRASS commands or uses GRASS every day.
I'm just the release assisstant to Mr. Neteler (:))
helping him to keep a schedule.
We need your input about what is good or bad to release.

That's the only bug I'm aware of that's not in the bug tracker :slight_smile:
Ciao
Andrea

10

Haven't gotten any feedback about this.
Do you think it would be wise to have an issue tracker for the
development series of grass?
This would mean for grass5.1.x and later grass5.3.x.

The issues tracker there would be different from the
ones tracked in the grass queue responsible for the stable series.

We could call the queue "grass-dev".
(And I also guess that we at Intevation think about migrating this
to the new upcoming roundup issue tracker, when we set it up.)

Would the developers want this?

Otherwise I think we need an area for grass5.1,
but or "close" or "stall" all bugs that aim for the development version.

  Bernhard

On Sat, Apr 13, 2002 at 03:58:50PM +0200, Bernhard Reiter wrote:

On Sat, Apr 13, 2002 at 01:34:28PM +0100, Glynn Clements wrote:
> Also, I'm not sure that this one really belongs in the RT:
> #942 GRASS 5.1: prequisites for compiling

You are right in that it is not a GRASS5.0.x bug.
To reflect this I've downgraded its priority.

We have to think if we want to create areas in this queue
for GRASS5.1.x issues. Or maybe an entirely new queue?
We could also have people mail issues about the development versions
directly to the list.

11

On Fri, Apr 12, 2002 at 06:39:35PM +0200, Bernhard Reiter wrote:

Attention: Here speaks the self elected release assisstant!

To all developers. This is a roadmap reminder.

  The code freeze for grass 5.0.0 release is coming up.
  =====================================================

We plan to create the release branch early in the calender week 17
(starting with monday the 22th of april).

Hi,

since monday the 22th is not far from today, we all should check

- if GRASS still compiles with the Gmakefile changes
- if all scripts are running due to the g.gisenv change
   (I need a suggestion to upgrade PERL scripts)
- how we tag the modules which should go to the release branch
   (once I wrote tools/cvsbranch.sh for that, but that's pretty
    inconvenient. We should utilize src/CMD/lists/GRASS )
- the d.zoom update should be present to reach consistency
- v.[in|out].shape - working to be released?
- many more issues

Happy hacking,

Markus

12

On Mon, Apr 15, 2002 at 04:07:37PM +0200, Andrea Aime wrote:

Bernhard Reiter wrote:
> > So, I think that we should
> > either remove these modules or inform the user that they may
> > fail. I'd prefer the latter, since these bug are hard to reproduce
> > with real data and these modules can't be easily substituted,
> > but I leave the decision up to you...
>
> Can you add a description of these problems to the documentation
> so that it ends up in the manpage under BUGS?

Mmm, I can provide the description but now I have some network
problems at home, where I have the cvs write access... if I provide
the updated man page can someone check it in for me?

I can check it in for you, if you mail me a suitable patch.
Just a rough description should do it.