Re: SPI Ticketting system

Hi all. There was a discussion recently on #SPI about using a tracking
system to help SPI keep track of tasks.

The general concensus during the discussion was that Request Tracker (RT)
was the preferred option as several of the people present (mostly board
members) have quite a bit of experience with RT.

I'd certainly like us to go forward with this as soon as possible.

As well as assisting with tracking tasks it could help us set & monitor
SLAs.

Jonathan, please put "Discussion of tracking system" on the agenda for the
April 12/13 board meeting. This will be a good opportunity to get the
board talking about it. I'd hope we get a general concensus and decision
to implement.

Cheers,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world

On 04/09/2012 09:24 PM, Robert Brockway wrote:
>
> Hi all. There was a discussion recently on #SPI about using a tracking
> system to help SPI keep track of tasks.
>
> The general concensus during the discussion was that Request Tracker
> (RT) was the preferred option as several of the people present (mostly
> board members) have quite a bit of experience with RT.
>
> I'd certainly like us to go forward with this as soon as possible.

Strongly suggest redmine....

JD

JD,

> Strongly suggest redmine....

Redmine was discussed. However, SPI has existing expertise in the IT
team in deploying and maintaining RT. And SPI doesn't need Redmine's
non-tracker features.

--Josh

On Tue, 10 Apr 2012 14:24:18 +1000 (EST), Robert Brockway <robert(at)spi-inc(dot)org> wrote:
> As well as assisting with tracking tasks it could help us set & monitor
> SLAs.

What SLAs might we be considering?

Having a tracker instance seems useful regardless, and I'm not too
fussed about the technology choice as long as it's something our admin
team is comfortable managing and meets our basic needs. I have no
personal experience using or hosting either rt or redmine.

Bdale

On Tue, 10 Apr 2012, Bdale Garbee wrote:

> On Tue, 10 Apr 2012 14:24:18 +1000 (EST), Robert Brockway <robert(at)spi-inc(dot)org> wrote:
>> As well as assisting with tracking tasks it could help us set & monitor
>> SLAs.
>
> What SLAs might we be considering?

Hmm, I was sloppy using the term SLA sorry. What I meant to say was that
it would assist with tracking resolution times and even allow us to set
'service targets' in which we aim to resolve certain types of tickets
within certain timeframes.

Cheers,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world

josh(at)postgresql(dot)org
> > Strongly suggest redmine....
>
> Redmine was discussed. However, SPI has existing expertise in the IT
> team in deploying and maintaining RT. And SPI doesn't need Redmine's
> non-tracker features.

I'm interested to hear how SPI will migrate away from RT if/when
the time comes. Any outline?

I ask because I've done some migrations in and out and out seems
to be the more difficult one.

Thanks,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

On Wed, 11 Apr 2012, MJ Ray wrote:

> josh(at)postgresql(dot)org
>>> Strongly suggest redmine....
>>
>> Redmine was discussed. However, SPI has existing expertise in the IT
>> team in deploying and maintaining RT. And SPI doesn't need Redmine's
>> non-tracker features.
>
> I'm interested to hear how SPI will migrate away from RT if/when
> the time comes. Any outline?

I don't believe any options have been considered.

I've run quite a few RT instances over the last 12 years or so at
different organisations. They've all been very long lived. The only time
I've retired an RT instance it was left running on a virtual box for
reference and no attempt was made to migrate the data.

Cheers,

Rob

--
Director, Software in the Public Interest, Inc.
Email: robert(at)spi-inc(dot)org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.spi-inc.org
Free and Open Source: The revolution that quietly changed the world

MJ,

> I'm interested to hear how SPI will migrate away from RT if/when
> the time comes. Any outline?
>
> I ask because I've done some migrations in and out and out seems
> to be the more difficult one.

Run it on Postgres. Since PostgreSQL is an Affliliated project, you
can then count on having someone to do a direct database extraction,
if required.

--Josh

josh(at)postgresql(dot)org
> MJ,
>
> > I'm interested to hear how SPI will migrate away from RT if/when
> > the time comes. Any outline?
> >
> > I ask because I've done some migrations in and out and out seems
> > to be the more difficult one.
>
> Run it on Postgres. Since PostgreSQL is an Affliliated project, you
> can then count on having someone to do a direct database extraction,
> if required.

I do run it on postgresql whenever I can (I really believe in SPI's
affiliated projects, you see). There's still something like 25 tables
to extract from and I seem to recall that the foreign key
relationships (such as a transaction to its creator) are not explicit,
probably because it also runs on databases that don't handle foreign
keys so well. Have you tried one?

I think some RT users are basically stuck in it so I'd like the board
to consider how SPI will move on if/when the time comes. I always
tell people to think about the exit routes with most software, whether
proprietary or FOSS.

The exit route from RT that I've used in the past was basically
dumping the live tickets to text and reparsing that. It's not great.
I don't remember if I used rt2mbox or a script that hammered the rt
client.

I've seen something similar done when a project moved from bugzilla,
so it may be that few bug trackers do better. I've used a lot but
not migrated between that many combinations of them so I don't have
a good overview. Hopefully there are smarter people than me reading
this, else we're all doomed! ;-)

Regards,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

MJ Ray <mjr(at)phonecoop(dot)coop> writes:

> The exit route from RT that I've used in the past was basically
> dumping the live tickets to text and reparsing that.

My hack for this was even more horrible:
http://offog.org/darcs/misccode/rt-to-trac

(I don't remember why I couldn't have the script do queries against the database directly; I think I didn't have access to the database myself.)

It did work, though...

--
Adam Sampson <ats(at)offog(dot)org> <http://offog.org/>

Quoting Adam Sampson <ats(at)offog(dot)org>:

> MJ Ray <mjr(at)phonecoop(dot)coop> writes:
>
>> The exit route from RT that I've used in the past was basically
>> dumping the live tickets to text and reparsing that.
>
> My hack for this was even more horrible:
> http://offog.org/darcs/misccode/rt-to-trac

Guys: please don't let the perfect be the enemy of getting anything
done. Currently we don't have a ticket tracking system *at all*.
Regardless of the system we adopt, it will be better (and easier to
migrate) than the assorted email boxes of various board members.

RT is open source, it's available, our IT volunteers have experience
with it, and it's neither better nor worse than most other issue
trackers. It's "good enough". Please stop the bikeshedding.

Thanks!

josh(at)postgresql(dot)org
> Quoting Adam Sampson <ats(at)offog(dot)org>:
> > My hack for this was even more horrible:
> > http://offog.org/darcs/misccode/rt-to-trac
>
> Guys: please don't let the perfect be the enemy of getting anything
> done. Currently we don't have a ticket tracking system *at all*.

Look, it was a legitimate question and something that I felt the
board should include in their decision-making. I'm not suggesting
that you don't make a decision!

It also seems to be that no-one in this discussion knows of anything
that's notably better, so everything sucks and this point seems to be
sort of a no-op. Oh well!

It looks to me like the biggest thing that could have hindered the
decision being made was that josh didn't show up for the meeting where
this was on the agenda and didn't even send apologies. Happily,
enough other board members attended to make quorum.

> Regardless of the system we adopt, it will be better (and easier to
> migrate) than the assorted email boxes of various board members. [...]

That sounds a lot like "We must do something! This is something,
therefore we must do this!" which is silly and dangerous. At least
email boxes have standards (too many, but still), so it is possible
to make things worse by adopting a bad system.

But I agree that RT seems a fair decision in this situation and wish
SPI well with it.

Regards,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

On Sat, Apr 14, 2012 at 01:27, MJ Ray <mjr(at)phonecoop(dot)coop> wrote:
> I think some RT users are basically stuck in it so I'd like the board
> to consider how SPI will move on if/when the time comes.  I always
> tell people to think about the exit routes with most software, whether
> proprietary or FOSS.

Just wanted to add belated support for MJ's point here: the ability to
migrate to other systems is a great advantage of open source; having
SPI set an example of including it in their decision making process
seems like a good idea as part of both responsible maintenance and
forward planning, and as practical advocacy for free software.

FWIW, as well as access via the underlying db (and the ability to look
at the source code to understand how the db is setup); rt has a
reasonable REST interface which is also available via a command line
tool -- see http://requesttracker.wikia.com/wiki/REST and
http://requesttracker.wikia.com/wiki/CLI or the rt-command deb (not
separated out from the "rt" rpm in Fedora).

Cheers,
aj

--
Anthony Towns <aj(at)erisian(dot)com(dot)au>

MJ,

> Look, it was a legitimate question and something that I felt the
> board should include in their decision-making. I'm not suggesting
> that you don't make a decision!

Sorry, didn't mean to imply that it wasn't a legitimate question. I was
just seeing the discussion go off into a tangent, and possibly blocking
deploying something several people could use *right now*.

--Josh Berkus

Josh Berkus <josh(at)postgresql(dot)org>
> Sorry, didn't mean to imply that it wasn't a legitimate question. I was
> just seeing the discussion go off into a tangent, and possibly blocking
> deploying something several people could use *right now*.

Huh? When did the board ever suggest that they were waiting for this
discussion to finish before deploying something? I think most of us
know we were just shouting into the well here.

Good luck with your new ticketing system,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

On 12812 March 1977, Robert Brockway wrote:

> Hi all. There was a discussion recently on #SPI about using a tracking
> system to help SPI keep track of tasks.
> The general concensus during the discussion was that Request Tracker
> (RT) was the preferred option as several of the people present (mostly
> board members) have quite a bit of experience with RT.

For a summary here: We have RT now, contributing members have read
access and can find the password in the -private list.

--
bye, Joerg
<_DeadBull_> ohne speicher, tastatur, mouse, pladde, monitor, also nur die
Hardware...

On 4/30/12 7:33 AM, Joerg Jaspert wrote:
> On 12812 March 1977, Robert Brockway wrote:
>
>> Hi all. There was a discussion recently on #SPI about using a tracking
>> system to help SPI keep track of tasks.
>> The general concensus during the discussion was that Request Tracker
>> (RT) was the preferred option as several of the people present (mostly
>> board members) have quite a bit of experience with RT.
>
> For a summary here: We have RT now, contributing members have read
> access and can find the password in the -private list.

yaaay! Great work guys.

/me files a whole buncha stuff in the "treasurer" queue ...