Re: (RT backport) was Re: updating roundcube backports to 1.2.x?
[correcting email address in 'To' field]
On Sun, Jun 11, 2017 at 07:37:55PM +0100, Dominic Hargreaves wrote:
> On Wed, May 17, 2017 at 02:25:36PM +0200, Rhonda D'Vine wrote:
> > 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.
Dear FTP masters,
I've not heard any response back from the backports team on this email,
and request-tracker4 in jessie-backports (and wheezy-backports) still
suffers from security issues (the package I uploaded to try and fix
this, 4.2.13-4~bpo8+2 back in June, has apparently gone into a black
hole). Please can you remove this package from wheezy-backports and
jessie-backports.
Thanks,
Dominic.
Reply to: