[request-tracker-maintainers] rt-3.6.1 release and filing ITP

[Toni Mueller]

Hello,

On Fri, 01.09.2006 at 12:52:28 +0300, Niko Tyni <ntyni at iki.fi> wrote:
> On Fri, Sep 01, 2006 at 12:31:17PM +0300, Niko Tyni wrote:
> > I'll file an ITP straight away; can't see any reason why not.
> On second thoughts, seeing the discussion from the 3.4 ITP wrt.
> packaging different versions of RT separately:
> 
>  http://lists.debian.org/debian-devel/2005/02/msg00019.html

> > but I guess the audience is otherwise very limited... maybe straight
> > to unstable is the way to go.

I think that going straight to unstable with a set of
request-tracker-3.6 packages is the way to go, in this case
_especially_ if we want to have enough exposure before freezing etch.

> > to drop 3.4. I think we should adopt 3.4 as well, it's still on the QA
> > group's hands.

> Do people agree here, or should we go with just 3.4 in etch, or
> something else?

Currently, I can't say how much work it would be to bring 3.4 up to
par, but otherwise, I'd like to see both in Etch.


I've read the thread you pointed out above and find many of the
arguments brought forward against having two (or more) versions of
something in one release invalid. For one, there's backports for a
reason - people want several versions to be available. On count two,
there's also the problem with the mentioned "smooth" PostgreSQL upgrade
which I have been bitten by sometimes. For other installations, I can
easily imagine that these upgrades simply won't work since they require
twice or thrice (can't quite remember) the disk space of the currently
running database. On a non-disk-twiddling machine, that could be hard
to come by. And third, asking for a separation along the lines of
librequest-tracker-something + request-tracker-frontend PLUS an
automatic upgrade mechanism is imho akin to asking DD's to become
upstream and fork, in many cases. Iow, I think these requests are
invalid, the more so, as only very few (other) people step forward and
do anything (thank you, Niko, Jacob, Tim et al!).


Best,
--Toni++