(RT backport) was Re: updating roundcube backports to 1.2.x?

[Dominic Hargreaves <dom@earth.li>]

On Wed, May 17, 2017 at 02:25:36PM +0200, Rhonda D'Vine wrote:
>     Hi!

Hi,

I'm sorry for the long delay in replying to this, and I am aware that
this has been mostly eclipsed by the long thread relating to django,
which I tried to follow. However I have made some points below
specific to the situation with RT.
 
>  Actually request-tracker4 in jessie-backports is also pretty aged.
> Let's take that specific example: At the point when the decision was
> made to update rt4 in unstable from 4.2 to 4.4 it was considered in a
> stage that is ready for a stable release.  That's the main part of what
> gets into testing in the long run.  4.4 is in testing, and thus we
> expect the backport to also carry that version instead of sticking with
> the old, because after all, it is deemed as release ready.
> 
>  If you *also* want to keep 4.2 around you should carry out that effort
> for stretch too, not only for backports.  That is, having 4.2 and 4.4
> side-by-side installable.
> 
>  It took me personally a lot of effort to make e.g. the wesnoth releases
> side-by-side installable and thus be able to support multiple releases
> that way.  It's something that libary maintainers do at times quite
> regularly.  What I don't see happening is having the effort to maintain
> packages side-by-side only for backports.  If you want to support both,
> please do so for the regular release, not only on the shoulders of
> backports.  This leaves the backport in a stage that only you yourself
> are able to tackle, and this is what we try to avoid.

I think this logic is faulty because creating supporting 4.2 in stretch
implies a far longer commitment than jessie-backports and 4.2 would
likely be EOL before stretch-lts was finished. But I take the point,
and I recognise that it was a mistake to using backports to support
users who wanted newer 4.2 features.

>  Backports is no place to maintain packages.  It's a place to backport
> packages to, the maintenance has to happen in unstable/testing.  And I'm
> a fair bit annoyed that this has to be repeatedly pointed out, getting
> ignored again and again with no communication and then being addressed
> with ignorance again. :/

Given that this comes up again and again perhaps the contribution page
could spell this out more. For example:

* Before uploading, ensure that you will be able to continue backporting
further versions of the package from the testing so that the package
in backports doesn't become a separate target that needs to be maintained
separately. Note that this effort can be considerable depending on the
complexity of the package.

At this point, I would rather remove request-tracker4 from jessie-backports
rather than update it to 4.4, given that users who want 4.4 in a stable
release will very soon have this with stretch. If this happened I would
set up a separate repository (like mozilla.debian.net). I would like to
instead request an exception to allow further maintenance uploads of 4.2 (and
for that matter 4.0 in wheezy-backports) as this is in the best interests
of the users, and avoids what feels like makework.

Please let me know your thoughts on this.

Thanks,
Dominic.