Re: what to do with LTS-backports?
On 2016-05-19 08:16:51, Rhonda D'Vine wrote:
> Hi,
>
> * Holger Levsen <holger@layer-acht.org> [2016-05-19 13:45:56 CEST]:
>> appearantly some maintainers don't want to support backports in
>> wheezy-backports anymore, saying wheezy is oldstable now (und
>> unsupported by Debian proper, "just" maintained by the Debian LTS team.)
>
> That's fine with me, I'm willing to pick up that work personally - as
> long as the package in wheezy-backports is current with jessie. What
> I'm unwilling to pick up is packages that aren't up to date with what we
> ship in jessie since a year now, having to update them where the
> original backporter abandoned the package and doesn't seem to be
> interested anymore in maintaining it:
>
> Looking at the stats, we have 327 out of 1040 [1] backported source
> package which have a newer upstream version in jessie than what we have
> in wheezy-backports, and an additional 175 packages [2] which have an
> updated Debian revision only. That's kinda *huge*, frankly spoken.
>
> [1] <http://backports.debian.org/wheezy-backports/outdated/>
> [2] <http://backports.debian.org/wheezy-backports/older/>
>
> I'm not so sure how to move on from that point, frankly spoken.
> Removals are never something that sounds nice.
That does seem like a ridiculously large amount of work, in my opinion.
I would personally simply drop support for those, to be honest. I don't
think we ever offered those backports to have LTS security support, so I
don't feel anyone should be surprised that the support is being dropped.
Nice to see those diffstat pages however, I didn't even know about
them. :)
> But: I really don't see this as an LTS issue somehow. wheezy-backports
> are done from stable, and the changed source through patches there
> should work/compile in wheezy-backports just the same. *If* they are in
> sync already with the version in jessie.
Agreed.
> And like said, I am willing to do that part.
That's great!
> There is one area though I have troubles with, and that is
> wheezy-backports-sloppy: Those packages come from stretch. And the
> further the releases divert there the more difficult it becomes to
> maintain those packages. This area really means a fair amount of
> headache and a burden, and at least from that point of view I'm a bit
> worried that the LTS related extending of the lifetime is too much to
> carry for most. If it weren't solely for wheezy-backports, I'd vote for
> "yes, keep it during LTS time still". If it were for
> wheezy-backports-sloppy I'd rather in the "please rather not" team.
> Personally speaking that is, not with my backports maintainer hat on.
I'm in the "please rather not" team for both, but I'm not going to do
that work, we have plenty on our plate just with wheezy without
backports.
>> OTOH, having unsupported backports with known security vulnerabilities
>> is bad. So an option would be to _close_ wheezy-backports _now_, also to
>> communicate this issue to the users.
>
> I really would love to have the security tracker supporting the
> backports overview again for that ...
> https://security-tracker.debian.org/tracker/status/release/stable-backports
> is empty - and I highly doubt that that's correct.
>
> https://security-tracker.debian.org/tracker/status/release/oldstable-backports
> has things listed (the only backports overview page that has anything,
> at all ...), but the issue-pages don't list backports neither, like
> https://security-tracker.debian.org/tracker/CVE-2015-7869
Right, it seems like this would be a necessary improvement if we want to
do any security support for backports.
I tried to make changes to the security tracker and somewhat got lost
along the way. But I could try again...
>> Removing individual backports from wheezy-bpo is both error prone and
>> manual busy work on the shoulders of the bpo admins, who wouldn't want
>> to do this job.
>
> Sure, but we already need to do that every now and then when we find
> out (by digging up or getting prodded about it) that packages are
> unmaintained in a rather long time ... What we would like is have
> backporters be more active in communicating on reasons if there are
> troubles with updating the backports and why they don't do it, rather
> than having us have to first find out and second prod them for a
> statement then ...
Maintainers doing their part of the work would obviously be the best
solution... I must confess that I have, myself, 3 wheezy-backports
packages that are out of date. One of them (ikiwiki) is probably even
vulnerable to the recent security issues... However, for the two others
(pv and monkeysign), they served their purpose, even if out of date...
For me it would be useful to have an email reminder when things get out
of whack: sometimes I even forget the backports I uploaded... :/
Something that sends me a notification of some sort when a package
transitions between the states in the `diffstat` backport pages would be
great.
>> (There is also the problem that some maintainers don't support their
>> backports during the life time of stable, but that's a different problem
>> IMO. Now we have the problem that backports need to be supported for up
>> to 5 years instead of 3 too… this mail is about this 5y problem.)
>
> Sure, but the 5y problem isn't that big (for regular backports, only
> for -sloppy) and if it weren't just that I'd be willing to carry that on
> my own, too. It's not as huge (besides -sloppy) as you seem to imply.
Thanks for all the details!
A.
--
Instead of worrying about what somebody else is going to do, which is
not under your control, the important thing is, what are you going to
decide about what is under your control?
- Richard Stallman
Reply to: