[GRASS5] bugs

GRASS GIS GRASS GIS developer
1

Hi Paolo,

just saw this one:

"I would therefore ask thos who opended the bugs to please check if they still
hold true, and to remove those that have been solved (I am reasonably sure
many of them have been, but I cannot check e.g. those on MacOSX, etc.
I can give some help if needed.
Also, please note that several wishes may not apply anymore (especially after
3 or 4 years).
"

Please note that many bug reporters won't see above message to
this list.

The recommended method is to
- enter such a bug and add a "reply" (not a "comment" as this won't trigger
  a mail AFAIK), asking if the report is still valid, mentioning also
  the new 6.0.0beta2.
- wait a couple of days and close it if there was no response
  and the bug obviously outdated

It's not an exciting job, but quite important to get the impressive
number of meanwhile useless reports down.

Thanks for your help,

Markus

2

ok, I'll try to do that in the spare time (which time?).
All the best.
pc

At 18:41, venerdì 25 febbraio 2005, Markus Neteler has probably written:

Hi Paolo,

just saw this one:

"I would therefore ask thos who opended the bugs to please check if they
still hold true, and to remove those that have been solved (I am reasonably
sure many of them have been, but I cannot check e.g. those on MacOSX, etc.
I can give some help if needed.
Also, please note that several wishes may not apply anymore (especially
after 3 or 4 years).
"

Please note that many bug reporters won't see above message to
this list.

The recommended method is to
- enter such a bug and add a "reply" (not a "comment" as this won't trigger
  a mail AFAIK), asking if the report is still valid, mentioning also
  the new 6.0.0beta2.
- wait a couple of days and close it if there was no response
  and the bug obviously outdated

It's not an exciting job, but quite important to get the impressive
number of meanwhile useless reports down.

Thanks for your help,

Markus

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

--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

3

- wait a couple of days and close it if there was no response
  and the bug obviously outdated

               ^^^^^^^^^^^^^^^^^^^

Shouldn't we keep a list of known GRASS 5.4 bugs somewhere rather than
just forgetting about them? e.g. 5.4's v.digit "won't fix" bugs.

I think we need to have some sort of "confirmed", "unreproducable", or
"new" tag column for bugs, so we can separate out valid bugs from
misconfigured systems at least, giving a more realistic bug number.

We should not be closing bug reports just because there are a lot of bug
reports. Clean up the bug list, sure; as long as it is by actually
fixing bugs, and not just forgetting them!

Hamish

4

At 06:20, sabato 26 febbraio 2005 you presumably wrote:

Shouldn't we keep a list of known GRASS 5.4 bugs somewhere rather than
just forgetting about them? e.g. 5.4's v.digit "won't fix" bugs.

Agreed. In my view, the best solution is to make two bugs lists, one for 5.4
and one for 6.0. Then I volunteer to manage the 6.0 bugs, changing grass57 to
grass60 where appropriate. Bernhard, would this be possible?
BTW: where do I find the total number of bugs?

I think we need to have some sort of "confirmed", "unreproducable", or
"new" tag column for bugs, so we can separate out valid bugs from
misconfigured systems at least, giving a more realistic bug number.

or, old and unreproducible bugs could be just squashed?

We should not be closing bug reports just because there are a lot of bug
reports. Clean up the bug list, sure; as long as it is by actually
fixing bugs, and not just forgetting them!

Right. But it is also necessary to get rid of the rubbish, otherwise we'll
scare new users away (and, in my view, what grass needs now is a larger user
base).

All the best.
pc
--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

5

> Shouldn't we keep a list of known GRASS 5.4 bugs somewhere rather
> than just forgetting about them? e.g. 5.4's v.digit "won't fix"
> bugs.

Agreed. In my view, the best solution is to make two bugs lists, one
for 5.4 and one for 6.0.

We already have these 8 "Areas":
None
RCbug
bug
grass5.0
grass5.4
grass5.7
wish
wish5.7

Click on the /\ \/ arrows at the top of the bug list to sort by type.

Adding "Area" to "Queue Filter" options at bottom of main bug list might
help clear here.

These could be updated to:
None
RCbug
grass5.0
grass5.4
wish5.4
grass6
wish6

Then I volunteer to manage the 6.0 bugs,
changing grass57 to grass60 where appropriate.

Isn't it always appropriate? They are the same thing.

I think the most important thing is to tag 5.0/5.4 only bugs to "area"
grass5.0 or grass5.4 or wish5.4 and set "priority" on 5.7+ bugs/wishes.

BTW: where do I find the total number of bugs?

I don't know if there is a better way than to sort by area/type and count
by hand?

> I think we need to have some sort of "confirmed", "unreproducable",
> or "new" tag column for bugs, so we can separate out valid bugs from
> misconfigured systems at least, giving a more realistic bug number.

or, old and unreproducible bugs could be just squashed?

GRASS is a huge program with many rare bugs. One can never test all
platforms/setups, so you can never say unreproducible==mistaken report.
Even if it is a mistake, if one person did it, others might as well, and
the others in the future might figure it out & post a solution.
Just deleting the contributed user experience would be a big mistake,
IMO.

> We should not be closing bug reports just because there are a lot of
> bug reports. Clean up the bug list, sure; as long as it is by
> actually fixing bugs, and not just forgetting them!

Right. But it is also necessary to get rid of the rubbish, otherwise
we'll scare new users away (and, in my view, what grass needs now is
a larger user base).

The bug list is not a marketing tool! The bug list is not a marketing tool!

Make default "priority" and "area" tag queue filter limits if you want
trim.

If a new user finds an obscure bug, the best thing that can happen is
for them to see that someone else has already found it and a solution is
being worked on. This gives them confidence in the future trends. This
is one of the things that makes Debian work so well.

The bug list is so hard to find (for me) in the new website layout that
I don't think new users will look at it unless they really are looking
for it.

Number of open bugs is does not equate to package stability, in fact
with respect to open software, I think it is often an inverse relationship.

Once 6.0 is released and officially the "stable" version of GRASS I have
no problem with old 5.4 bugs being archived and removed from the bug
list, with a prominent link to the 5.4 BUGS file. Until that time...

Hamish

6

On Mon, Feb 28, 2005 at 12:30:00PM +1300, Hamish wrote:
...

> > I think we need to have some sort of "confirmed", "unreproducable",
> > or "new" tag column for bugs, so we can separate out valid bugs from
> > misconfigured systems at least, giving a more realistic bug number.
>
> or, old and unreproducible bugs could be just squashed?

GRASS is a huge program with many rare bugs. One can never test all
platforms/setups, so you can never say unreproducible==mistaken report.
Even if it is a mistake, if one person did it, others might as well, and
the others in the future might figure it out & post a solution.
Just deleting the contributed user experience would be a big mistake,
IMO.

That's generally right, but RT should not become a museum for
unresolved bugs of old GRASS versions.

...

The bug list is so hard to find (for me) in the new website layout that

Were would you like to see it?

Markus

7

On Sat, Feb 26, 2005 at 09:33:36AM +0100, Paolo Cavallini wrote:

At 06:20, sabato 26 febbraio 2005 you presumably wrote:
> Shouldn't we keep a list of known GRASS 5.4 bugs somewhere rather than
> just forgetting about them? e.g. 5.4's v.digit "won't fix" bugs.

Agreed. In my view, the best solution is to make two bugs lists, one for 5.4
and one for 6.0. Then I volunteer to manage the 6.0 bugs, changing grass57 to
grass60 where appropriate. Bernhard, would this be possible?

I have added the area "grass6.0".
(Note beside people at Intevation Markus is also has admin rights
on the tracker.)

8

On Sat, Feb 26, 2005 at 09:33:36AM +0100, Paolo Cavallini wrote:

BTW: where do I find the total number of bugs?

I can run stats directly on the database of our tracker,
otherwise counting manually is possible.
(I have a script half finished to mail them out on a regular basis.
However I am missing the time to complete it.)

9

On Mon, Feb 28, 2005 at 09:19:14AM +0100, Markus Neteler wrote:

On Mon, Feb 28, 2005 at 12:30:00PM +1300, Hamish wrote:
...
> > > I think we need to have some sort of "confirmed", "unreproducable",
> > > or "new" tag column for bugs, so we can separate out valid bugs from
> > > misconfigured systems at least, giving a more realistic bug number.
> >
> > or, old and unreproducible bugs could be just squashed?
>
> GRASS is a huge program with many rare bugs. One can never test all
> platforms/setups, so you can never say unreproducible==mistaken report.
> Even if it is a mistake, if one person did it, others might as well, and
> the others in the future might figure it out & post a solution.
> Just deleting the contributed user experience would be a big mistake,
> IMO.

That's generally right, but RT should not become a museum for
unresolved bugs of old GRASS versions.

I agree with both statements, but I think Hamish also agreed that
we need to clean out, what we can clean out.

Markus: Can empty the very old BUGS file from CVS then?
Can we completely empty it? I only want to make sure because it says:
You are maintaining it and I don't know if there is any bug in there
that is not in the RT. You would know best.

10

On Mon, Feb 28, 2005 at 12:30:00PM +1300, Hamish wrote:

We already have these 8 "Areas":
None
RCbug
bug
grass5.0
grass5.4
grass5.7
wish
wish5.7

These could be updated to:
None
RCbug
grass5.0
grass5.4
wish5.4
grass6
wish6

I have added wish6 and grass6 now.
I have kept grass5.7 and wish5.7 for now
so that we do not loose the information.
If everything is updated to grass6 and wish6 I can also remove that areas.

11

On Mon, Feb 28, 2005 at 11:15:53AM +0100, Bernhard Reiter wrote:

On Mon, Feb 28, 2005 at 09:19:14AM +0100, Markus Neteler wrote:
> On Mon, Feb 28, 2005 at 12:30:00PM +1300, Hamish wrote:
> ...
> > > > I think we need to have some sort of "confirmed", "unreproducable",
> > > > or "new" tag column for bugs, so we can separate out valid bugs from
> > > > misconfigured systems at least, giving a more realistic bug number.
> > >
> > > or, old and unreproducible bugs could be just squashed?
> >
> > GRASS is a huge program with many rare bugs. One can never test all
> > platforms/setups, so you can never say unreproducible==mistaken report.
> > Even if it is a mistake, if one person did it, others might as well, and
> > the others in the future might figure it out & post a solution.
> > Just deleting the contributed user experience would be a big mistake,
> > IMO.
>
> That's generally right, but RT should not become a museum for
> unresolved bugs of old GRASS versions.

I agree with both statements, but I think Hamish also agreed that
we need to clean out, what we can clean out.

Markus: Can empty the very old BUGS file from CVS then?

Please do whatever is necessary.

Can we completely empty it? I only want to make sure because it says:
You are maintaining it

I was maintaining it...

and I don't know if there is any bug in there
that is not in the RT. You would know best.

No idea. It's not unlikely that bugs are not present in RT. Someone
has to verify carefully (I have no time for that at the moment, also
I am no longer focusing on < 6.0).

Markus

12

I am checking single bugs before updating from 5.7 to 6.
I have a few requests/suggestions for the bug tracker:
- force area definition (users should not be able to file a bug without
associate category)
- split it into two queues: grass5x and grass6x (with different links from
grass web site); this would make it far easier to keep everything tidy, even
if at the expenses of some replication
- a flag "reported/confirmed" (as suggested) would be useful
- bugs might better be sorted by area+priority (from grass6 - priority 100 to
wish6 - priority 0) than by date
All the best.
pc

At 11:17, lunedì 28 febbraio 2005, Bernhard Reiter has probably written:

On Mon, Feb 28, 2005 at 12:30:00PM +1300, Hamish wrote:
> We already have these 8 "Areas":
> None
> RCbug
> bug
> grass5.0
> grass5.4
> grass5.7
> wish
> wish5.7
>
> These could be updated to:
> None
> RCbug
> grass5.0
> grass5.4
> wish5.4
> grass6
> wish6

I have added wish6 and grass6 now.
I have kept grass5.7 and wish5.7 for now
so that we do not loose the information.
If everything is updated to grass6 and wish6 I can also remove that areas.

--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

13

> The bug list is so hard to find (for me) in the new website layout that

Were would you like to see it?

Development page between:

- Compiling GRASS - Programmer's Manual -

add a Bugs section.

I can do that, just not today.

Hamish

14

I have a few requests/suggestions for the bug tracker:
- force area definition (users should not be able to file a bug
without associate category)

this generally happens if the bug is submitted by email.

- bugs might better be sorted by area+priority (from grass6 - priority
100 to wish6 - priority 0) than by date

I take it you mean by default? You can sort by priority (or whatever) by
clicking the up/down arrows at the column headings.

Newest-bugs-first helps to keep new bugs from getting lost.

Hamish

15

On Mon, Feb 28, 2005 at 10:43:54PM +0100, Paolo Cavallini wrote:

I am checking single bugs before updating from 5.7 to 6.
I have a few requests/suggestions for the bug tracker:

Note as I have written before I hope to be able to offer a better system.
The current RT is quite hard to adapt, thus I'd rather focus to work
on the future system.

- force area definition (users should not be able to file a bug without
associate category)

IMO not done easily.

- split it into two queues: grass5x and grass6x (with different links from
grass web site); this would make it far easier to keep everything tidy, even
if at the expenses of some replication

Two queues can be done by the tracker, but I would suggest
to use two links from the butracking page to archive the same.

- a flag "reported/confirmed" (as suggested) would be useful

Not easily done, though I would suggest that a developer can just
add this as reply or comment to the tracker.

- bugs might better be sorted by area+priority (from grass6 - priority 100 to
wish6 - priority 0) than by date

Not easily done, but you can sort by priority or filter by category.
Can you come up with the best links for the grass bugs page?

16

On Mon, Feb 28, 2005 at 01:01:48PM +0100, Markus Neteler wrote:

On Mon, Feb 28, 2005 at 11:15:53AM +0100, Bernhard Reiter wrote:

> Markus: Can empty the very old BUGS file from CVS then?

Please do whatever is necessary.

> Can we completely empty it? I only want to make sure because it says:
> You are maintaining it

I was maintaining it...

> and I don't know if there is any bug in there
> that is not in the RT. You would know best.

No idea. It's not unlikely that bugs are not present in RT. Someone
has to verify carefully (I have no time for that at the moment, also
I am no longer focusing on < 6.0).

I was hoping that just by reading over the list you could mark
whatever you remember without careful checking.
This is the best effort approach.

17

On Tue, Mar 01, 2005 at 03:04:59PM +1300, Hamish wrote:

> > The bug list is so hard to find (for me) in the new website layout that
>
> Were would you like to see it?

Development page between:

- Compiling GRASS - Programmer's Manual -

add a Bugs section.

I can do that, just not today.

Please do, whenever you find the time.

Markus

18

On Tue, Mar 01, 2005 at 11:57:41AM +0100, Bernhard Reiter wrote:

On Mon, Feb 28, 2005 at 01:01:48PM +0100, Markus Neteler wrote:
> On Mon, Feb 28, 2005 at 11:15:53AM +0100, Bernhard Reiter wrote:

> > Markus: Can empty the very old BUGS file from CVS then?
>
> Please do whatever is necessary.
>
> > Can we completely empty it? I only want to make sure because it says:
> > You are maintaining it
>
> I was maintaining it...
>
> > and I don't know if there is any bug in there
> > that is not in the RT. You would know best.
>
> No idea. It's not unlikely that bugs are not present in RT. Someone
> has to verify carefully (I have no time for that at the moment, also
> I am no longer focusing on < 6.0).

I was hoping that just by reading over the list you could mark
whatever you remember without careful checking.
This is the best effort approach.

Nevertheless I have committed a more reasonable explanation for
within the file now.

19

> - split it into two queues: grass5x and grass6x (with different
> links from grass web site); this would make it far easier to keep
> everything tidy, even if at the expenses of some replication

Two queues can be done by the tracker, but I would suggest
to use two links from the butracking page to archive the same.

...but any raster/lib bugs will affect both versions. Better to clear
out all grass5.x-specific bugs from the bug tracker to the old
grass/BUGS file in CVS, add a prominent link to that on the GRASS 5.4
webpage & main bug reporting page, and go on from there?

a warning of which bug numbers will be archived & removed from the bug
tracker a few days before it happens would be nice (posted to this
list).

Sound like a plan?

Hamish

20

One question: are we going to keep the two grass versions side by side for
long? This of course makes bug tracking (among other things) much more
complicated, as our emails show.
All the best.
pc

At 03:33, mercoledì 02 marzo 2005, Hamish has probably written:

> > - split it into two queues: grass5x and grass6x (with different
> > links from grass web site); this would make it far easier to keep
> > everything tidy, even if at the expenses of some replication
>
> Two queues can be done by the tracker, but I would suggest
> to use two links from the butracking page to archive the same.

...but any raster/lib bugs will affect both versions. Better to clear
out all grass5.x-specific bugs from the bug tracker to the old
grass/BUGS file in CVS, add a prominent link to that on the GRASS 5.4
webpage & main bug reporting page, and go on from there?

a warning of which bug numbers will be archived & removed from the bug
tracker a few days before it happens would be nice (posted to this
list).

Sound like a plan?

Hamish

--
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it www.faunalia.com
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953