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 <step...@that.guru> 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/RKG34VEBSKXPKQLZB4H2AH7PPEA4RJV3 > /#7I6KXRTG7ONPURZ3RZH67E2JQXQHOYO4 > [4] https://lists.fedoraproject.org/archives/list/epel-devel@lis > ts.fedoraproject.org/thread/B6ASOXHXX4SLUDE3WOR2GFFRDEAJX436 > /#A22LLWB5QM3PLEWN7PMFVRK3WCM3RTIJ > [5] https://lists.fedoraproject.org/archives/list/epel-devel@lis > ts.fedoraproject.org/thread/CBCLW2VUMZY2AXBBRMLPTKIWIYZRJMV2 > /#FIGALSOZALNNOY42DHNSNPB5BSGWSXRA > [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-le...@lists.fedoraproject.org >
_______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org