+Konstantin, the kernel.org sysadmin. The context is that patchwork has just removed (see subject) support for Django 1.6, but I've been told that RHEL/EPEL7 which you run has only that version, so updating to the latest patchwork would now be impossible (again)
> We can't support Django 1.4: it's too long in the tooth and has been > unsupported for too long to even consider. It's also ancient and awful compared to newer versions :) > So I think we need to answer the following question: > > * Are deployers going to install from source/pip? I don't really know. Perhaps Konstantin can chime in. > If not, then we're going to have (a) roll back the Django 1.6 removal > patches, (b) put together a roadmap for future Django version support and > (c) avoid using non-stdlib libraries (outside of Django) going forward. As > Damien pointed out, these actions come with some rather severe costs for > us so I'd like to be absolutely certain of this before I take any actions. > There's the obvious alternative of not caring about LTS installations like kernel.org and simply continue developing the software as is against upstream. *Eventually*, it's going to get to the users, perhaps not as fast as the users (like me) would like. And I'm not suggesting at all that you should consider "LTS distro" support of huge importance. I think in a way part of the problem is that your user audience is also developers (in a different space), so we users might be interested in working on tools improvements ourselves (like the regex auto-delegation feature that Mauro/Laurent have), but there's less incentive to do that if we can't actually benefit from it in a fairly short time frame (and we're more likely to script our way around it instead.) johannes _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork