[GRASS5] Dealing with old bug reports: new GRASS 6 bugtracker?

GRASS GIS GRASS GIS developer
,
1

Hi,

just a comment on how to deal with old bug reports in our
bugtracker:

In the QGIS project old reports are automatically closed if
the reporter doesn't answer a comment in n days:

---------------- snip Example ----------------

Comment By: SourceForge Robot (sf-robot)

Date: 07/21/05 19:00

Message:
Logged In: YES
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 45 days (the time period specified by
the administrator of this Tracker).

---------------- end snip ----------------

I would appreciate to have such a feature for us. A few days ago
I spent some time on cleaning up reports in RT and came across
a couple (many) reports which are untouched for years and will
remain untouched for other years. IMHO we shouldn't make RT a museum
of old reports about bugs in old GRASS versions which aren't used
any more by the majority of users.

Some stats:

# total open bugs:
./htmltable_extractor.pl bugs.html | tr '\n' ' ' | tr '[' '\n' | grep ' #' | wc -l
    452

out of these:

# GRASS 6 bugs:
./htmltable_extractor.pl bugs.html | tr '\n' ' ' | tr '[' '\n' | grep grass6 | wc -l
     64

# GRASS 6 wishes:
./htmltable_extractor.pl bugs.html | tr '\n' ' ' | tr '[' '\n' | grep wish6 | wc -l
     40

# bugs older than 1 year
./htmltable_extractor.pl bugs.html | tr '\n' ' ' | tr '[' '\n' | grep yr | wc -l
    156

# bugs older than 2+ years
./htmltable_extractor.pl bugs.html | tr '\n' ' ' | tr '[' '\n' | grep '[2|3|4] yr' | wc -l
     96

In summary: The 452 bug reports do NOT reflect the current that of GRASS 6. It's
simply misleading.

Other suggestion: We set up a separate bugtracker for GRASS 6.

Markus

PS: I used http://www.devshed.com/c/a/Perl/Web-Mining-with-Perl/2/

2

just a comment on how to deal with old bug reports in our
bugtracker:

In the QGIS project old reports are automatically closed if
the reporter doesn't answer a comment in n days:

The bug doesn't go away even if the the person does.

We can do this for "GRASS doesn't install on my PC, why not?" style
reports, but I don't think we should do it for segfault-like or wish
requests.

In summary: The 452 bug reports do NOT reflect the current that of
GRASS 6. It's simply misleading.

Other suggestion: We set up a separate bugtracker for GRASS 6.

I like this idea. Just as the GRASS 5 -> GRASS 6 transistion, only items
with a sponsor get migrated.

I would not like to have old non-fixed bugs get tagged with the same
"Resolved" label as fixed bugs. The bug tracker may contain details
which might be useful for a user who has found a 5.4 v.digit bug. I know
the debain bug reports are often reassuring that the error wasn't my
fault, even if it is old and unfixed.

A lot of the bugs may be 2+ years old, but a lot of the raster modules
haven't been modified in that long either!

The bug tracker is not a PR tool.

I don't mean to be against the plans, just when the cleanup happens do
it with care..

Hamish

3

On Fri, Jul 22, 2005 at 07:52:13PM +1200, Hamish wrote:

> just a comment on how to deal with old bug reports in our
> bugtracker:
>
> In the QGIS project old reports are automatically closed if
> the reporter doesn't answer a comment in n days:

The bug doesn't go away even if the the person does.

That's not always true:

- In the posted QGIS case the bug was solved but I forgot to confirm.
  So the auto-closure was correct (otherwise I could reopen it if I
  am not happy yet as user).
- In some/many GRASS cases the developers forget to close in RT or don't
  remember that it was posted there.
- In some cases the problem is solved in later versions, so the bug
  no longer applies if we don't want to backport all features (impossible).

We can do this for "GRASS doesn't install on my PC, why not?" style
reports, but I don't think we should do it for segfault-like or wish
requests.

Agreed for wishes.
Segfaults depend on lots of environmental factors which are often hard/
impossible to reproduce.

> In summary: The 452 bug reports do NOT reflect the current that of
> GRASS 6. It's simply misleading.
>
> Other suggestion: We set up a separate bugtracker for GRASS 6.

I like this idea. Just as the GRASS 5 -> GRASS 6 transistion, only items
with a sponsor get migrated.

I would not like to have old non-fixed bugs get tagged with the same
"Resolved" label as fixed bugs.

There is a "stalled" label as well. Maybe newer version of RT provide
even more.

The bug tracker may contain details
which might be useful for a user who has found a 5.4 v.digit bug. I know
the debain bug reports are often reassuring that the error wasn't my
fault, even if it is old and unfixed.

This requires an RT manager who merges reports etc.

A lot of the bugs may be 2+ years old, but a lot of the raster modules
haven't been modified in that long either!

Examples:
- #35 ?
- #241 will never get changed (probably)
- #1035 the same
- #1047 would be nice
- #1063 unlikely
- #1065 unlikely
- #1066 unlikely
- #1232 no idea

and so on.

The bug tracker is not a PR tool.

But it's considered as such a thing by some people...

Also: a bug tracker filled with 4xx reports is hard to maintain. At least
personally, I just get frustrated by opening it :slight_smile:

I don't mean to be against the plans, just when the cleanup happens do
it with care..

Absolutely. That's why I suggested splitting into GRASS 5 RT and GRASS 6 RT.

Markus

4

Hamish wrote:

just a comment on how to deal with old bug reports in our
bugtracker:

In the QGIS project old reports are automatically closed if
the reporter doesn't answer a comment in n days:

The bug doesn't go away even if the the person does.

I agree - please do not close old unresolved bug reports (especially not after 45 days). There are a few important bugs that won't get fixed within the next 45 days for sure - they are just too complex to resolve quickly (e.g. v.in.ascii). Also, while fixing some old bugs I have submitted some new ones that were in the code for years and were forgotten (such as the 3D distance in r.flow) - bug tracker allows me to keep track of these old bugs and I can go back to them when I have more time but I certainly cannot promise to do it in 45 days or any n-days.

We can do this for "GRASS doesn't install on my PC, why not?" style
reports, but I don't think we should do it for segfault-like or wish
requests.

In summary: The 452 bug reports do NOT reflect the current that of
GRASS 6. It's simply misleading.

Other suggestion: We set up a separate bugtracker for GRASS 6.

Please do that - I spent two days trying to help clean bugtracker
just recently and it was indeed a frustrating experience.
Setting up separate bugtracker for GRASS6 should solve half of the problems and if Maciek does a good job in sorting out the real bugs
from complaints and users problems and tracing the status of important bugs with people who have
the expertise to fix them we should be in a pretty good shape.

Helena

I like this idea. Just as the GRASS 5 -> GRASS 6 transistion, only items
with a sponsor get migrated.

I would not like to have old non-fixed bugs get tagged with the same
"Resolved" label as fixed bugs. The bug tracker may contain details
which might be useful for a user who has found a 5.4 v.digit bug. I know
the debain bug reports are often reassuring that the error wasn't my
fault, even if it is old and unfixed.

A lot of the bugs may be 2+ years old, but a lot of the raster modules
haven't been modified in that long either!

The bug tracker is not a PR tool.

I don't mean to be against the plans, just when the cleanup happens do
it with care..

Hamish

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

5

(CC Bernhard)

On Fri, Jul 22, 2005 at 12:27:06PM -0400, Helena Mitasova wrote:

Hamish wrote:
>>just a comment on how to deal with old bug reports in our
>>bugtracker:
>>
>>In the QGIS project old reports are automatically closed if
>>the reporter doesn't answer a comment in n days:
>
>
>The bug doesn't go away even if the the person does.

I agree - please do not close old unresolved bug reports (especially not
after 45 days). There are a few important bugs that won't get fixed
within the next 45 days for sure - they are just too complex to resolve
quickly (e.g. v.in.ascii). Also, while fixing some old bugs I have
submitted some new ones that were in the code for years and were
forgotten (such as the 3D distance in r.flow) - bug tracker allows me to
keep track of these old bugs and I can go back to them when I have more
time but I certainly cannot promise to do it in 45 days or any n-days.

To clarify: I meant bugs where the developers say that it is resolved and
the users do not confirm.

>We can do this for "GRASS doesn't install on my PC, why not?" style
>reports, but I don't think we should do it for segfault-like or wish
>requests.
>
>
>>In summary: The 452 bug reports do NOT reflect the current that of
>>GRASS 6. It's simply misleading.
>>
>>Other suggestion: We set up a separate bugtracker for GRASS 6.

Please do that - I spent two days trying to help clean bugtracker
just recently and it was indeed a frustrating experience.
Setting up separate bugtracker for GRASS6 should solve half of the
problems and if Maciek does a good job in sorting out the real bugs
from complaints and users problems and tracing the status of important
bugs with people who have
the expertise to fix them we should be in a pretty good shape.

Helena

@Bernhard: what do you think, is there a possibility to
split RT?

Markus

>I like this idea. Just as the GRASS 5 -> GRASS 6 transistion, only items
>with a sponsor get migrated.
>
>I would not like to have old non-fixed bugs get tagged with the same
>"Resolved" label as fixed bugs. The bug tracker may contain details
>which might be useful for a user who has found a 5.4 v.digit bug. I know
>the debain bug reports are often reassuring that the error wasn't my
>fault, even if it is old and unfixed.
>
>
>A lot of the bugs may be 2+ years old, but a lot of the raster modules
>haven't been modified in that long either!
>
>The bug tracker is not a PR tool.
>
>
>I don't mean to be against the plans, just when the cleanup happens do
>it with care..
>
>
>
>Hamish
>
>_______________________________________________
>grass5 mailing list
>grass5@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grass5

6

Hi Markus,

On Sat, Jul 23, 2005 at 06:37:20AM +0200, Markus Neteler wrote:

(CC Bernhard)

On Fri, Jul 22, 2005 at 12:27:06PM -0400, Helena Mitasova wrote:

To clarify: I meant bugs where the developers say that it is resolved and
the users do not confirm.

in my view, those should be closed after a reasonable amount of time.

> >>In summary: The 452 bug reports do NOT reflect the current that of
> >>GRASS 6. It's simply misleading.

If a user is still on GRASS5 (and usually there is a reason for this)
then this bug still affects GRASS6 in some way.
A bug database also does not need to be representative,
Debian and KDE always have thousands of bugs open.
It is a tool and database mainly for helper and developers.

> >>Other suggestion: We set up a separate bugtracker for GRASS 6.
>
> Please do that - I spent two days trying to help clean bugtracker
> just recently and it was indeed a frustrating experience.

I would be interesting why it was frustrating technically,
because it seems always a bit frustrating when we do not have enough
people helping with the tracker.
Technically, if you set up a filter for grass6 bugs, then you are
not seeing the others.

> Setting up separate bugtracker for GRASS6 should solve half of the
> problems

Can you explain what problems will be solved?

> and if Maciek does a good job in sorting out the real bugs
> from complaints and users problems and tracing the status of important
> bugs with people who have
> the expertise to fix them we should be in a pretty good shape.

@Bernhard: what do you think, is there a possibility to
split RT?

It is work, but of course it is possible.
I would not really recommend it and I still want to propose a new
infrastructure for GRASS based on gforge at some day (no schedule yet,
but we have a lot of it running already).
This would allow for a better integration of several trackers.
Another option would be to move to roundup.

  Bernhard

7

On Mon, Jul 25, 2005 at 12:25:38PM +0200, Bernhard Reiter wrote:

Hi Markus,

On Sat, Jul 23, 2005 at 06:37:20AM +0200, Markus Neteler wrote:
> (CC Bernhard)
>
> On Fri, Jul 22, 2005 at 12:27:06PM -0400, Helena Mitasova wrote:

> To clarify: I meant bugs where the developers say that it is resolved and
> the users do not confirm.

in my view, those should be closed after a reasonable amount of time.

> > >>In summary: The 452 bug reports do NOT reflect the current that of
> > >>GRASS 6. It's simply misleading.

If a user is still on GRASS5 (and usually there is a reason for this)
then this bug still affects GRASS6 in some way.

Not necessarily. If things are rewritten, the bug report does often
no longer apply (see my "this works in 6.x" or "please try in 6.x"
comments in some of the RT reports).

A bug database also does not need to be representative,
Debian and KDE always have thousands of bugs open.
It is a tool and database mainly for helper and developers.

Exactly. And a rather crowded bugtracker doesn't help too much
for such a small developers group if things cannot be visually
separated. Therefore my suggestion to split.

> > >>Other suggestion: We set up a separate bugtracker for GRASS 6.
> >
> > Please do that - I spent two days trying to help clean bugtracker
> > just recently and it was indeed a frustrating experience.

I would be interesting why it was frustrating technically,
because it seems always a bit frustrating when we do not have enough
people helping with the tracker.

For me it's frustrating since the list is endless and I see a lot
of stuff which will apparently never be closed since it was resolved
in a later version.

Technically, if you set up a filter for grass6 bugs, then you are
not seeing the others.

How to do this? Doesn't this require an "Area" filter which is
not there? Wish: I would like to see "grass6" only.

> > Setting up separate bugtracker for GRASS6 should solve half of the
> > problems

Can you explain what problems will be solved?

Because a bugtracker should look sort of "inviting" to people to
help. If I see 450 bugs in a long page, I get tired immediately and
go elsewhere :slight_smile:

> > and if Maciek does a good job in sorting out the real bugs
> > from complaints and users problems and tracing the status of important
> > bugs with people who have
> > the expertise to fix them we should be in a pretty good shape.

> @Bernhard: what do you think, is there a possibility to
> split RT?

It is work, but of course it is possible.
I would not really recommend it and I still want to propose a new
infrastructure for GRASS based on gforge at some day (no schedule yet,
but we have a lot of it running already).

Do you mean this one: http://gforge.org/ ?

This would allow for a better integration of several trackers.
Another option would be to move to roundup.

http://roundup.sourceforge.net/

I feel that in the past most of the bugs were solved via mailing
list...

Markus

8

From: "Markus Neteler" <neteler@itc.it>

How to do this? Doesn't this require an "Area" filter which is
not there? Wish: I would like to see "grass6" only.

I think that "grass5.7" area should be still considered when talking of Grass6 bugs. Some of these still apply. An example I recall is http://intevation.de/rt/webrt?serial_num=2383&display=History

And of course the "grass6.1" area should be included too.

P.S.
I started the cleanup on Saturday. Currently I will be able to spend few hours on most Saturdays and few minutes daily for basic maintance.

First several bugs revised were 5.7 mostly.

Maciek

9

On Tue, Jul 26, 2005 at 08:38:13AM +0200, Maciek Sieczka wrote:
...

I think that "grass5.7" area should be still considered when talking of
Grass6 bugs. Some of these still apply. An example I recall is
http://intevation.de/rt/webrt?serial_num=2383&display=History

This is not a bug (for me). It also worked (for me) when Stephan
was reporting it.

More details in the report #2383.

Markus

10

On Mon, Jul 25, 2005 at 11:00:22PM +0200, Markus Neteler wrote:

On Mon, Jul 25, 2005 at 12:25:38PM +0200, Bernhard Reiter wrote:
> On Sat, Jul 23, 2005 at 06:37:20AM +0200, Markus Neteler wrote:
> > On Fri, Jul 22, 2005 at 12:27:06PM -0400, Helena Mitasova wrote:

> If a user is still on GRASS5 (and usually there is a reason for this)
> then this bug still affects GRASS6 in some way.

Not necessarily. If things are rewritten, the bug report does often
no longer apply (see my "this works in 6.x" or "please try in 6.x"
comments in some of the RT reports).

It means that a user has a problem that is not solved
with the existance of GRASS6. That is all I am saying.
The bug entry would be a good place to record the solutions,
onces there is one.

For me it's frustrating since the list is endless and I see a lot
of stuff which will apparently never be closed since it was resolved
in a later version.

We probably need a "non-fix" state in the future to help this.

> Technically, if you set up a filter for grass6 bugs, then you are
> not seeing the others.

How to do this? Doesn't this require an "Area" filter which is
not there? Wish: I would like to see "grass6" only.

You are right an area filter would be an improvement.
For whatever reason I thought we had one.
(I'll ask our system administration if we can easily add one.)

Because a bugtracker should look sort of "inviting" to people to
help. If I see 450 bugs in a long page, I get tired immediately and
go elsewhere :slight_smile:

I tend to disagree that the long list is a major factor,
the feel of the development community is.
Usually you start fixing one or a few bugs that affects you
not looking at the others. And KDE and Debian prove the impact
wrong, they have a huge number of bugs in the tracker and attract
a lot of people.

> > @Bernhard: what do you think, is there a possibility to
> > split RT?
>
> It is work, but of course it is possible.
> I would not really recommend it and I still want to propose a new
> infrastructure for GRASS based on gforge at some day (no schedule yet,
> but we have a lot of it running already).

Do you mean this one: http://gforge.org/ ?

Yes, the software that can be fetched from this side.
Running here of course.

> This would allow for a better integration of several trackers.
> Another option would be to move to roundup.

http://roundup.sourceforge.net/

Yes.

I feel that in the past most of the bugs were solved via mailing list...

That is not bad, it happens a lot with other projects, too.

  Bernhard
ps.: I probably will not be able to answer for a couple of days.

11

On Wed, Jul 27, 2005 at 04:35:30PM +0200, Bernhard Reiter wrote:

On Mon, Jul 25, 2005 at 11:00:22PM +0200, Markus Neteler wrote:

...

> Because a bugtracker should look sort of "inviting" to people to
> help. If I see 450 bugs in a long page, I get tired immediately and
> go elsewhere :slight_smile:

I tend to disagree that the long list is a major factor,
the feel of the development community is.

Example:

If I touch/fix 30 bugs out of 450, I change ~ 7%. Means, I
don't see any visual impact.

If I touch/fix 30 bugs out of 150 (and the GRASS 6 are less),
I change 20%. This satisfies me much more psychologically.

I am talking about psychologically effects here which are
IMHO very important.

Usually you start fixing one or a few bugs that affects you
not looking at the others. And KDE and Debian prove the impact
wrong, they have a huge number of bugs in the tracker and attract
a lot of people.

I don't think that we can compare KDE/GRASS or Debian/GRASS.

[...]

Markus

12

I removed quite a few outdated bug reports, and I can confirm the
psychological effect Markus is talking about is very real.
And now is difficult to tell "true" bugs from cosmetic ones (in spite of the
classification).
All the best.
pc

At 18:00, mercoledì 27 luglio 2005, Markus Neteler has probably written:

On Wed, Jul 27, 2005 at 04:35:30PM +0200, Bernhard Reiter wrote:
> On Mon, Jul 25, 2005 at 11:00:22PM +0200, Markus Neteler wrote:

...

> > Because a bugtracker should look sort of "inviting" to people to
> > help. If I see 450 bugs in a long page, I get tired immediately and
> > go elsewhere :slight_smile:
>
> I tend to disagree that the long list is a major factor,
> the feel of the development community is.

Example:

If I touch/fix 30 bugs out of 450, I change ~ 7%. Means, I
don't see any visual impact.

If I touch/fix 30 bugs out of 150 (and the GRASS 6 are less),
I change 20%. This satisfies me much more psychologically.

I am talking about psychologically effects here which are
IMHO very important.

> Usually you start fixing one or a few bugs that affects you
> not looking at the others. And KDE and Debian prove the impact
> wrong, they have a huge number of bugs in the tracker and attract
> a lot of people.

I don't think that we can compare KDE/GRASS or Debian/GRASS.

[...]

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

13

Regarding the bugtracker.

In my opinion it would be good if the 'comment' would be removed for good and that 'reply' would automatically also forward to grass5 list and the assignee. I happen to see entries in the bugtracker which were never forwarded to public while should have been. This happens because:

1. Even people who know 'reply' doesn't forward to the list forget to CC manually sometimes.

2. Occasional bug reporters will never know they should CC. However they propably indeed expect that their 'comments' or 'reply' would be CCed to the grass5 list - like their very report was.

In QGIS BT, which we like, any reply is forwarded to the list. This provides better information flow and more eyes are looking at the problem.

Good idea? Possible?

I'd like that the email sent to the reporter by 'reply' via Grass BT would not contain 'Maciek Sieczka via RT' but 'Request Tracker <grass-bugs@intevation.de>' (and my real addres if possible too).

Currently, if the reporter replies to the email sent from 'Maciek Sieczka via RT' his reply will never reach anybody, sic!. And he is not likely to specify target emails manually, as he cannot know he is supposed to. What he does is 'reply' and he is right to expect his email gets somewhere, which doesn't happen.

Could that be fixed?

Maciek

14

On Wed, Jul 27, 2005 at 10:09:17PM +0200, Maciek Sieczka wrote:

Regarding the bugtracker.

In my opinion it would be good if the 'comment' would be removed for good
and that 'reply' would automatically also forward to grass5 list and the
assignee. I happen to see entries in the bugtracker which were never
forwarded to public while should have been. This happens because:

1. Even people who know 'reply' doesn't forward to the list forget to CC
manually sometimes.

2. Occasional bug reporters will never know they should CC. However they
propably indeed expect that their 'comments' or 'reply' would be CCed to
the grass5 list - like their very report was.

In QGIS BT, which we like, any reply is forwarded to the list. This
provides better information flow and more eyes are looking at the problem.

Good idea?

Yes, good idea. I rarely come back on a regular base to the RT to
check if the reporting user has written something.

Possible?

Hopefully.

[...]

Markus

15

On Thu, Jul 28, 2005 at 10:25:19AM +0200, Markus Neteler wrote:

On Wed, Jul 27, 2005 at 10:09:17PM +0200, Maciek Sieczka wrote:
> Regarding the bugtracker.
> In my opinion it would be good if

From experience I know that changing the bugtracker is a lot of work,
especially if it changes a lot. Because RT is reaching is end of life
soon, I would rather spend more time on the new system than on major
changes on the old one.

> I happen to see entries in the bugtracker which were never
> forwarded to public while should have been.

This is debatable.
I found it better to do the discussion inside of each issue
and not clutter the email lists about it in other projects.
Of course the tracker system needs to make this possible.
Roundup is a lot better in this regard than Request Tracker,
as Request Tracker is geared towards a help-desk use.

> any reply is forwarded to the list. This
> provides better information flow and more eyes are looking at the problem.

I guess that we would need another list for this.
The behaviour itself annoys me a bit on projects like kmail.

Yes, good idea. I rarely come back on a regular base to the RT to
check if the reporting user has written something.

If you wrote a reply, you can "take" the issue and then
a reply of the user will be directed to you and you do not miss it.

  Bernhard

16

From: "Bernhard Reiter" <bernhard@intevation.de>

If you wrote a reply, you can "take" the issue and then
a reply of the user will be directed to you and you do not miss it.

Indeed. But if I went this way during the cleanup, I would have to "take" a
lot of bugs, while only developers who really fix the bug should "take" them
so they have full control on an issue. Besides, missunderstandings are be
possible - I might be taken for a developer fixing the bug :DDD.

A good solution for me would be simply to CC any message sent to
grass-bugs@intevation.de to my address werchowyna@epf.pl temporarily, so I
keep an eye on everything - those of my particular interest mainly. After
all there is not that much traffic in the RT and I don't mind some extra
spam. That'd be a workarond until you can craft neat, new bugtracker for
Grass. Is my idea hard to implement?

One remark more. I noticed that a "reply" from the RT interface sent as a
"guest" is sent *only* to the RT itself and the bug owner, while the
requestor doesn't get a copy. Only when I "reply" as a registered user
"msieczka" both requestor and owner are CC'ed. Why the difference? I think a
reply from a guest should be taken same as from a registerd user, you never
know who has an idea.

P.S.

I still think that CC'ing grass5 list all the messages to
grass-bugs@intevation.de by default is a good idea. There could be an option
not to do so if needed, but the default should be to CC in my opinion.
Developers in charge of particular issues come and go, sprain their wrists
;), while any relative information should be discussed ASAP to resolve the
proble possibly quick. Otherwise it is more likely to have 4/5 yera old
zombie bugs like in Grass.

