[request-tracker-maintainers] [Rt-devel] Development roadmap

[Dominic Hargreaves]

[adding pkg-request-tracker-maintainers to this discussion as should
have been the case from the start; see
<http://lists.bestpractical.com/pipermail/rt-devel/2011-May/011464.html>
for the rest].

On Thu, May 05, 2011 at 02:10:45PM -0400, Kevin Falcone wrote:
> On Thu, May 05, 2011 at 06:50:13PM +0100, Dominic Hargreaves wrote:
> > Okay. I still need to get clear in my head the relative trade-offs
> > between being able to install and maintain multiple versions at once
> > vs the simplicity of a single package name. Much of it probably depends
> > on the frequency of releases relative to Debian's stable release cycle,
> > as well as your expectation for the support of older branches.
> 
> I'm not exactly sure when having 3.6 and 3.8 installed in parallel is useful.

It's not so much that installing them together would be useful, but
that depending when new major releases from you appear relative to the
Debian release cycle, having two major versions in a stable release
could be useful. This is a reasonably common situation with a number
of complex packages in Debian, but there are obviously trade-offs to
be made.

> > > If you can get a request-tracker4 packages instead of
> > > request-tracker40/request-tracker42 it would make us all very happy.
> > 
> > Could you expand on how that would particularly affect you as
> > upstreams?
> 
> Because if request-tracker4 gets into a stable release, users would be
> able to come up to a more recent release of RT without pulling the
> patches from testing/unstable.  We encountered a lot of folks
> installing 3.6.7 because it was available in Debian and we'd done a
> lot of work on 3.8 that they never saw.

I don't think that the difference in naming will affect that situation
at all. There's no simple answer to "stable contains old packages" --
that's a fundamental part of how Debian works -- but bear in mind that
backports of RT3.8 to lenny were available for much of its lifetime.

Having co-installable packages may actually be better for the
availability of a given major release in Debian, because it's likely to
mean there are fewer compatibility issues (see below) to resolve before
being uploaded.

One thing that I didn't really cover in my opening post about this
was the issue of API stability. Now, I realise that RT doesn't really
have a formal, published API, and in fact sometimes extensions break
even with point releases, but having a lot (relatively) of breakage
between 4.0 and 4.2 would be another reason of having co-installable
packages, so that different versions of the extension could be
targetted at each, if needed.

Dominic.

-- 
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-request-tracker-maintainers/attachments/20110509/194388fa/attachment.pgp>