Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
On Wed, 24 May 2017 at 14:55:42 +0100, Neil Williams wrote:
> On Wed, 24 May 2017 13:02:51 +0000
> Scott Kitterman <debian@kitterman.com> wrote:
> > This is not correct. Updating the package to the latest 1.8 version
> > took me less than half an hour.
>
> Upgrading the packages using django to accept 1.8 took the LAVA
> software team of 6 FTE developers 6 MONTHS of work.
I'm confused: what action or inaction are you recommending or objecting
to as a result of this? Your mail sounded as though you are objecting
to Scott's proposal to move from 1.8.16 to 1.8.18, but I'm not sure how
what you said implies that being a bad idea.
For a maintainer of Django-dependent software, making your dependent
software compatible with a new branch is a lot of work due to API breaks
between branches. I don't think anyone is disputing that.
If I'm understanding correctly, what we're discussing is the ongoing
maintenance of Django in jessie-backports, which already contains
1.8.16; and the options are to remove it, or keep 1.8.16 (which has
known security issues), or update along the 1.8.x banch to 1.8.18,
or upgrade to 1.10.x from stretch. (I'm not saying that all of
those options are acceptable, only that they exist.)
If you want to stay on an older version of Django and not need to change
other Django-dependent code, stable has 1.7.x. Your dependent code might
get broken by jessie-backports' 1.8.x, sure - but if it is, then that
damage has already been done, so I think we can ignore it for the purposes
of this discussion?
Holding the version at 1.8.16 obviously has no risk of making your
dependent packages regress, but if your dependent package meets the
conditions for exploiting a Django security vulnerability, then
it would remain vulnerable.
Updating 1.8.16 to 1.8.18 (breaking current backports policy in the way
that has been proposed in recent threads) is meant to be a compatible
change, with security fixes only, so it seems like a relatively low risk
of generating extra work for the maintainers of dependent packages.
If the Django maintainers are forced by backports policy to backport
1.10.x from stretch into jessie-backports, then I can see that *that*
has the potential to create a lot of work for the maintainers of
dependent packages, because unlike the upgrade from 1.8.16 to 1.8.18,
it's a jump between branches and seems likely to contain API breaks.
S
Reply to: