On 8 November 2016 at 10:31, Brian Bouterse <bbouters@xxxxxxxxxx> wrote: > 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. > I believe the current problems are with the python supported. The path being discussed in the meetings was to move python34-django18 and similar versioning for EL6. This may mean problems for source code that is python2x based but unless someone is willing to help work on python27 rpms for EL6, any django after 1.4 is not supported ( I believe and could be wrong). > 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@xxxxxxxxxxxxxxxxxxxxxxx/thread/RKG34VEBSKXPKQLZB4H2AH7PPEA4RJV3/#7I6KXRTG7ONPURZ3RZH67E2JQXQHOYO4 >> [4] >> https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/B6ASOXHXX4SLUDE3WOR2GFFRDEAJX436/#A22LLWB5QM3PLEWN7PMFVRK3WCM3RTIJ >> [5] >> https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
