[GRASS-dev] Re: GRASS at GForge first steps - second encounter

[Maciej Sieczka]

Maris

Sorry for late reply. Heavy winds here in Poland broke my internet
connection. All fine now.

Maris Nartiss wrote:
> I signed up to GForge to test new GRASS trackers.

I can't see you among the GRASS project members at GForge [2] nor I got
your request. Did you request to join GRASS project [3]?

> I submited two
> patches to code patch tracker and here are my observations.
>
> * In view issue page (i.e. [1]), please, add attribute "align=left"
> to TD element containing user's submitted text. In some browsers it's
> centred and it is NOT a browser bug but a correct interpretation of
> CSS 2.1 spec - it inherits align parameter from first parent that HAS
> such attribute set.

I can't do such things. I don't have access to the very engine. Please
contact the GForge devs or maybe the Intevation who host the GForge;
fill a ticket in their tracker?
http://wald.intevation.org/tracker/?group_id=1

> * I do not see all info that I entered when I was submiting patch.
> Missing are CVS checkout date, GRASS version, GRASS component.

You need to be logged in as a GRASS project member to see more details.

> They should be visible when viewing issue.

I think you are right. Same as above though. Sorry.

> * Issue browse mode lacks column "Last changed" and possibility to
> sort by thath colum. IMHO it's really usefull to sort issues by
> activity.

I myself can't do anything about it.

> As I understand, new issue forwarding to -dev ML is not yet enabled.

Yes. I'm still waiting for feedback like your to polish things up. Thanks.

> Meanwhile could You clarify a bit for all dev's how patch handling
> should be done using this new and wonderfull tool. I mean - how long
> patch/bug should lie in tracker till it is considered that nobody
> cares bout it and fallback mechanisms should be activated?

What do you mean by "fallback mechanism"?

If I understand your question correct - there are 2 timers configurable
for each tracker:

1. Days till considered overdue

2. Days till pending tracker items time out


ad.1. According to manual:

"a * near the open date indicates that the request is more than 30 days
old. The overdue time (default 30 days) is configurable for each tracker."

I have set that to 90 days.

ad.2.

Manual doesn't explain that. By default it was 14 days. I have set it
to 60. We'll see what it means and how it works "in action".

> Should devel make a note to issue while he is inspecting patch (if
> it's not oneliner or trivial)?

I guess so. Any hints might be helpfull.

> Should there be some "areas of interest" defined
> like Michael monitoring GUI related bugs/patches etc?

One can monitor a whole tracker or one ticket. If eg. Michael wants to
monitor all GUI issues, he'd need to keep an eye on the dev list for
incoming new tickets interest and select to "monitor" each one
separately via GForge interface.

Maciek

[1]
http://wald.intevation.org/tracker/index.php?func=detail&aid=262&group_id=21&atid=205

[2]
http://wald.intevation.org/project/memberlist.php?group_id=21

[3]
http://wald.intevation.org/project/request.php?group_id=21