On Wednesday, March 11, 2015 at 12:00:25 PM UTC-4, Carl Meyer wrote: > > 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 an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/24c3984b-32a7-4ea2-9680-d7b44c3c09c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
