[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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


Reply to: