[request-tracker-maintainers] Plans for Lenny

[Niko Tyni]

Hi folks,

now that Etch is released (hooray!), I guess it's time to think about
the future, ie. Lenny.

First, RT versions. I think it's pretty clear that we should drop
the 3.4 branch before Lenny. Considering the upstream timeline:

3.0 2003-03
3.2 2004-06
3.4 2005-02
3.6 2006-06

it looks very probable that 3.8 will be released in a year from now.
Even if it won't, I don't think there will be any interest in 3.4
in 2009 (or whenever Lenny is going to be released...)

Given this, should we have request-tracker3.4 removed from unstable
straight away, or keep it alive (ie. upload upstream 3.4.6) for a while
still? Any opinions? I see backports.org and maybe Ubuntu as a potential
target audience for 3.4.6, but that's all.

Second, packaging improvements. As I see it, the areas that need work are 

- database integration. I'm looking at dbconfig-common [1],
  and it looks good. This should give us the PostgreSQL/MySQL setup +
  schema upgrades more or less for free, with debconf prompts and all.
  There's no support for SQLite or Informix in dbconfig-common; I'm
  not sure if that's a problem.

- non-DB parts of RT_SiteConfig.pm (eg. $rtname etc.) should be queried
  with debconf

- integration with the web server: the Apache2 stuff should be
  configured automatically, unless the admin opts out. Ideally, just
  find out the right config snippet and drop it into /etc/apache2/conf.d,
  but there are some hurdles...
  
- support for apache1 is going away, see #418266

- mail setup: is there a sensible way to automatically do this? 
  I haven't really looked into this yet.

I'm going to start with the DB stuff, as some big fruits seem to be
hanging low there. Maybe we should upgrade to 3.6.3 first with the current
framework to get a reference point into the testing distribution, though.
Uploading into experimental first might be a good idea too.

I'm also toying with the idea of supporting non-Apache setups with
SpeedyCGI, but that's probably not worth the effort...

Last, there are quite a few RT extension modules on CPAN nowadays.
I think they would go well within this group's area, so I plan to look
through them at some point too. Matthew Johnson was already packaging
RT-Extension-CommandByMail, so we have a start there.

I hope I'll get through NM before Lenny (I'm in the last stages now),
so this won't all fall on Toni. I'd love to have more people involved,
of course. I wonder if a new mail to debian-perl would find some...

BTW, many of RT's dependencies that have been maintained by Stephen
Quinney until now are going to move under the Debian Perl Group umbrella
[2] as soon as I find the time. That shouldn't change anything here,
though, except that I'll probably upgrade them to the newest upstream
versions too.

Comments welcome, sorry if this is a bit incoherent...

[1] http://people.debian.org/~seanius/policy/dbconfig-common.html/
[2] http://lists.debian.org/debian-perl/2006/11/msg00054.html

Cheers,
-- 
Niko