Re: Why retire Python 2 packages and games that still work to end user ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Miro Hrončok wrote:
> 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.

Then why do you require all this FESCo exception bureaucracy, including a 
Python 3 migration plan, for every single package requiring Python 2, even 
if it is only the interpreter (and the shipped standard library)?

> 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.

And that is a perfectly valid reason to orphan the Python 2 parts. My issue 
with the policy you proposed and FESCo approved for F31 is that it does not 
require this to be the case, but allows maintainers to drop the Python 2 
subpackage just because they don't like Python 2 (or simply want to avoid 
going through the bureaucracy you're requiring for F32), which is a quite 
antisocial thing to do.

If the partial orphaning policy were limited to packages where upstream 
dropped or is in the process of dropping Python 2 support, I would not 
object.

That said, those are also the cases where the split out python2-* package 
WOULD in fact be "done" and never require getting updated to a newer 
version, unless upstream maintains some legacy/LTS branch. So the situation 
for whomever ends up stuck maintaining the python2-* package would not be 
that different from the RHEL situation.

> 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.

But why does this have to go through FESCo and a formal approval process? 
Why is it not sufficient that the maintainer says "yes, this is still 
needed"? If a maintainer wants to keep the package, this clearly means it is 
important to SOMEBODY, so why do we need an approval by committee to confirm 
this (or worse, veto this against the wishes of the maintainer)?

We do not normally require this level of bureaucracy for things depending on 
a compatibility package, and I think this is a very dangerous precedent to 
set.

> 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?

When it takes no extra effort to maintain the Python 2 module because the 
current upstream still supports it just fine, what is the rationale for 
dropping it, other than "I don't like Python 2 anymore"? As I wrote above, 
if upstream stops supporting Python 2, that is a valid reason. If nothing in 
Fedora (nor in popular third-party repositories) requires the Python 2 parts 
anymore, that is a reason too.

> 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.

All I am asking for is to not actively drop python2-* subpackages without a 
good reason to do so. (It actually requires more effort to go and delete the 
specfile portions than to just keep them. ;-) )

> Arguably, maintaining dead software requires more effort than maintaining
> live one. But that kinda depends on the particular package.

My experience maintaining the Qt 3 stack is quite the opposite. Those 
packages require a lot less effort to keep going than, say, qt5-qtwebengine.

> 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.

My idea is that people depending on specific python2-* modules should 
maintain them, as usual when a library gets orphaned. But we cannot expect 
one person to maintain all of them. Neither you, nor me, nor anybody else.

What I want to see is a small group of python2 maintainers keeping the 
interpreter going, and then individual packagers of dependent packages 
(reverse dependencies) maintaining the individual python2-* modules they 
need for their packages. If nobody can be found for a specific module, then 
that module should get retired by the normal retirement process for orphaned 
packages. I don't see why a more aggressive removal process is needed here.

>> 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.

OK.

        Kevin Kofler
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux