Hi John and Christian, On 03/27/2015 09:46 AM, John Paulett wrote: > James, thanks for putting this together. > > Christian, I am in a similar position, supporting 2.6 for the next 6-12 > months. I had planned to keep a personal fork of Django 1.6, > backporting security patches as needed, but I would be happy to > contribute to a common effort in this regard. > > As mentioned by others, keeping the effort unofficial may be ideal. A > planed end-of-life of this secondary support may also be helpful to > still convince people to migrate forward. > > For a personal fork this wasn't going to be needed, but I wonder how > package distribution should occur. I doubt that publishing unofficial > distributable under Django's PyPI project is advisable.
I agree. I'll outline my idea of how this could work; consider it an alternative proposal (or proposed revision of) James' DEP. (I don't think a DEP is needed for this, but if other core team members feel that it is, I am willing to work this up into DEP format). - The community support work happens in a third-party GitHub fork. If you and Christian want to work together on it for 1.6, one of you can create a repo and grant the other commit access. (This is of course something that you have every right to do regardless of what the core team thinks of it.) - One of you applies for security pre-notifications (under the "distributor of Django" category -- essentially you are applying to be equivalent to e.g. a Debian or Fedora packager of Django, who could/might provide the same kind of extended support you are planning to.) - I think from the core team's perspective, the ideal situation would be that these releases not be on PyPI at all, but that your users would download them directly from the "releases" section of your github repo, or perhaps pip-install them from a PyPI-compatible index that you publish somewhere on static file hosting. If this is acceptable, it would allow you to use PEP 440 "local version identifiers" [1] in your versions, which I think is the most semantically correct for this situation. So your versions would look something like "1.6.11+extended-1" (choice of actual local-version label up to you). If not-on-PyPI is a total dealbreaker for your users, it might be an option to release under a different PyPI project name, such as "Django-16-Community-Support" or similar, but this is less than ideal. For one, it would require the actual package to have a name other than "Django", and it would require the use of something like "1.6.11.post1" instead of the local version identifier, since PyPI does not accept local version identifiers. - A preamble should be added to the README of the project on GitHub to indicate that this is unofficial community-based extended support for Django 1.6, intended only for users of distributions who are providing extended security support for Python 2.6, and should only be used under those circumstances. It should clearly warn that Python 2.6 is EOL and should not be used unless your distro is continuing to support it. It should also clearly indicate that the Django core team is not providing this extended support, and point to the correct GitHub repo issues tracker for raising any issues with it. The same information should be provided in public announcements about the extended support, web pages about it, etc. How does this sound to you, Christian and John? How does it sound to other members of the core team? Any objections to any of what I proposed? Thanks, Carl [1] https://www.python.org/dev/peps/pep-0440/#local-version-identifiers -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/55158459.9040304%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
