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@lists.fedoraproject... [4] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... [5] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... [6] https://www.djangoproject.com/download/ [7] http://blog.beanbaginc.com/2015/09/11/work-toward-a-django-1-8-port-for-revi...
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@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-leave@lists.fedoraproject.org
On 8 November 2016 at 10:31, Brian Bouterse bbouters@redhat.com 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@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@lists.fedoraproject... [4] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... [5] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... [6] https://www.djangoproject.com/download/ [7] http://blog.beanbaginc.com/2015/09/11/work-toward-a-django-1-8-port-for-revi... _______________________________________________ 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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org
On 08/11/16 16:31, Brian Bouterse 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 I can shed a light here: - Django14 followed the old Django naming scheme in Fedora. Django was renamed to python-django there. - Django-1.4 was the old long term supported version and works with pythons up to python 2.6 - Django14 should be retired IMO - Django-1.8 (current long term supported version) requires python 2.7. That means, we can not have a recent Django in EPEL6 with system python. - The main reason not updating to Django-1.8 in EPEL7 is reviewboard. (I don't know the state of askbot currently, Fedora has ask.fedoraproject.org). - Maintaining a django version, which was retired upstream becomes more and more a pain, esp. if it's not part of your job to keep it alive.
Matthias
On 2016-11-08 18:06, Matthias Runge wrote:
On 08/11/16 16:31, Brian Bouterse 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 I can shed a light here:
- Django14 followed the old Django naming scheme in Fedora. Django was
renamed to python-django there.
- Django-1.4 was the old long term supported version and works with
pythons up to python 2.6
- Django14 should be retired IMO
I agree. It's rather decrepit at this point.
- Django-1.8 (current long term supported version) requires python 2.7.
That means, we can not have a recent Django in EPEL6 with system python.
Per the docs [1]
Django 1.8 requires Python 2.7, 3.2, 3.3, 3.4, or 3.5
EPEL 7 comes with Python 3.4, correct? If so, 'python3-django' seems like a thing that can be done.
- The main reason not updating to Django-1.8 in EPEL7 is reviewboard.
(I don't know the state of askbot currently, Fedora has ask.fedoraproject.org).
Yes, so Django 1.6 [2] is the one currently provided on EPEL 7. However, that's Python 2.7. Would it be possible to add a Python 3 version using Django 1.8? Alternatively (and this might be heresy), what's the possibility of bundling that version of Django in the Reviewboard package only, or renaming it to something like 'python-django-rb', to free up the 'python-django' namespace for Django 1.8?
- Maintaining a django version, which was retired upstream becomes more
and more a pain, esp. if it's not part of your job to keep it alive.
Yes, that's understandable. However, the Django project does seem to have a handle on this now with their LTS releases. Supporting only these LTS versions seems like a good move. Once Django 1.11 is released, we can wait a month or two for packages to upgrade their dependencies before switching to that, and so on.
Stephen
[1] https://docs.djangoproject.com/en/1.10/releases/1.8/ [2] https://dl.fedoraproject.org/pub/epel/7/x86_64/p/
On Wed, 09 Nov 2016 10:13:48 +0000 Stephen Finucane stephen@that.guru wrote: ..snip...
Yes, so Django 1.6 [2] is the one currently provided on EPEL 7. However, that's Python 2.7. Would it be possible to add a Python 3 version using Django 1.8? Alternatively (and this might be heresy), what's the possibility of bundling that version of Django in the Reviewboard package only, or renaming it to something like 'python-django-rb', to free up the 'python-django' namespace for Django 1.8?
I think we should have 1.8 in the name... if/when it drops out of support and we want to move to 1.10, we can just retire 1.8 and move to 1.10 without having a specific flag day that breaks everyone using 1.8.
kevin
On 11/09/2016 03:21 PM, Kevin Fenzi wrote:
On Wed, 09 Nov 2016 10:13:48 +0000 Stephen Finucane stephen@that.guru wrote: ..snip...
Yes, so Django 1.6 [2] is the one currently provided on EPEL 7. However, that's Python 2.7. Would it be possible to add a Python 3 version using Django 1.8? Alternatively (and this might be heresy), what's the possibility of bundling that version of Django in the Reviewboard package only, or renaming it to something like 'python-django-rb', to free up the 'python-django' namespace for Django 1.8?
I think we should have 1.8 in the name... if/when it drops out of support and we want to move to 1.10, we can just retire 1.8 and move to 1.10 without having a specific flag day that breaks everyone using 1.8.
+1
On 11/09/2016 03:13 AM, Stephen Finucane wrote:
On 2016-11-08 18:06, Matthias Runge wrote:
On 08/11/16 16:31, Brian Bouterse 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 I can shed a light here:
- Django14 followed the old Django naming scheme in Fedora. Django was
renamed to python-django there.
- Django-1.4 was the old long term supported version and works with
pythons up to python 2.6
- Django14 should be retired IMO
I agree. It's rather decrepit at this point.
- Django-1.8 (current long term supported version) requires python 2.7.
That means, we can not have a recent Django in EPEL6 with system python.
Per the docs [1]
Django 1.8 requires Python 2.7, 3.2, 3.3, 3.4, or 3.5
EPEL 7 comes with Python 3.4, correct? If so, 'python3-django' seems like a thing that can be done.
We are building up a Python 3.4 stack on EPEL 6 & 7, so that is an option.
I'm also poking at Python 2.7 on EPEL6 here: https://copr.fedorainfracloud.org/coprs/g/python/python2.7_epel6/packages/
Anyone in the python sig group and build there and play along/help out.
On Tue, 8 Nov 2016 19:06:20 +0100 Matthias Runge mrunge@matthias-runge.de wrote:
On 08/11/16 16:31, Brian Bouterse 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 I can shed a light here:
- Django14 followed the old Django naming scheme in Fedora. Django was
renamed to python-django there.
- Django-1.4 was the old long term supported version and works with
pythons up to python 2.6
- Django14 should be retired IMO
Agreed.
- Django-1.8 (current long term supported version) requires python
2.7. That means, we can not have a recent Django in EPEL6 with system python.
- The main reason not updating to Django-1.8 in EPEL7 is reviewboard.
(I don't know the state of askbot currently, Fedora has ask.fedoraproject.org).
ask is currently rhel6 and using Django14. We should move it to rhel7 and django-1.8. ;)
- Maintaining a django version, which was retired upstream becomes
more and more a pain, esp. if it's not part of your job to keep it alive.
Yeah.
We also need Django 1.8 in epel7 for mailman3/hyperkitty.
It's using python34 for that. I don't know if very many applications that support django 1.8 also support python3 or not.
kevin
epel-devel@lists.fedoraproject.org
-
Brian Bouterse -
Kevin Fenzi -
Matthias Runge -
Orion Poplawski -
Stephen Finucane -
Stephen John Smoogen