Em Fri, 06 Nov 2015 17:37:47 +0000 "Finucane, Stephen" <[email protected]> escreveu:
> > On Fri, Nov 06, 2015 at 12:25:18PM -0200, Mauro Carvalho Chehab wrote: > > > > Django 1.8 is LTS so I imagine there should be support coming for this > > in > > > > EPEL, SLES etc. I'm little to no experience with these distros though, > > and > > > > I have no idea how these folks plan/publish their roadmaps. Could you > > advise? > > > > > > It doesn't matter whatever version Django maintainers decide to be their > > > LTS version if they don't sync it with the LTS distro releases. > > > > > The point is: it is a very high risk to run patchwork on any serious > > > projects like the Linux Kernel on some server that doesn't run a LTS > > > distribution. > > > > > > It is also a serious risk to manually maintain its own manually > > > maintained packages on an LTS distro, as you may risk forgetting to do > > > some important security upgrade because the fix is not packaged by > > > inside the distribution. > > > > Just for the record, my opinion on this: there are definitely good > > reasons to want to use distribution packages, but that's the usual > > distro packages vs upstream versions/branches discussion. That's > > especially true for even newer trendy things like Node. > > > > I'd ask for a slice of empathy here. Demanding that a project > > dependencies are based on the union of supported LTS releases across > > distributions will hurt the project. Having constraints like "Patchwork > > has to work from django 1.4 until 2018 because of Debian 7" makes > > development a miserable experience. > > We can't support Django 1.4: it's too long in the tooth and has been > unsupported for too long to even consider. We only just removed Django > 1.6 support so I can consider rolling that back, but unless someone > else wants to contribute patches then it's not going to be viable to > support anything older. Yes, I know. I'm not asking to re-add Django 1.4 support, but just saying that my legs got broken when django 1.4 support got removed. > > > That's an even bigger problem when adding more dependencies into the > > mix. > > You've identified another issue here: non-Django dependencies. At the moment, > we only rely on a very small set of requirements[1], most of which should be > available via system packages. If we can't use pip then we're going to be > very careful not to introduce dependencies that aren't provided by RHEL, > Ubuntu LTS, Debian etc. This is going to severely hamper developer velocity > so I'd like to know for sure that this is necessary before undertaking > anything. > > > I don't need to on, people have discussed at length the impedance > > mismatch between distribution packages and upstream development. There > > are a number of solutions people use to decouple their web applications > > from the underlying system, I'd argue that's even one of the selling > > point of interesting things like Docker: Build your app with its > > dependencies, deploy! > > > > So, I'll just ask if people could at least ponder the question on both > > sides before being very assertive about the "right" way patchwork should > > handle its dependencies and deployment. It's definitely not a black or > > white answer, I have seen package updates in distributions break > > applications as well for instance. > > > > Security doesn't have to mean trusting the distribution (which in turns > > more often than not trusts an upstream), there is something to say about > > trusting an upstream directly. > > > > -- > > Damien > > So I think we need to answer the following question: > > * Are deployers going to install from source/pip? We won't. We don't want to increase the risk of attacks at linuxtv.org. This is something that we've discussed already internally with the other machine sysadmins. There, we'll be using only python/django/etc that are provided by a LTS distribution (currently, Debian 7, but we'll likely migrate to Debian 8 in some future). I guess kernel.org also won't be installing Django from its sources, but that's just my wild guess. I'm c/c Konstantin, as he's the one that answers for kernel.org infrastructure. > 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. > > Mauro: Johannes: Can you provide input here, or direct me to the correct > channels to get this information (mail or IRC). If you need, you can reach me on IRC. My nick is "mchehab". > > Cheers, > Stephen > > PS: There are a million of these on the net, but the Mozilla blog[2] details > installing from pip and the rationale for doing so. Just saying :) > > [1] > https://github.com/getpatchwork/patchwork/blob/946c5b72b2e3f9db851379c1cf68f1f9d7eebe7f/docs/requirements-prod.txt > [2] > https://blog.mozilla.org/webdev/2013/01/11/switching-to-pip-for-python-deployments/ _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
