Suggestion: create tickets in GRASS-trac for the important bugs left
in GForge or RT. This permits to assign milestones and renders bug
management more transparent (with little overhead). Communication
should continue in the old reports.
Markus
Hi Markus,
2008/2/9, Markus Neteler <neteler@osgeo.org>:
Suggestion: create tickets in GRASS-trac for the important bugs left
in GForge or RT. This permits to assign milestones and renders bug
I would agree, since the automatized migration of bugs reported in
GForge is unclear (and for RT almost impossible).
management more transparent (with little overhead). Communication
should continue in the old reports.
I am not sure, I would vote to continue in communication in Trac. When
reporting GForge/RT bug in Trac, to add link to the old tracker to see
previous comments.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
Markus Neteler wrote:
Suggestion: create tickets in GRASS-trac for the important bugs left
in GForge or RT. This permits to assign milestones and renders bug
management more transparent (with little overhead). Communication
should continue in the old reports.
A nice idea, so we can use trac's nice milestone lists.
But if doing that, I would prefer to full-ascii copy over old bug log
into the new report and resolve the old report with a note about where
it has moved to.
Was there any movement getting ssh (or whatever) access to the GForge
machine to copy to the trac machine and run the importer?
Is there any way to get a raw dump of the RT system? There is a wealth
of institutional knowledge and reasoning in there. Also interesting tid
bits like http://intevation.de/rt/webrt?serial_num=1069
If not, and it doesn't look good I think we should start on a HTML
scraper for that. (both open and closed! bugs) That way we could keep a
searchable archive. After archiving GRASS 5-only bugs as 'wontfix' we
could "port" the important ones into trac on a as-needed basis.
?
If we can get access to the raw RT database files there are other
options... i.e. write our own translator if one doesn't already exist.
I think it's important enough to consider going to the effort.
Also I personally feel that access to information is more important
than limiting clutter in trac. The milestone filters etc can keep the
"modern" bugs away from the long standing issues.
Hamish
ps- in a harddrive crash I have some months ago lost my RT login
details. There are some bugs like #815 we can close now (r.category
rules=). http://intevation.de/rt/webrt?serial_num=815
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Markus:
> Suggestion: create tickets in GRASS-trac for the important bugs
> left in GForge or RT. This permits to assign milestones and renders
> bug
Martin wrote:
I would agree, since the automatized migration of bugs reported in
GForge is unclear (and for RT almost impossible).
nothing's impossible. 
Clarification+update of issues here would be interesting to know.
> management more transparent (with little overhead). Communication
> should continue in the old reports.I am not sure, I would vote to continue in communication in Trac.
When reporting GForge/RT bug in Trac, to add link to the old tracker
to see previous comments.
I would prefer to copy report text in full as perhaps one day the old
servers go silent for any reason and the links go cold.
Even a flat ASCII or HTML copy would be fine.
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
(cc intevation.de)
On Feb 9, 2008 11:35 PM, Hamish <hamish_b@yahoo.com> wrote:
Markus Neteler wrote:
> Suggestion: create tickets in GRASS-trac for the important bugs left
> in GForge or RT. This permits to assign milestones and renders bug
> management more transparent (with little overhead). Communication
> should continue in the old reports.A nice idea, so we can use trac's nice milestone lists.
But if doing that, I would prefer to full-ascii copy over old bug log
into the new report and resolve the old report with a note about where
it has moved to.Was there any movement getting ssh (or whatever) access to the GForge
machine to copy to the trac machine and run the importer?Is there any way to get a raw dump of the RT system? There is a wealth
of institutional knowledge and reasoning in there. Also interesting tid
bits like http://intevation.de/rt/webrt?serial_num=1069If not, and it doesn't look good I think we should start on a HTML
scraper for that. (both open and closed! bugs) That way we could keep a
searchable archive. After archiving GRASS 5-only bugs as 'wontfix' we
could "port" the important ones into trac on a as-needed basis.
?If we can get access to the raw RT database files there are other
options... i.e. write our own translator if one doesn't already exist.
I think it's important enough to consider going to the effort.
There was a sort of promise to generate the dump... no clue when this
will happen 
Also I personally feel that access to information is more important
than limiting clutter in trac. The milestone filters etc can keep the
"modern" bugs away from the long standing issues.Hamish
ps- in a harddrive crash I have some months ago lost my RT login
details. There are some bugs like #815 we can close now (r.category
rules=). http://intevation.de/rt/webrt?serial_num=815
I observe that my RT account also fails. And no crash here...
Possibly also RT problems?
Markus
On Feb 11, 2008 9:28 AM, Sascha Wilde <sascha.wilde@intevation.de> wrote:
"Markus Neteler" <neteler@osgeo.org> writes:
> (cc intevation.de)
> On Feb 9, 2008 11:35 PM, Hamish <hamish_b@yahoo.com> wrote:>> If we can get access to the raw RT database files there are other
>> options... i.e. write our own translator if one doesn't already exist.
>> I think it's important enough to consider going to the effort.
>
> There was a sort of promise to generate the dump... no clue when this
> will happenThere was some progress on this issue in the past weeks.
Maciej Sieczka and I decided to use an XML export function of gforge,
which I fixed up to basically work with your trackers.Please have a look at Issue560 on the Wald Site Admin Bug tracker:
http://wald.intevation.org/tracker/index.php?func=detail&aid=560&group_id=1&atid=162
Thanks, Sascha, much appreciated.
Now monitoring the wish report...
Markus