On Sun, Aug 11, 2019 at 9:33 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 11. 08. 19 3:45, Kevin Kofler wrote: > > Nico Kadel-Garcia wrote: > >> Maintaining python 2 requires maintaining a*lot* of infrastructure. > > What kind of infrastructure do you need to maintain a package that is (will > > be) no longer updated upstream? This takes almost no work. The only thing to > > do is to backport some security fixes from Python 3, and occasionally to fix > > FTBFS bugs. > > > We are still planning to maintain the interpreter. As is documented in the > change. So can we please stop arguing about maintaining the interpreter over and > over? It is staying and our team will maintain it at least until RHEL 7 EOL, > possibly longer. So why do package maintainers have to do a whole lot of extra work to keep a package that has already been approved in the distro. There's a lot of work going into various stacks upstream for python3 work but in a lot of cases the time available is split and now we're asking the limited maintainers of packaged in Fedora to do more work unnecessarily to keep their packages around otherwise they're be aggressively killed off and they'll have to then do even more work to get them back.... or probably just go and use Ubuntu or CentOS or something else instead. This is frankly a ridiculous policy! > > Now if your concern is maintaining all the python2-* packages, then there > > ought to be some middle ground between maintaining all of them including > > ones that are not used by anything in Fedora anymore, and just dropping all > > of them (with or without the planned exception process, whose usefulness > > depends entirely on how willing FESCo will be to approve the requests). > > Maybe the set of python2-* modules in EL7 or EL8, with or without EPEL, > > minus the ones already retired from Fedora by now, would be a reasonable > > starting point? > > Yes the concern is about maintaining the python2-* packages. > > The difference between EL and Fedora is that package sin Fedora get recent > rebases / updates to newer version. You cannot just package them and call it > "done". And most of the upstreams are coming to a point where you cannot update > the Python 2 package because the new version doe snot support Python 2. > > That at the end means you need to go over nonobvious bumps to split the Python 2 > package out of the "common" package, in order to update the "common" (now Python > 3 only) package. And this problem spreads further with dependencies (even > transitive ones). I don't have the energy or time to split hundreds of packages > and maintain a separate stack of Python 2 packages. If somebody else has, go for it. > > The set of python2-* packages to remain is determined by the FESCo exceptions. > It is fairly easy really: We don't have the necessary information to understand > what Python packages are "important" and what are "cruft". Hence if your package > is important, you just need to explain that. Obviously, if you need to maintain > the package as a dependency, for another important package, the exception can be > requested at once, you don't need to request dozens of exception to keep e.g. > chromium around. > > > I also think that there ought to be more cooperation from the maintainers of > > individual python2-* modules. The approved Fedora 31 Change makes it way too > > easy for maintainers to just drop Python 2 support for no reason. > > When a packager doesn't want to maintain it, that's good enough reason. > > You have a right to orphan a package, why you should not have the right to > orphan a half of your package, when he other half works without it? > > > If > > upstream dropped Python 2 support from the current version and so an old > > version has to be packaged specifically for Python 2, that is one good > > reason to require somebody else to pick up maintenance, but as it stands, no > > such reason is required and Fedora maintainers can arbitrarily drop Python 2 > > support from their Python modules even if upstream still supports it. This > > is just pointless and unhelpful. > > Requiring others to maintain the packages your packages (or you) need just > because they maintained it until now is not very friendly. Of course, you can > ask nicely, but you cannot say this is their duty. > > > We can try to find people to pick up python2 and a bunch of python2-* > > modules, but expecting the python2 maintainer(s) to sign up for maintaining > > each and every python2-* module is unreasonable and unrealistic. Even if > > several of them will also be dead upstream (at least the version that works > > with Python 2) and thus require very little maintenance effort. > > Arguably, maintaining dead software requires more effort than maintaining live > one. But that kinda depends on the particular package. > > I don't need people to maintain **all** Python 2 packages, just mine. But > possibly other maintainers also don't want to maintain theirs. As the snowball > rolls, you need somebody to maintain **almost all** of them. > > >> To support multiple pythons, python26, python28 if it ever happens, > >> python36 python38 when it comes out. > > The whole reason for this discussion is that Python 2.8 will likely never > > happen. It definitely will not happen from Python upstream. Otherwise, there > > would not be all this talk about dropping Python 2 due to being unsupported > > upstream. > > Correct. We just want to signal that this is a compat package. We will most > likely still provide python2 (so users can discover it more easily). Why is the > package name so important to you? > > > I don't see much point in supporting Python 2.6, which is even more ancient > > than Python 2.7, and 2.7 is backwards-compatible with 2.6. > > The point is to support developers who use Fedora as they workstation but need > to support and test Python 2.6 (e.g. on EL6) in their code. Nevertheless, the > python26 package is now orphaned, because one of the dependencies is orphaned > (compat-openssl10). > > > And supporting multiple versions is not an argument for not having at least > > a python2 symlink and Provides: python2 in python27. > > Correct. Except both of those to happen. > > >> Simply replacing the "python2" line iwth "python27" is not a difficent > >> edit in most source code. > > But it is still a completely unnecessary edit. > > Yes. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
