[request-tracker-maintainers] RT command-by-mail

[Niko Tyni]

On Wed, Mar 21, 2007 at 10:55:44AM +0000, Matthew Johnson wrote:
> Hi, we run a request-tracker instance and I'd like to interact with it
> by mail (a-la debbugs). I see there is a CommandByMail plugin
> (http://search.cpan.org/src/JESSE/RT-Extension-CommandByMail-0.05/) but
> it is not yet packaged. I have therefore packaged it (although not yet
> tested that this works) and wondered how best to proceed. Would you like
> to package it under your alioth group's name, or shall I just do so
> myself?

Hi,

I've been thinking of packaging some of the RT-Extension modules myself,
and I think they would go well with the pkg-request-tracker group.
You're certainly welcome to join the group, especially if you'd like to
help out with the main RT packages too :)

> I'm not yet a DD (I'm in NM) so I'll eventually need a sponsor for the 
> package. Would any of you be willing?

I'm not a DD yet either, so I can't help there. The only DD working in
the group is Toni Mueller, he's done all our uploads so far.

> The preliminary packages are available here:
> http://mjj29.matthew.ath.cx/debian-upload/rt3.6-commandbymail/

I had a look at the packaging, some thoughts:

- the standard naming would be librt-extension-commandbymail-perl. 
- I think it would be better to install this to /usr/share/perl5 just
  like any other perl module instead of /usr/share/request-tracker3.6
  (INSTALLDIRS=vendor etc., see the Debian Perl policy)
- the module is not specific to RT 3.6; it looks like 3.4.6 should work 
  too (and for 3.6 it needs > 3.6.1 anyway, see the patch directory)
- the debian/RT.pm trick is nice, but is it really needed? It looks
  like all the fuss is just for t/utils.pl, and the tests look invasive
  enough that there's no sense running the at build time anyway...
- the dependencies on libmime-perl should be versioned (>= 5.420)
- ${perl:Depends} and dh_perl would be good too
- there's 'Makefile.old' in .diff.gz , that's just cruft
- please don't repackage the original tarball
- using '-$(MAKE) clean' is suboptimal; see #325372

Hope this doesn't come across as nitpicking, that's not the intent :)
 
> Lastly, we have just upgraded to etch from sarge, so are still using
> rt3.4. Is upgrading to 3.6 trivial? or are there any migration gotchas?

There's some information in README.Debian of the request-tracker3.6
package. They can be installed side-to-side, and the command name
alternatives default to the older version (the priorities are 260 for
3.6 and 270 for 3.4).

The important thing is to run the database schema upgrades, I don't
think there are any other big issues.

Cheers,
-- 
Niko Tyni   ntyni at iki.fi