Take a look at QGIS. They have all the bug discussion CCed to their dev list
and although it is some mess in the archive, no doubt, there are positives:

1. folks who might never see the discussion on a particular bug report now
can see it and share their knowledge (and learn - to be more helpfull in
future?)
2. it is less likely that the same solutions are doubled
3. those who can't help are better informed, so they can avoid buggy actions
and won't report same bug (or place same comments) that somebody did

We know your opinion. What do other Folks think?

Maciek

17

On Wed, 2005-08-10 at 22:57 +0200, Maciek Sieczka wrote:

I still think that CC'ing grass5 list all the messages to
grass-bugs@intevation.de by default is a good idea. There could be an option
not to do so if needed, but the default should be to CC in my opinion.
Developers in charge of particular issues come and go, sprain their wrists
;), while any relative information should be discussed ASAP to resolve the
proble possibly quick. Otherwise it is more likely to have 4/5 yera old
zombie bugs like in Grass.

Take a look at QGIS. They have all the bug discussion CCed to their dev list
and although it is some mess in the archive, no doubt, there are positives:

1. folks who might never see the discussion on a particular bug report now
can see it and share their knowledge (and learn - to be more helpfull in
future?)
2. it is less likely that the same solutions are doubled
3. those who can't help are better informed, so they can avoid buggy actions
and won't report same bug (or place same comments) that somebody did

We know your opinion. What do other Folks think?

I would like to see bugs copied to the list. I find it beneficial, but
maybe I'm the only person who runs around fixing things at random as
they come up. :wink:

If the list isn't copied, add me to CC: if it isn't too much trouble.

--
Brad Douglas <rez@touchofmadness.com>

18

On Wed, Aug 10, 2005 at 10:57:34PM +0200, Maciek Sieczka wrote:

From: "Bernhard Reiter" <bernhard@intevation.de>

>If you wrote a reply, you can "take" the issue and then
>a reply of the user will be directed to you and you do not miss it.

Indeed. But if I went this way during the cleanup, I would have to "take" a
lot of bugs, while only developers who really fix the bug should "take" them
so they have full control on an issue. Besides, missunderstandings are be
possible - I might be taken for a developer fixing the bug :DDD.

A good solution for me would be simply to CC any message sent to
grass-bugs@intevation.de to my address werchowyna@epf.pl temporarily, so I
keep an eye on everything - those of my particular interest mainly. After
all there is not that much traffic in the RT and I don't mind some extra
spam. That'd be a workarond until you can craft neat, new bugtracker for
Grass. Is my idea hard to implement?

Unfortunately: Probably yes.
I cannot say for sure until I have tried.

One remark more. I noticed that a "reply" from the RT interface sent as a
"guest" is sent *only* to the RT itself and the bug owner, while the
requestor doesn't get a copy. Only when I "reply" as a registered user
"msieczka" both requestor and owner are CC'ed. Why the difference? I think a
reply from a guest should be taken same as from a registerd user, you never
know who has an idea.

No idea, this might be simply a bug or has a meaning.

I still think that CC'ing grass5 list all the messages to
grass-bugs@intevation.de by default is a good idea.

If this is what most people want, I will try to make it happen.
It will be the same implementation effort than above.

  Bernhard

19

Dear GRASS-Developers and Tester,

we just added a filter posibility by AREA to the GRASS bugtracker.
You will see it on the bottom of the page.

This might help until we can replace the tracker based
on request-tracker that is showing its age.

Best,
  Bernhard

On Wed, Jul 27, 2005 at 04:35:30PM +0200, Bernhard Reiter wrote:

On Mon, Jul 25, 2005 at 11:00:22PM +0200, Markus Neteler wrote:
> On Mon, Jul 25, 2005 at 12:25:38PM +0200, Bernhard Reiter wrote:

> > Technically, if you set up a filter for grass6 bugs, then you are
> > not seeing the others.
>
> How to do this? Doesn't this require an "Area" filter which is
> not there? Wish: I would like to see "grass6" only.

You are right an area filter would be an improvement.
For whatever reason I thought we had one.
(I'll ask our system administration if we can easily add one.)

20

Hi Bernhard,

cool!

I have updated all grass6.1 area bugs to grass6 (keep it simple) and
deleted area grass6.1. Also added links to the filtered RT:

http://grass.itc.it/bugtracking/bugreport.html
GRASS 6 bugs only
GRASS 6 wishes only

Now someone will have to check for the remaining bugs/wishes *without*
area indication if they apply to grass6.

Thanks

Markus

On Wed, Aug 31, 2005 at 06:29:12PM +0200, Bernhard Reiter wrote:

Dear GRASS-Developers and Tester,

we just added a filter posibility by AREA to the GRASS bugtracker.
You will see it on the bottom of the page.

This might help until we can replace the tracker based
on request-tracker that is showing its age.

Best,
  Bernhard

On Wed, Jul 27, 2005 at 04:35:30PM +0200, Bernhard Reiter wrote:
> On Mon, Jul 25, 2005 at 11:00:22PM +0200, Markus Neteler wrote:
> > On Mon, Jul 25, 2005 at 12:25:38PM +0200, Bernhard Reiter wrote:

> > > Technically, if you set up a filter for grass6 bugs, then you are
> > > not seeing the others.
> >
> > How to do this? Doesn't this require an "Area" filter which is
> > not there? Wish: I would like to see "grass6" only.
>
> You are right an area filter would be an improvement.
> For whatever reason I thought we had one.
> (I'll ask our system administration if we can easily add one.)