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

Reply via email to