Django 1.6's lifespan for security updates?

[Christian Hammond]

Hi,

According to
https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions,
it appears that when Django 1.8 is released, Django 1.6 will no longer
receive security updates. I wanted to verify that this is true, and ask
whether there's a possibility of an extension on this timeframe.

I'll explain the situation we're in.

I manage Review Board, a code review tool currently in use by several
thousand companies/organizations, many of whom (according to stats we have
available) are on Python 2.6. From conversations we've had, many of these
companies are on LTS releases of Linux distributions that bundle Python 2.6
by default (including their mod_wsgi support, etc.), and are likely to
remain on it for the next year or two. Not to mention Amazon Linux and
other variants are all sticking with 2.6 for now as well.

This puts us in a difficult position where we are unable to drop Python 2.6
support without affecting a large number of installs out there (12% of our
base, or over 700 installs), meaning we haven't yet been able to make the
transition to Django 1.7/1.8 (as much as we want it). (It also makes the
lives of packagers easier who are trying to support software stuck in this
situation, from what I'm being told, as they're responsible for security
updates.)

As Django 1.6 is the last release to support Python 2.6, it would be very
nice to have a longer-term security release plan while companies transition
over. We see this happening, but slowly.

Is there any possibility of treating Django 1.6 as a special LTS release?

Thanks for considering :)

Christian

--
Christian Hammond
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com

[Carl Meyer]

Hi Christian,

Post by Christian Hammond
According to
https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions,
it appears that when Django 1.8 is released, Django 1.6 will no longer
receive security updates. I wanted to verify that this is true, and ask
whether there's a possibility of an extension on this timeframe.

It is true, and I don't think it should be extended.

Post by Christian Hammond
I'll explain the situation we're in.
I manage Review Board, a code review tool currently in use by several
thousand companies/organizations, many of whom (according to stats we
have available) are on Python 2.6. From conversations we've had, many of
these companies are on LTS releases of Linux distributions that bundle
Python 2.6 by default (including their mod_wsgi support, etc.), and are
likely to remain on it for the next year or two. Not to mention Amazon
Linux and other variants are all sticking with 2.6 for now as well.
This puts us in a difficult position where we are unable to drop Python
2.6 support without affecting a large number of installs out there (12%
of our base, or over 700 installs), meaning we haven't yet been able to
make the transition to Django 1.7/1.8 (as much as we want it). (It also
makes the lives of packagers easier who are trying to support software
stuck in this situation, from what I'm being told, as they're
responsible for security updates.)
As Django 1.6 is the last release to support Python 2.6, it would be
very nice to have a longer-term security release plan while companies
transition over. We see this happening, but slowly.
Is there any possibility of treating Django 1.6 as a special LTS release?

I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.

If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)

Carl

[Avraham Serour]

each django deployed on the machines with python 2.6 should already be on
the project virtualenv
I suggest to compile python 2.7 yourself and create the virtualenvs based
on the compiled python, no need to replace it system-wide

Post by Carl Meyer
Hi Christian,

Post by Christian Hammond
According to

https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions
,

Post by Christian Hammond
it appears that when Django 1.8 is released, Django 1.6 will no longer
receive security updates. I wanted to verify that this is true, and ask
whether there's a possibility of an extension on this timeframe.

It is true, and I don't think it should be extended.

Post by Christian Hammond
I'll explain the situation we're in.
I manage Review Board, a code review tool currently in use by several
thousand companies/organizations, many of whom (according to stats we
have available) are on Python 2.6. From conversations we've had, many of
these companies are on LTS releases of Linux distributions that bundle
Python 2.6 by default (including their mod_wsgi support, etc.), and are
likely to remain on it for the next year or two. Not to mention Amazon
Linux and other variants are all sticking with 2.6 for now as well.
This puts us in a difficult position where we are unable to drop Python
2.6 support without affecting a large number of installs out there (12%
of our base, or over 700 installs), meaning we haven't yet been able to
make the transition to Django 1.7/1.8 (as much as we want it). (It also
makes the lives of packagers easier who are trying to support software
stuck in this situation, from what I'm being told, as they're
responsible for security updates.)
As Django 1.6 is the last release to support Python 2.6, it would be
very nice to have a longer-term security release plan while companies
transition over. We see this happening, but slowly.
Is there any possibility of treating Django 1.6 as a special LTS release?

I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.
If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)
Carl
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/54FF6991.7080909%40oddbird.net
.
For more options, visit https://groups.google.com/d/optout.

[Stephen Gallagher]

Post by Carl Meyer
I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.
If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)

So, here's the basic problem. The distributions that are packaging python
2.6 are, basically Red Hat Enterprise Linux 6 and its clones (CentOS,
Scientific Linux, Oracle, etc.) and SUSE Linux Enterprise Server 11. These
two distributions make up a significant percentage of the enterprise
deployment space. Neither of these distributions ships Django itself. For
RHEL, the Fedora Project provides the EPEL add-on repository which is
unsupported and *may* carry Django (though it has proven to be difficult,
more on that in a minute). For SLES, there is OpenSUSE which acts
similarly. These are community-sponsored and generally limited to only
packaging what upstream provides, since with no corporate backing and
engineering support, backporting patches from newer releases is unlikely to
happen.

The reason that neither of these distributions carries Django is
specifically because of the short lifecycle of Django. The LTM releases
(1.4 and the upcoming 1.8) are somewhat better aligned with the goals of
enterprise distributions, but even those approximately three-year lifespans
are significantly shorter than the ten years that the enterprise
distributions want to maintain. So the chances of Django ever being shipped
by a company capable of supporting it for that length of time is basically
zero. (Not unless Django someday becomes a critical part of the standard
Linux platform).

In the Enterprise software space, there's an average of a two-year period
between a new version of software becoming available and companies actually
deploying it. This essentially means that an LTM release needs to be at
minimum four years long, since it will require half of the supported
lifecycle for consumers to convert over to it and they'll need the other
half of it in order to migrate to the next version. (Also, most companies
don't like constant migrations like this).

So, I realize that Django 1.6 is not an LTM release, and so asking for an
extension on it is probably unlikely to happen. I'd like to see 1.4
supported for at least the two-year migration period to 1.8, though (with
1.8 planned to accommodate the future migration as well).

Also, is there any chance at all that python 2.6 support could be
reintroduced to Django 1.8? That would make it plausible to migrate
existing users to an LTM release at least, buying time to figure further
plans out.

[Andreas Kuhne]

Post by Stephen Gallagher

Post by Carl Meyer
I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.
If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)

So, here's the basic problem. The distributions that are packaging python
2.6 are, basically Red Hat Enterprise Linux 6 and its clones (CentOS,
Scientific Linux, Oracle, etc.) and SUSE Linux Enterprise Server 11. These
two distributions make up a significant percentage of the enterprise
deployment space. Neither of these distributions ships Django itself. For
RHEL, the Fedora Project provides the EPEL add-on repository which is
unsupported and *may* carry Django (though it has proven to be difficult,
more on that in a minute). For SLES, there is OpenSUSE which acts
similarly. These are community-sponsored and generally limited to only
packaging what upstream provides, since with no corporate backing and
engineering support, backporting patches from newer releases is unlikely to
happen.
The reason that neither of these distributions carries Django is
specifically because of the short lifecycle of Django. The LTM releases
(1.4 and the upcoming 1.8) are somewhat better aligned with the goals of
enterprise distributions, but even those approximately three-year lifespans
are significantly shorter than the ten years that the enterprise
distributions want to maintain. So the chances of Django ever being shipped
by a company capable of supporting it for that length of time is basically
zero. (Not unless Django someday becomes a critical part of the standard
Linux platform).
In the Enterprise software space, there's an average of a two-year period
between a new version of software becoming available and companies actually
deploying it. This essentially means that an LTM release needs to be at
minimum four years long, since it will require half of the supported
lifecycle for consumers to convert over to it and they'll need the other
half of it in order to migrate to the next version. (Also, most companies
don't like constant migrations like this).
So, I realize that Django 1.6 is not an LTM release, and so asking for an
extension on it is probably unlikely to happen. I'd like to see 1.4
supported for at least the two-year migration period to 1.8, though (with
1.8 planned to accommodate the future migration as well).
Also, is there any chance at all that python 2.6 support could be
reintroduced to Django 1.8? That would make it plausible to migrate
existing users to an LTM release at least, buying time to figure further
plans out.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

I think the main thing here is that python 2.6 has already reached end of
life in October 2013. That's 1 œ years ago! So opting for a dead version of
python to be used is not really the right way to go for the django
developers IMHO. I understand that python 2.6 is available via the package
manager in all of the enterprise distributions you are citing, however, it
should be possible (as someone already suggested) to compile at least 2.7
if not python 3 yourself and run them in virtualenvs (which you should be
doing anyway).

Maintaining old versions of python and several versions of the django
framework will only make things harder for the developers, which will
eventually just delay the development process, making vital security
releases take longer to be deployed. I understand the problems you are
having with python 2.6 not being supported, but frankly I don't see that to
be a django issue, but rather the enterprise server versions that are
running a python version past it's end of life.

Regards,

Andréas

[Bill Freeman]

You should really decouple yourself from the distro's choices, saving
headaches in the future. Let me expand on Avraham's suggestion.

There is little difficulty in having more than one version of python on a
box. The main caution here is that the distrio's use of python might
depend on that python being a 2.6. That means that (ignoring PATH
modifications and use of virtualenvs) that typing "python" should get you a
2.6.. If your distro offers a 2.7 package, it is probably built so that
"python" gets you a 2.6, and "python2.7" gets you a 2.7, and the distor's
python based tools will continue to work (as) fine (as they ever did).

But I don't recommend using a distro 2.7 package, even if available. You
become subject to them doing something bizarre in an update. You have much
better control if you build it yourself. Avoiding replacing what you get
when you type "python" is easy enough: instead of "make install" use "make
altinstall", which does everything except "ln python2.7 python". Another
approach, used where I work, is to set the install path to a directory not
included in the default PATH setting, but then you can't simply type
"python2.7" (at least as root) to get a 2.7, or, more to the point, you
have to give a full path to virtualenv's -p flag. It takes some fiddling
(last time I did this) to be certain that you have all the necessary
development libraries (-devel on RPM based systems), since, for some,
python will still build, but some features won't be available. You may not
care about some of them now (readline support is a case in point) but they
don't hurt anything, and it's better than rebuilding later. Document what
you had to add for future reference.

Another requirement, if you are using mod_wsgi, is to re-link it against
your python. A given httpd - mod_wsgi install can only use one version.of
python. This, in practice, means building your own mod_wsgi, rather than
using a distro version. And if you're going this far, you may as well take
full control by building Apache httpd as well, though, so long as a
suitable development package is available, you may not need to.. It's not
as big a deal as it may sound.

If you're not using httpd/mod_wsgi, I can't offer any advice on what may be
required, since I haven't done my own installs of ngnx, etc.

Bill

Post by Andreas Kuhne

Post by Stephen Gallagher

Post by Carl Meyer
I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.
If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)

So, here's the basic problem. The distributions that are packaging python
2.6 are, basically Red Hat Enterprise Linux 6 and its clones (CentOS,
Scientific Linux, Oracle, etc.) and SUSE Linux Enterprise Server 11. These
two distributions make up a significant percentage of the enterprise
deployment space. Neither of these distributions ships Django itself. For
RHEL, the Fedora Project provides the EPEL add-on repository which is
unsupported and *may* carry Django (though it has proven to be difficult,
more on that in a minute). For SLES, there is OpenSUSE which acts
similarly. These are community-sponsored and generally limited to only
packaging what upstream provides, since with no corporate backing and
engineering support, backporting patches from newer releases is unlikely to
happen.
The reason that neither of these distributions carries Django is
specifically because of the short lifecycle of Django. The LTM releases
(1.4 and the upcoming 1.8) are somewhat better aligned with the goals of
enterprise distributions, but even those approximately three-year lifespans
are significantly shorter than the ten years that the enterprise
distributions want to maintain. So the chances of Django ever being shipped
by a company capable of supporting it for that length of time is basically
zero. (Not unless Django someday becomes a critical part of the standard
Linux platform).
In the Enterprise software space, there's an average of a two-year period
between a new version of software becoming available and companies actually
deploying it. This essentially means that an LTM release needs to be at
minimum four years long, since it will require half of the supported
lifecycle for consumers to convert over to it and they'll need the other
half of it in order to migrate to the next version. (Also, most companies
don't like constant migrations like this).
So, I realize that Django 1.6 is not an LTM release, and so asking for an
extension on it is probably unlikely to happen. I'd like to see 1.4
supported for at least the two-year migration period to 1.8, though (with
1.8 planned to accommodate the future migration as well).
Also, is there any chance at all that python 2.6 support could be
reintroduced to Django 1.8? That would make it plausible to migrate
existing users to an LTM release at least, buying time to figure further
plans out.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

I think the main thing here is that python 2.6 has already reached end of
life in October 2013. That's 1 œ years ago! So opting for a dead version of
python to be used is not really the right way to go for the django
developers IMHO. I understand that python 2.6 is available via the package
manager in all of the enterprise distributions you are citing, however, it
should be possible (as someone already suggested) to compile at least 2.7
if not python 3 yourself and run them in virtualenvs (which you should be
doing anyway).
Maintaining old versions of python and several versions of the django
framework will only make things harder for the developers, which will
eventually just delay the development process, making vital security
releases take longer to be deployed. I understand the problems you are
having with python 2.6 not being supported, but frankly I don't see that to
be a django issue, but rather the enterprise server versions that are
running a python version past it's end of life.
Regards,
Andréas
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CALXYUbmpPr6sDqQDQZ0iAUjK%3DJTmqo5mUL1jyDmGa2hFD_U1%3DQ%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CALXYUbmpPr6sDqQDQZ0iAUjK%3DJTmqo5mUL1jyDmGa2hFD_U1%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Tom Evans]

On Wed, Mar 11, 2015 at 12:53 PM, Andreas Kuhne

Post by Andreas Kuhne
I think the main thing here is that python 2.6 has already reached end of
life in October 2013. That's 1 ½ years ago! So opting for a dead version of
python to be used is not really the right way to go for the django
developers IMHO. I understand that python 2.6 is available via the package
manager in all of the enterprise distributions you are citing, however, it
should be possible (as someone already suggested) to compile at least 2.7 if
not python 3 yourself and run them in virtualenvs (which you should be doing
anyway).

For enterprise operating systems, the packages that are provided by
them, are supported by them. Python 2.6 is still the supported python
version in RHEL 6 - its not end of life - and will continue to be
supported until (at the earliest) Oct 31, 2016. Up until that point,
any security issue in python 2.6 will be backported by the OS vendor,
and a new package is released.

For instance, in RHEL 6, the supported version of apache is 2.2.15.
2.2.15 is old, it was released March 2010, and has lots of bugs, but
when you install it in RHEL 6, you actually get (today) 2.2.15.39.el6,
which is patched to fix all security issues between 2.2.15 and 2.2.29
(and possibly bug fixes for things that have yet to be released by
httpd project).

Using a self compiled python 2.7 would not be supported by the OS
vendor, and so would require a separate support contract. For RHEL6,
you can "get" python2.7 by using the Fedora SCL collections, but this
also isn't covered by the OS support contract (iirc).

This is not hypothetical issues. If you build your own python package,
you are responsible for building, packaging and supporting it. When
there are security issues with the version you have, you need to know
about it, and have enough time to deal with it. If your business is
not packaging up software, that is a waste of time, it is better to
pay someone to do it for you, which is why we have vendor supported OS
+ packages, you simply need to have the support contract.

Obviously, not everyone has these issues. Not everyone cares - move
fast and break things is good..

Cheers

Tom

[Carl Meyer]

Hi Stephen,

Post by Stephen Gallagher
So, here's the basic problem. The distributions that are packaging
python 2.6 are, basically Red Hat Enterprise Linux 6 and its clones
(CentOS, Scientific Linux, Oracle, etc.) and SUSE Linux Enterprise
Server 11. These two distributions make up a significant percentage of
the enterprise deployment space. Neither of these distributions ships
Django itself. For RHEL, the Fedora Project provides the EPEL add-on
repository which is unsupported and *may* carry Django (though it has
proven to be difficult, more on that in a minute). For SLES, there is
OpenSUSE which acts similarly. These are community-sponsored and
generally limited to only packaging what upstream provides, since with
no corporate backing and engineering support, backporting patches from
newer releases is unlikely to happen.
The reason that neither of these distributions carries Django is
specifically because of the short lifecycle of Django. The LTM releases
(1.4 and the upcoming 1.8) are somewhat better aligned with the goals of
enterprise distributions, but even those approximately three-year
lifespans are significantly shorter than the ten years that the
enterprise distributions want to maintain. So the chances of Django ever
being shipped by a company capable of supporting it for that length of
time is basically zero. (Not unless Django someday becomes a critical
part of the standard Linux platform).
In the Enterprise software space, there's an average of a two-year
period between a new version of software becoming available and
companies actually deploying it. This essentially means that an LTM
release needs to be at minimum four years long, since it will require
half of the supported lifecycle for consumers to convert over to it and
they'll need the other half of it in order to migrate to the next
version. (Also, most companies don't like constant migrations like this).

It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an LTS release
under current policy), to accommodate these enterprise users on dead (to
upstream) Python versions.

I remain quite unconvinced that this "someone" should be the Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.

Post by Stephen Gallagher
So, I realize that Django 1.6 is not an LTM release, and so asking for
an extension on it is probably unlikely to happen. I'd like to see 1.4
supported for at least the two-year migration period to 1.8, though
(with 1.8 planned to accommodate the future migration as well).

I think the current plan is for a 6-month support window for 1.4 after
the release of 1.8. (Tim can probably correct me if I'm wrong - I know
there was discussion about 3 months vs 6 months; I thought we settled on
six.)

Post by Stephen Gallagher
Also, is there any chance at all that python 2.6 support could be
reintroduced to Django 1.8? That would make it plausible to migrate
existing users to an LTM release at least, buying time to figure further
plans out.

I think that's extremely unlikely.

Carl

[Stephen Gallagher]

Post by Carl Meyer
It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an LTS release
under current policy), to accommodate these enterprise users on dead (to
upstream) Python versions.
I remain quite unconvinced that this "someone" should be the Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.

Sure, I both understand and respect that. The problem is that it moves the
problem further up the stack and closer to the end-users.

The platform vendor (Red Hat, SUSE, etc.) won't take on the responsibility
for every package, or likely any package that doesn't directly support
something they are trying to sell to a customer. Hence why the major
vendors don't ship a copy for themselves.

The community-supported add-ons are all volunteer efforts, most often by
amateur packagers who are only in rare occasions equipped to do real
engineering work to backport patches. These people rely on the upstreams
continuing to support the packages so they can package the updated
releases. Sometimes this leads to an upstream killing off support for a
release and the add-on repository being unable to upgrade. This is bad for
everyone, because over time this *will* (not may) end up with packages in
the wild with known vulnerabilities and little-to-no way to address it.

So the responsibility then goes to the framework developers who have more
engineering knowledge about the subject but generally fewer resources to
spare. So the answer there is that "someone else" needs to step up and take
over the security maintenance. Unfortunately, that now brings it up to the
application developers.

Application developers rarely know the internals of the packages they
depend on; generally they consume the public API and don't think twice
about the rest of the implementation. Similar to the framework developers,
they have limited resources best spent on delivering something their
customers can use. With a lack of knowledge of the framework, they're not
generally equipped to do the maintenance themselves. Traditionally, this
results in a functional equivalent to the worst-case of the add-on
repository situation above: application developers just bundle a version of
the framework that worked when they implemented it and *never update it*.
This inevitably ends with something that appears to work for their users
but will eventually bit-rot and become a liability.

Lastly, we have the application users. Let's be honest: do we want
end-users responsible for maintaining the complete stack? They're going to
do what they always do: find and install one version (no matter how old)
and just use it until something goes wrong, at which point they have no one
to call who knows the system and can fix it for them.




When looking at the big picture, the best thing for end-users is for the
lowest levels of this stack to take control of maintenance for it. In cases
where the stack is critical infrastructure (like the Python interpreter
itself), the OS vendor will take it over, even to the degree of maintaining
it past its upstream end-of-life. Where it's not critical infrastructure,
the upstream developers are the best-equipped to manage maintenance.
Further up in the stack than that, you have a very unbalanced scale of
decreasing knowledge vs increasing need for stability.

[Tim Graham]

Having managed the last few security releases for Django, I'll say it's one
of my least favorite tasks and I'm quite looking forward to dropping
support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if
there's sufficient interest that we could raise funds to support this
effort outside of my normal duties as Django fellow, there's a chance you
could convince me to continue backporting patches and preparing releases
for these versions. I'm not quite sure how the logistics of such an
arrangement would work, but just thought I'd throw the idea out there and
see if anyone is ready to back the effort financially. I'd want the
endorsement of the core team before finalizing anything.

Post by Stephen Gallagher

Post by Carl Meyer
It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an LTS release
under current policy), to accommodate these enterprise users on dead (to
upstream) Python versions.
I remain quite unconvinced that this "someone" should be the Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.

Sure, I both understand and respect that. The problem is that it moves the
problem further up the stack and closer to the end-users.
The platform vendor (Red Hat, SUSE, etc.) won't take on the responsibility
for every package, or likely any package that doesn't directly support
something they are trying to sell to a customer. Hence why the major
vendors don't ship a copy for themselves.
The community-supported add-ons are all volunteer efforts, most often by
amateur packagers who are only in rare occasions equipped to do real
engineering work to backport patches. These people rely on the upstreams
continuing to support the packages so they can package the updated
releases. Sometimes this leads to an upstream killing off support for a
release and the add-on repository being unable to upgrade. This is bad for
everyone, because over time this *will* (not may) end up with packages in
the wild with known vulnerabilities and little-to-no way to address it.
So the responsibility then goes to the framework developers who have more
engineering knowledge about the subject but generally fewer resources to
spare. So the answer there is that "someone else" needs to step up and take
over the security maintenance. Unfortunately, that now brings it up to the
application developers.
Application developers rarely know the internals of the packages they
depend on; generally they consume the public API and don't think twice
about the rest of the implementation. Similar to the framework developers,
they have limited resources best spent on delivering something their
customers can use. With a lack of knowledge of the framework, they're not
generally equipped to do the maintenance themselves. Traditionally, this
results in a functional equivalent to the worst-case of the add-on
repository situation above: application developers just bundle a version of
the framework that worked when they implemented it and *never update it*.
This inevitably ends with something that appears to work for their users
but will eventually bit-rot and become a liability.
Lastly, we have the application users. Let's be honest: do we want
end-users responsible for maintaining the complete stack? They're going to
do what they always do: find and install one version (no matter how old)
and just use it until something goes wrong, at which point they have no one
to call who knows the system and can fix it for them.
When looking at the big picture, the best thing for end-users is for the
lowest levels of this stack to take control of maintenance for it. In cases
where the stack is critical infrastructure (like the Python interpreter
itself), the OS vendor will take it over, even to the degree of maintaining
it past its upstream end-of-life. Where it's not critical infrastructure,
the upstream developers are the best-equipped to manage maintenance.
Further up in the stack than that, you have a very unbalanced scale of
decreasing knowledge vs increasing need for stability.

[Christian Hammond]

Hey Tim,

I can definitely relate. It's not fun maintaining security releases (or
fixes of any sort) for older versions of the software. Been there (am there
now).

We're trying to encourage people to move to Python 2.7 so that we can
upgrade, but this is the enterprise. It's not an easy task. (Look how long
Microsoft tried to get people off of IE6.) Python 2.6 is still wildly
populate in the enterprise. The sad fact is, even once we leave Python 2.6
behind, there's going to be at least a few hundred companies with servers
running Django 1.6.x who will not be upgrading for quite some time, no
matter what any of us do or say (just as there are still at least a hundred
running against Django 1.4). Once security releases stop for 1.6, these
companies are going to be vulnerable to any new exploits.

I wholeheartedly agree about using virtualenv and staying on top of the
latest releases, but we've had little luck in getting administrators to
move in that direction. We've been trying to work with a handful recently
who insist on running older versions with very custom deployments because
"it works and we don't want to risk anything," but at the same time they're
quick to pull in any security updates offered by RHEL/us/whoever, as it's a
liability otherwise. Especially since, as others have said, they have
support contracts in place that they're paying a lot of money for, and will
not violate. The advice on virtualenvs and building your own Python is
good, and I appreciate it and agree with it, but it just won't make a dent
in the number of enterprise Python 2.6/Django 1.6 users out there.

So... we're in a tough position now. Hundreds of companies *will* be on
Django 1.6 for the next couple of years at least, no matter what advice we
give or what any of us choose to do. Since newer versions of Django don't
support Python 2.6, it'll be even harder for these companies to upgrade
without rebuilding their infrastructure, further ensuring that they'll
stick with what they have.

I wish I could say that we could fully-fund future Django 1.6 security
updates, but our company is young and still trying to stay afloat, so our
funds are limited. I'll personally contribute what I can afford to the
cause, if I knew what sort of target there was, and how likely this would
be to happen. I don't want to leave our users hanging and vulnerable.

The only other course of action I can think of is to maintain some sort of
unofficial fork of Django 1.6 with backported security updates, but I think
that's just going to cause more problems than it solves in far too many
areas.

Maybe I'm rambling at this point. It's a pretty major issue for us, and
we're feeling a bit stuck on what to do about this. Since we use Django as
a component in a distributable webapp, instead of in-house in a controlled
environment, we seem to hit problems that most people don't have to deal
with.

Thanks again for your thoughts on this, everyone.

Christian

Post by Tim Graham
Having managed the last few security releases for Django, I'll say it's
one of my least favorite tasks and I'm quite looking forward to dropping
support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if
there's sufficient interest that we could raise funds to support this
effort outside of my normal duties as Django fellow, there's a chance you
could convince me to continue backporting patches and preparing releases
for these versions. I'm not quite sure how the logistics of such an
arrangement would work, but just thought I'd throw the idea out there and
see if anyone is ready to back the effort financially. I'd want the
endorsement of the core team before finalizing anything.

Post by Stephen Gallagher

Post by Carl Meyer
It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an LTS release
under current policy), to accommodate these enterprise users on dead (to
upstream) Python versions.
I remain quite unconvinced that this "someone" should be the Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.

Sure, I both understand and respect that. The problem is that it moves
the problem further up the stack and closer to the end-users.
The platform vendor (Red Hat, SUSE, etc.) won't take on the
responsibility for every package, or likely any package that doesn't
directly support something they are trying to sell to a customer. Hence why
the major vendors don't ship a copy for themselves.
The community-supported add-ons are all volunteer efforts, most often by
amateur packagers who are only in rare occasions equipped to do real
engineering work to backport patches. These people rely on the upstreams
continuing to support the packages so they can package the updated
releases. Sometimes this leads to an upstream killing off support for a
release and the add-on repository being unable to upgrade. This is bad for
everyone, because over time this *will* (not may) end up with packages in
the wild with known vulnerabilities and little-to-no way to address it.
So the responsibility then goes to the framework developers who have more
engineering knowledge about the subject but generally fewer resources to
spare. So the answer there is that "someone else" needs to step up and take
over the security maintenance. Unfortunately, that now brings it up to the
application developers.
Application developers rarely know the internals of the packages they
depend on; generally they consume the public API and don't think twice
about the rest of the implementation. Similar to the framework developers,
they have limited resources best spent on delivering something their
customers can use. With a lack of knowledge of the framework, they're not
generally equipped to do the maintenance themselves. Traditionally, this
results in a functional equivalent to the worst-case of the add-on
repository situation above: application developers just bundle a version of
the framework that worked when they implemented it and *never update it*.
This inevitably ends with something that appears to work for their users
but will eventually bit-rot and become a liability.
Lastly, we have the application users. Let's be honest: do we want
end-users responsible for maintaining the complete stack? They're going to
do what they always do: find and install one version (no matter how old)
and just use it until something goes wrong, at which point they have no one
to call who knows the system and can fix it for them.
When looking at the big picture, the best thing for end-users is for the
lowest levels of this stack to take control of maintenance for it. In cases
where the stack is critical infrastructure (like the Python interpreter
itself), the OS vendor will take it over, even to the degree of maintaining
it past its upstream end-of-life. Where it's not critical infrastructure,
the upstream developers are the best-equipped to manage maintenance.
Further up in the stack than that, you have a very unbalanced scale of
decreasing knowledge vs increasing need for stability.

[Mike Dewhirst]

Maybe ... some effort to solve the infrastructure issue would make it
worth kickstarter funding.

A couple of colleagues are pushing me towards Docker as a packaged
Python 3.4 environment but that is beyond my interest atm.

I am running a dedicated production server on Ubuntu 14.04 which more or
less forces me to stick with Python 2.7. I would like to move to Python
3.x using virtualenv but I don't want to mess with stuff which is working.

Maybe a really nice solution would be a kickstarter project to develop a
deployment tool to create a predictable, supportable modern environment
on "old" boxes and to vaccuum up the existing Django sites running on
bare metal.

In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv
approach would be covered by standard Ubuntu support. I have only
glanced at Docker so I don't know how valid that might be.

Just a random thought.

Mike

Post by Christian Hammond
Hey Tim,
I can definitely relate. It's not fun maintaining security releases (or
fixes of any sort) for older versions of the software. Been there (am
there now).
We're trying to encourage people to move to Python 2.7 so that we can
upgrade, but this is the enterprise. It's not an easy task. (Look how
long Microsoft tried to get people off of IE6.) Python 2.6 is still
wildly populate in the enterprise. The sad fact is, even once we leave
Python 2.6 behind, there's going to be at least a few hundred companies
with servers running Django 1.6.x who will not be upgrading for quite
some time, no matter what any of us do or say (just as there are still
at least a hundred running against Django 1.4). Once security releases
stop for 1.6, these companies are going to be vulnerable to any new
exploits.
I wholeheartedly agree about using virtualenv and staying on top of the
latest releases, but we've had little luck in getting administrators to
move in that direction. We've been trying to work with a handful
recently who insist on running older versions with very custom
deployments because "it works and we don't want to risk anything," but
at the same time they're quick to pull in any security updates offered
by RHEL/us/whoever, as it's a liability otherwise. Especially since, as
others have said, they have support contracts in place that they're
paying a lot of money for, and will not violate. The advice on
virtualenvs and building your own Python is good, and I appreciate it
and agree with it, but it just won't make a dent in the number of
enterprise Python 2.6/Django 1.6 users out there.
So... we're in a tough position now. Hundreds of companies *will* be on
Django 1.6 for the next couple of years at least, no matter what advice
we give or what any of us choose to do. Since newer versions of Django
don't support Python 2.6, it'll be even harder for these companies to
upgrade without rebuilding their infrastructure, further ensuring that
they'll stick with what they have.
I wish I could say that we could fully-fund future Django 1.6 security
updates, but our company is young and still trying to stay afloat, so
our funds are limited. I'll personally contribute what I can afford to
the cause, if I knew what sort of target there was, and how likely this
would be to happen. I don't want to leave our users hanging and vulnerable.
The only other course of action I can think of is to maintain some sort
of unofficial fork of Django 1.6 with backported security updates, but I
think that's just going to cause more problems than it solves in far too
many areas.
Maybe I'm rambling at this point. It's a pretty major issue for us, and
we're feeling a bit stuck on what to do about this. Since we use Django
as a component in a distributable webapp, instead of in-house in a
controlled environment, we seem to hit problems that most people don't
have to deal with.
Thanks again for your thoughts on this, everyone.
Christian
Having managed the last few security releases for Django, I'll say
it's one of my least favorite tasks and I'm quite looking forward to
dropping support for 1.4 (which supports Python 2.5) and 1.6 (Python
2.6). But, if there's sufficient interest that we could raise funds
to support this effort outside of my normal duties as Django fellow,
there's a chance you could convince me to continue backporting
patches and preparing releases for these versions. I'm not quite
sure how the logistics of such an arrangement would work, but just
thought I'd throw the idea out there and see if anyone is ready to
back the effort financially. I'd want the endorsement of the core
team before finalizing anything.
It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an
LTS release
under current policy), to accommodate these enterprise users
on dead (to
upstream) Python versions.
I remain quite unconvinced that this "someone" should be the
Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.
Sure, I both understand and respect that. The problem is that it
moves the problem further up the stack and closer to the end-users.
The platform vendor (Red Hat, SUSE, etc.) won't take on the
responsibility for every package, or likely any package that
doesn't directly support something they are trying to sell to a
customer. Hence why the major vendors don't ship a copy for
themselves.
The community-supported add-ons are all volunteer efforts, most
often by amateur packagers who are only in rare occasions
equipped to do real engineering work to backport patches. These
people rely on the upstreams continuing to support the packages
so they can package the updated releases. Sometimes this leads
to an upstream killing off support for a release and the add-on
repository being unable to upgrade. This is bad for everyone,
because over time this *will* (not may) end up with packages in
the wild with known vulnerabilities and little-to-no way to address it.
So the responsibility then goes to the framework developers who
have more engineering knowledge about the subject but generally
fewer resources to spare. So the answer there is that "someone
else" needs to step up and take over the security maintenance.
Unfortunately, that now brings it up to the application developers.
Application developers rarely know the internals of the packages
they depend on; generally they consume the public API and don't
think twice about the rest of the implementation. Similar to the
framework developers, they have limited resources best spent on
delivering something their customers can use. With a lack of
knowledge of the framework, they're not generally equipped to do
the maintenance themselves. Traditionally, this results in a
functional equivalent to the worst-case of the add-on repository
situation above: application developers just bundle a version of
the framework that worked when they implemented it and *never
update it*. This inevitably ends with something that appears to
work for their users but will eventually bit-rot and become a
liability.
Lastly, we have the application users. Let's be honest: do we
want end-users responsible for maintaining the complete stack?
They're going to do what they always do: find and install one
version (no matter how old) and just use it until something goes
wrong, at which point they have no one to call who knows the
system and can fix it for them.
When looking at the big picture, the best thing for end-users is
for the lowest levels of this stack to take control of
maintenance for it. In cases where the stack is critical
infrastructure (like the Python interpreter itself), the OS
vendor will take it over, even to the degree of maintaining it
past its upstream end-of-life. Where it's not critical
infrastructure, the upstream developers are the best-equipped to
manage maintenance. Further up in the stack than that, you have
a very unbalanced scale of decreasing knowledge vs increasing
need for stability.
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

[Russell Keith-Magee]

Post by Mike Dewhirst
Maybe ... some effort to solve the infrastructure issue would make it
worth kickstarter funding.
A couple of colleagues are pushing me towards Docker as a packaged Python
3.4 environment but that is beyond my interest atm.
I am running a dedicated production server on Ubuntu 14.04 which more or
less forces me to stick with Python 2.7. I would like to move to Python 3.x
using virtualenv but I don't want to mess with stuff which is working.
Maybe a really nice solution would be a kickstarter project to develop a
deployment tool to create a predictable, supportable modern environment on
"old" boxes and to vaccuum up the existing Django sites running on bare
metal.
In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv
approach would be covered by standard Ubuntu support. I have only glanced
at Docker so I don't know how valid that might be.

Docker isn't needed for any of this, especially on Ubuntu 14.04. Python 2
and Python 3 can co-exist, and Python3.4 is part of the standard repo for
Ubuntu 14.04. Even if it wasn't, you could install Python to a user-space
directory, and create a virtualenv based on *that* version of Python.

However, in a broader sense, I think you'll find that the audience of
people who need this tool are almost by definition the set of people who
wouldn't be able to use it.

If a company is locked into Python 2.6, it's because they're on a
Enterprise Supported Version (tm) of some operating system; in that sort of
environment, installing and using *anything* that isn't provided by the
vendor is a non-starter. Even if a tool *was* developed, you'd need to get
it deployed in-channel - and that could take years... or you could just
upgrade your system :-)

FWIW: This is the exact type of problem that RedHat software collections
are designed to fix - RHEL wore a lot of flack for being so pathologically
behind the times (the Python interpreter being one key component). RedHat's
response has been to introduce software collections - an officially
mandated set of tools that can be updated much more regularly, official
blessed by the manufacturer.

https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/

Obviously, this won't help if you're not on RHEL6 or 7 - but it's an
indication that some enterprise vendors are listening.

Yours,
Russ Magee %-)

[Stephen Gallagher]

Maybe ... some effort to solve the infrastructure issue would make it worth kickstarter funding.
A couple of colleagues are pushing me towards Docker as a packaged Python 3.4 environment but that is beyond my interest atm.
I am running a dedicated production server on Ubuntu 14.04 which more or less forces me to stick with Python 2.7. I would like to move to Python 3.x using virtualenv but I don't want to mess with stuff which is working.
Maybe a really nice solution would be a kickstarter project to develop a deployment tool to create a predictable, supportable modern environment on "old" boxes and to vaccuum up the existing Django sites running on bare metal.
In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv approach would be covered by standard Ubuntu support. I have only glanced at Docker so I don't know how valid that might be.

Docker isn't needed for any of this, especially on Ubuntu 14.04. Python 2 and Python 3 can co-exist, and Python3.4 is part of the standard repo for Ubuntu 14.04. Even if it wasn't, you could install Python to a user-space directory, and create a virtualenv based on *that* version of Python.
However, in a broader sense, I think you'll find that the audience of people who need this tool are almost by definition the set of people who wouldn't be able to use it.
If a company is locked into Python 2.6, it's because they're on a Enterprise Supported Version (tm) of some operating system; in that sort of environment, installing and using *anything* that isn't provided by the vendor is a non-starter. Even if a tool *was* developed, you'd need to get it deployed in-channel - and that could take years... or you could just upgrade your system :-)

I think you'll find that this is a bit overstated. Customers install plenty of software that isn't provided by Red Hat. I think you might be amazed at how popular the public Extra Packages for Enterprise Linux repository is (it's a sub-project of Fedora that provides many packages from the Fedora collection built for RHEL).

What they don't do (except in dire need) is install alternative versions of software that *is* provided by their support contract. This is because for most companies, the added features aren't worth the self-maintenance. No one who isn't an OS vendor can keep up with the security issues on all of that software.

FWIW: This is the exact type of problem that RedHat software collections are designed to fix - RHEL wore a lot of flack for being so pathologically behind the times (the Python interpreter being one key component). RedHat's response has been to introduce software collections - an officially mandated set of tools that can be updated much more regularly, official blessed by the manufacturer.
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/
Obviously, this won't help if you're not on RHEL6 or 7 - but it's an indication that some enterprise vendors are listening.

Yes and no, but it's not much of an answer because the double-edged sword here is that the Software Collections also have a much shorter supported lifespan than the main operating system (which guarantees a stable platform for at least ten years). For most companies, rebuilding "that one internal app we maintain" every three years is unrealistic. Not everyone is Twitter or Netflix, doing multiple deploys an hour.

Speaking anecdotally, the average lifetime I've seen of customer-produced internal apps is usually about 7-8 years (generally equivalent to whenever they moved to the latest RHEL release until the moment it goes out of support... sometimes past that, unwisely). You do not want to know how many datacenters are still running RHEL 4 and even RHEL 3.

Yours,
Russ Magee %-)
--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/B74QJaqA0b4/unsubscribe.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq848g%2BUavE0giY2cogrh%3DwY2OzxbeHX9Bv0_SXFD0v0L0oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[James Bennett]

Post by Tim Graham
Having managed the last few security releases for Django, I'll say it's
one of my least favorite tasks and I'm quite looking forward to dropping
support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if
there's sufficient interest that we could raise funds to support this
effort outside of my normal duties as Django fellow, there's a chance you
could convince me to continue backporting patches and preparing releases
for these versions. I'm not quite sure how the logistics of such an
arrangement would work, but just thought I'd throw the idea out there and
see if anyone is ready to back the effort financially. I'd want the
endorsement of the core team before finalizing anything.

Way, way, *way* back in the day, there was unofficial bugfix support for
pre-magic-removal versions of Django run on the basis of "some people who
need it step up and do all the work". It was solely done in SVN and never
involved issuing new releases, so anyone running off the maintenance branch
had to just update their checkout whenever a fix landed in it.

I'm not opposed to allowing that again -- and in fact I was one of the
people who did extended maintenance for pre-m-r Django because my employer
at the time needed it -- but I think we should carefully consider how it's
going to work before trying it, since we no longer have the ability to give
partial commit bits.

[Russell Keith-Magee]

Post by James Bennett

Post by Tim Graham
Having managed the last few security releases for Django, I'll say it's
one of my least favorite tasks and I'm quite looking forward to dropping
support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if
there's sufficient interest that we could raise funds to support this
effort outside of my normal duties as Django fellow, there's a chance you
could convince me to continue backporting patches and preparing releases
for these versions. I'm not quite sure how the logistics of such an
arrangement would work, but just thought I'd throw the idea out there and
see if anyone is ready to back the effort financially. I'd want the
endorsement of the core team before finalizing anything.

Way, way, *way* back in the day, there was unofficial bugfix support for
pre-magic-removal versions of Django run on the basis of "some people who
need it step up and do all the work". It was solely done in SVN and never
involved issuing new releases, so anyone running off the maintenance branch
had to just update their checkout whenever a fix landed in it.
I'm not opposed to allowing that again -- and in fact I was one of the
people who did extended maintenance for pre-m-r Django because my employer
at the time needed it -- but I think we should carefully consider how it's
going to work before trying it, since we no longer have the ability to give
partial commit bits

Agreed that this is an approach we could take - but I don't think the lack
of a partial commit bit isn't a major issue IMHO.

At a technical level, Git gives anyone the ability to fork Django's
repository. There's no *technical* reason that someone couldn't maintain a
1.6 branch *right now* - the only restrictions are that they couldn't call
that repository official (as per BSD licensing terms), and they wouldn't
have access to security patches until everyone else did.

However, both of these are solvable problems.

The only thing that makes Django's Github repository "official" is because
the core team says it is. If someone wants to take on the task of back
porting all the security patches to 1.6, we (as a project) can point to
that repository if we want. If we're interested in doing 1.6 support as an
"unofficial" subproject, then it seems appropriate to me that the
repository *isn't* Django's core repository; picking a third-party vendor's
repo sounds like the right way to do it.

As for getting the patches ahead of time - I'd be more than happy for an
appropriately qualified and trustworthy individual/company to be added to
the security pre-notification list.

So - it really just comes down to someone having the enthusiasm to maintain
the branch. Christian has been around the Django project for a long time
(he was a contributor to Django Evolution from very early on, and took over
maintenance of the project when I moved on). If he's got a commercial
interest in continued 1.6 support, and he can spare a couple of hours to do
a backport when a security issue is announced, I'd have no problem adding
him to the pre-notification list, and adding some documentation pointing at
his fork of Django as an "unofficial 1.6 repository". If Christian hasn't
got the time to do this, but he (and/or anyone else) can throw some funds
at Tim, Tim is already on the security notification list.

Yours
Russ Magee %-)

[Carl Meyer]

Post by James Bennett
Way, way, *way* back in the day, there was unofficial bugfix support
for pre-magic-removal versions of Django run on the basis of "some
people who need it step up and do all the work". It was solely done
in SVN and never involved issuing new releases, so anyone running
off the maintenance branch had to just update their checkout
whenever a fix landed in it.
I'm not opposed to allowing that again -- and in fact I was one of
the people who did extended maintenance for pre-m-r Django because
my employer at the time needed it -- but I think we should carefully
consider how it's going to work before trying it, since we no longer
have the ability to give partial commit bits
Agreed that this is an approach we could take - but I don't think the
lack of a partial commit bit isn't a major issue IMHO.
At a technical level, Git gives anyone the ability to fork Django's
repository. There's no *technical* reason that someone couldn't maintain
a 1.6 branch *right now* - the only restrictions are that they couldn't
call that repository official (as per BSD licensing terms), and they
wouldn't have access to security patches until everyone else did.
However, both of these are solvable problems.
The only thing that makes Django's Github repository "official" is
because the core team says it is. If someone wants to take on the task
of back porting all the security patches to 1.6, we (as a project) can
point to that repository if we want. If we're interested in doing 1.6
support as an "unofficial" subproject, then it seems appropriate to me
that the repository *isn't* Django's core repository; picking a
third-party vendor's repo sounds like the right way to do it.
As for getting the patches ahead of time - I'd be more than happy for an
appropriately qualified and trustworthy individual/company to be added
to the security pre-notification list.
So - it really just comes down to someone having the enthusiasm to
maintain the branch. Christian has been around the Django project for a
long time (he was a contributor to Django Evolution from very early on,
and took over maintenance of the project when I moved on). If he's got a
commercial interest in continued 1.6 support, and he can spare a couple
of hours to do a backport when a security issue is announced, I'd have
no problem adding him to the pre-notification list, and adding some
documentation pointing at his fork of Django as an "unofficial 1.6
repository". If Christian hasn't got the time to do this, but he (and/or
anyone else) can throw some funds at Tim, Tim is already on the security
notification list.

I agree with all of this. I think that the Django core team will not
provide this extended support for 1.6 (because it gives the impression
that Python 2.6 is a supported and secure platform, which is only true
for the subset of our user base on certain extended-support distros),
and I don't think that extended-support releases of 1.6 should or will
ever appear on pypi.python.org/pypi/Django.

But I think that anyone who feels the need for this extended support can
feel free to raise the resources to make it happen and do it in a github
fork. If someone planning to maintain such a fork applied for
pre-notification of security releases, and could demonstrate significant
support for their effort, I would be in favor of that application.

And I think that if "that person" ends up being Tim Graham, as an
individual outside of his duties as Django Fellow, that's his choice and
I don't see any problem with it. We've already established a precedent,
several times over, for members of the core team to be paid for certain
tasks that parts of the community need or want that aren't getting done
otherwise. I would not support the DSF or Django core team sponsoring
the fundraising for this effort, but if a part of the community raises
the funds and Tim wants to accept said funds and do the work, more power
to him, as long as it doesn't detract from his other work as Django Fellow.

Carl

[Tim Graham]

Discussion to be continued on django-developers:
https://groups.google.com/d/topic/django-developers/69fOquu8v-U/discussion

<javascript:>

Post by James Bennett
Way, way, *way* back in the day, there was unofficial bugfix support
for pre-magic-removal versions of Django run on the basis of "some
people who need it step up and do all the work". It was solely done
in SVN and never involved issuing new releases, so anyone running
off the maintenance branch had to just update their checkout
whenever a fix landed in it.
I'm not opposed to allowing that again -- and in fact I was one of
the people who did extended maintenance for pre-m-r Django because
my employer at the time needed it -- but I think we should carefully
consider how it's going to work before trying it, since we no longer
have the ability to give partial commit bits
Agreed that this is an approach we could take - but I don't think the
lack of a partial commit bit isn't a major issue IMHO.
At a technical level, Git gives anyone the ability to fork Django's
repository. There's no *technical* reason that someone couldn't maintain
a 1.6 branch *right now* - the only restrictions are that they couldn't
call that repository official (as per BSD licensing terms), and they
wouldn't have access to security patches until everyone else did.
However, both of these are solvable problems.
The only thing that makes Django's Github repository "official" is
because the core team says it is. If someone wants to take on the task
of back porting all the security patches to 1.6, we (as a project) can
point to that repository if we want. If we're interested in doing 1.6
support as an "unofficial" subproject, then it seems appropriate to me
that the repository *isn't* Django's core repository; picking a
third-party vendor's repo sounds like the right way to do it.
As for getting the patches ahead of time - I'd be more than happy for an
appropriately qualified and trustworthy individual/company to be added
to the security pre-notification list.
So - it really just comes down to someone having the enthusiasm to
maintain the branch. Christian has been around the Django project for a
long time (he was a contributor to Django Evolution from very early on,
and took over maintenance of the project when I moved on). If he's got a
commercial interest in continued 1.6 support, and he can spare a couple
of hours to do a backport when a security issue is announced, I'd have
no problem adding him to the pre-notification list, and adding some
documentation pointing at his fork of Django as an "unofficial 1.6
repository". If Christian hasn't got the time to do this, but he (and/or
anyone else) can throw some funds at Tim, Tim is already on the security
notification list.

I agree with all of this. I think that the Django core team will not
provide this extended support for 1.6 (because it gives the impression
that Python 2.6 is a supported and secure platform, which is only true
for the subset of our user base on certain extended-support distros),
and I don't think that extended-support releases of 1.6 should or will
ever appear on pypi.python.org/pypi/Django.
But I think that anyone who feels the need for this extended support can
feel free to raise the resources to make it happen and do it in a github
fork. If someone planning to maintain such a fork applied for
pre-notification of security releases, and could demonstrate significant
support for their effort, I would be in favor of that application.
And I think that if "that person" ends up being Tim Graham, as an
individual outside of his duties as Django Fellow, that's his choice and
I don't see any problem with it. We've already established a precedent,
several times over, for members of the core team to be paid for certain
tasks that parts of the community need or want that aren't getting done
otherwise. I would not support the DSF or Django core team sponsoring
the fundraising for this effort, but if a part of the community raises
the funds and Tim wants to accept said funds and do the work, more power
to him, as long as it doesn't detract from his other work as Django Fellow.
Carl