I believe the future of Django in EPEL is a topic that is being discussed on the EPSCO meetings last week and this week (18:00 UTC on Wednesdays in #fedora-meeting, iirc).
I'm hoping that even if a newer, 1.8 based Django package is added to EPEL6, that the existing one named Django14 can be kept for legacy usage. The Django14 package having that unconventional name would allow a new package to use the more conventional python-django name which is convenient.On Tue, Nov 8, 2016 at 7:05 AM, Stephen Finucane <stephen@xxxxxxxxx> wrote:
Afternoon,
I'm currently working through the final stages of a new release for Patchwork [1]. One of the things that's been discussed extensively in the past is the versions of Django we support. Most sysadmins refuse to use packages outside of those provided by their distro (i.e. no pip). After a long discussion about this time last year [2], we resigned ourselves to having to support the deprecated Django 1.6 and 1.7 releases as these are the most recent version available in EPEL and Debian Stable, respectively. However, the next version of Patchwork introduces a new dependency - Django REST Framework - which is technically avoidable but really should be used. This dependency is available in Debian Testing, but I see no recent version of package in EPEL, sadly.
I looked into packaging DRF, but it seems EPEL doesn't support a modern version of Django. I realize there's been a lot of discussion on this in the past [3][4][5], but I couldn't find any conclusion. As such, I have a question: what would it take to start packaging the *stable* versions of Django (currently 1.8)? Django publishes a timeline for stable vs. non-stable packages, which includes some overlap between the last stable release and the next one, a la Ubuntu [6]. This seems compatible with EPEL's packaging strategies, thus, I imagine it should be possible to package stable versions. When a stable package is deprecated upstream, we could remove from EPEL as expected. Any package that doesn't upgrade to support the latest stable version is probably dead and not worth retaining in EPEL, with some exceptions (Reviewboard).
I realise that, for better or worse, Django 1.6 must be kept (ReviewBoard, for example, is stuck with 1.6 for the foreseeable future [7]). This would probably mean we'd need to create a versioned Django package (python2-django18, python3-django18). However, I'd be willing to help with both this and a DRF package as long as I continue to contribute to and maintain Patchwork (it's been two years and I'm not quitting any time soon).
Is this something that we could put together a game plan on?
Cheers,
Stephen
[1] https://github.com/getpatchwork/patchwork
[2] https://lists.ozlabs.org/pipermail/patchwork/2015-November/ 002046.html
[3] https://lists.fedoraproject.org/archives/list/epel-devel@lis ts.fedoraproject.org/thread/RK G34VEBSKXPKQLZB4H2AH7PPEA4RJV3 /#7I6KXRTG7ONPURZ3RZH67E2JQXQH OYO4
[4] https://lists.fedoraproject.org/archives/list/epel-devel@lis ts.fedoraproject.org/thread/B6 ASOXHXX4SLUDE3WOR2GFFRDEAJX436 /#A22LLWB5QM3PLEWN7PMFVRK3WCM3 RTIJ
[5] https://lists.fedoraproject.org/archives/list/epel-devel@lis ts.fedoraproject.org/thread/CB CLW2VUMZY2AXBBRMLPTKIWIYZRJMV2 /#FIGALSOZALNNOY42DHNSNPB5BSGW SXRA
[6] https://www.djangoproject.com/download/
[7] http://blog.beanbaginc.com/2015/09/11/work-toward-a-django- 1-8-port-for-review-board/
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
