Re: what to do with LTS-backports?
On Thu, 19 May 2016 at 10:38:42 -0400, Antoine Beaupré wrote:
> 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.
I agree. If the requirement for maintaining a backport was advertised to
be committing to looking after it for 5 years, I probably wouldn't do
any backports, for the same reasons I didn't join the LTS team (I have
no use for LTS myself, no test environment, and other Debian work that
I would rather be spending my limited time on).
This is basically the same principle as handing over LTS for non-backports
to the LTS team rather than it being part of ordinary maintainers'
responsibility; I think there's general consensus that supporting packages
for 2ish years is part of a maintainer's job, but also general consensus
that supporting them for 5 years is not what we agreed to, and so the
people with a specific interest in that task should be responsible for it.
> > 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.
This assumes that security fixes or stable-updates in jessie never
introduce dependencies on platform features that are new in jessie,
which seems likely to be a good approximation, but not entirely true.
> 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
It's vulnerable to the recent security issues, and also an older XSS from
2015, and also doesn't work with blogspam.net any more. Please update it
(I'm 90% sure the jessie version would work with a simple recompile)
or remove it.
For jessie, I've picked up maintaince of backports by preparing
a backport the same day I release each new upstream version, using
that backport in production, and uploading it to backports when the
corresponding non-backport reaches testing (or immediately if there's
a security fix). This works, but usually requires that I remember to
finish my release process several days later, which isn't ideal.
> 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... :/
For developers who prepare and test matching unstable and backport
versions as part of a single release process, it would also be useful if
there was a way to upload the backport version at the same time, and have
it automatically held in a queue until the corresponding unstable version
migrated, then accepted without further action from the developer. I've
considered uploading backports to DELAYED/n where n matches the unstable
package's urgency, but then they'd be rejected for violating the
"backport from testing" policy if the unstable package's migration got
delayed for some reason (RC-buggy dependencies, for example).
S
Reply to: