On 03/23/18 18:41, Toshio Kuratomi wrote:
On Fri, Mar 23, 2018, 9:50 AM Petr Viktorin <pvikt...@redhat.com <mailto:pvikt...@redhat.com>> wrote:On 03/23/18 16:43, Toshio Kuratomi wrote: > > > On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin <pvikt...@redhat.com <mailto:pvikt...@redhat.com> > <mailto:pvikt...@redhat.com <mailto:pvikt...@redhat.com>>> wrote: > > On 03/23/18 15:15, Toshio Kuratomi wrote: > > Something that occurred to me last night, rather than a > conditional on > > Fedora version, is there a macro that we could provide to mean > python2 > > is available in this Fedora version? That way packagers wanting to > > support their packages on the versions of python that the > platform ships > > can conditionalize on that imstead of fedora release (which is > variable > > depending on whether someone picked up and drops support for the > > orphaned python 2 package) > > I'm not sure how useful that would be. Wouldn't we want that not only > for the python2 package, but also for other dependencies? > Django's py2 subpackage is dropped already. Should there have been a > macro advertising that? > > > Also, we want to *avoid* breaking everything at once. Providing a flag > that gets flipped at one moment wouldn't solve much. > _______________________________________________ > > Depends on what the groups of packagers want... A macro for Django would > definitely have given an easy option for packagers to take advantage > of. Otoh, how far in advance was the Django removal telegraphed and how > much chance was there that a new maintainer would pick it up? Um, Django set its current policy back in 2015 (see https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ <https://www.djangoproject.com/weblog/2015/jun/25/roadmap/>): We will support a Python version up to and including the first Django LTS release whose security support ends after security support for that version of Python ends. For example, Python 3.3 security support ends September 2017 and Django 1.8 LTS security support ends April 2018. Therefore Django 1.8 is the last version to support Python 3.3. Fedora follows upstream, packaging the newest version (which is now incompatible with py2). And the django-1.11 LTS release is packaged in Fedora for Python 2, as a courtesy to projects that need a bit more time. (Of course, instead of maintaining the LTS I could just say to kobo or pulp that they're out of time and on their own. That's not what I want. But I also don't want to maintain the LTS forever.) > It doesn't do as much good for a package that is going to definitely drop > support in the very next release as it does for a package that is going > to drop support two releases from now, maybe, unless someone decides to > pick it up, even at the last minute, perhaps only after they realize > it's been removed from the repository.... Python 2 is security-critical software with thousands of dependencies. If someone is not following along, and wakes up at the last minute to maintain it, then I *still* want to remove as many of those dependencies as possible -- both to make their job easier, and because I wouldn't trust them to do a very good job. > Why do we want to avoid *breaking* everything at once? I can see us > wanting to keep things *working* as long as it makes sense to the set of > packagers that care (which I think adding the macro would aid in) but it > doesn't feel like actively designing things to break a little at a time > is helpful to anyone. I *don't* want to support Python 2. I *do* want to give packagers a more-than-fair change to switch to py3-only, if they haven't done so yet. And possibly help with concrete problems they'll have when switching. But I can't help with those problems if they appear all at once. Python2 is used in many parts of Fedora (and beyond) that we don't *see* until we start removing things -- build tools, infrastructure, who knows what else. Removing these things lets us react to problems as they come up. If everyone starts dropping the py2 subpackages *now*, starting from the leaves, then by circa 2020 we can orphan Python 2 with clean conscience. > Users can't count on things working from release > to release and packagers have to do more work to keep the pieces they > care about working. Sorry, but with that mindset I could just orphan Python 2 now. That would be irresponsible.You're only reading half of what I wrote above. I was saying that it doesn't help either those who want to keep it or those who want to drop it. Inconsistency hurts both of those sets of people. Dropping now would help one for the detriment of the other set. Dropping at once in the future would be a compromise to those two sets.
Ah, but I don't see those two sets of people -- those who *want to* drop py2 versus those who *don't want to*. If *anyone* would be in the latter group -- they don't want to drop py2, and so they are willing to put in the work to support it -- then all this is moot: the current py2 maintainers will celebrate, give python2 to that someone else, and go work on more interesting things.
Instead, there are people who *can* drop py2 from their packages and those who *can't*. If you (or your upstream) are working to drop Python 2 and need three more years for it, that's sad, but OK! you still have to do the work (because we, sadly, can't help everyone), but we don't want to leave you hanging if you're trying. But if you're *asking* when to remove Python 2 support, the answer is clear. No need for a macro to give the signal. Drop py2 now, or if you maintain a single spec for all Fedoras, conditionalize on Fedora > 28.
If you want to maintain py2 subpackages for "as long as possible", there will come a point in time when you will need to decide either to drop py2, or take over maintenance of Python 2 itself. As above, we celebrate, and leave you to it.
That's not a threat though -- we'd much rather communicate, advise and help.
With your reply, I see that you think that forcing breakage will let you help those who want to drop support now. That's fine. It wasn't clear in your earlier mail that you were ponying up resource to help people get over any python2-dropping hurdles and that you fear they won't come to you with those problems until you force the issue on them.
Sorry! Too many nuances to this, I'm afraid. It's hard to express everything, especially in a way to make those who just skim the text to get the right idea.
_______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
