Proposal bug management (old trackers - GRASS-trac)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal bug management (old trackers - GRASS-trac)

Markus Neteler
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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal bug management (old trackers - GRASS-trac)

Martin Landa
Hi Markus,

2008/2/9, Markus Neteler <[hidden email]>:
> 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 *
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal bug management (old trackers - GRASS-trac)

hamish-2
In reply to this post by Markus Neteler
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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal bug management (old trackers - GRASS-trac)

hamish-2
In reply to this post by Martin Landa
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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal bug management (old trackers - GRASS-trac)

Markus Neteler
In reply to this post by hamish-2
(cc intevation.de)

On Feb 9, 2008 11:35 PM, Hamish <[hidden email]> 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=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.

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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal bug management (old trackers - GRASS-trac)

Markus Neteler
On Feb 11, 2008 9:28 AM, Sascha Wilde <[hidden email]> wrote:

> "Markus Neteler" <[hidden email]> writes:
> > (cc intevation.de)
> > On Feb 9, 2008 11:35 PM, Hamish <[hidden email]> 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 happen :(
>
> There 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev