On 8/11/19 2:28 PM, Kevin Kofler wrote:
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)?
Python 2 will not get the attention, fixes, and security updates that
people have been used to in the past decade. That's a big deal, and
unfortunately we know no good way to properly communicate this to all
the affected packagers.
We hope the bureaucracy works for the hundreds of packages with inactive
maintainers; the flip side is that the active maintainers do have to do
some more work, even if it's just filing a ticket and switching a
BuildRequires. Sorry for that.
As for the Python 3 migration plan: we can agree to maintain Python 2
for you to depend on, if there's a feasible plan of moving away from
Python 2. If there's no plan, you'll just run into trouble in a few more
years. If you consider your package important, we really want to know
about the situation.
The Python 3 migration plan is not a requirement, but a very common and
useful piece of information that we want to hear about. Every package is
different; we can't know where each upstream does their planning. As a
packager, you know best where to ask for this info, so we ask you to
find it and paste the link in a Fedora place -- Bugzilla or a FESCo ticket.
If there's another plan instead of a "Python 3 porting plan" (like port
to Rust instead, or to Tauthon, or maintain Python 2 forever), we'd also
like to know about it.
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.
The policy is for those *and their dependencies*.
See, I have a "package where upstream is in the process of dropping
Python 2 support". It's called "python2".
I could just drop it and call it a day, but since people still want it,
I'll maintain it. But only for those who care and who understand the
situation; not for the hundreds of inactive maintainers.
(To be clear: making it possible and straightforward to build Fedora
RPMs with python3 *is* more work than just maintaining the interpreter
for users.)
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.
Sure, but this "python2" one does need ongoing maintenance.
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)?
The maintainer needs to say "yes, this is still needed" for all the
(transitive) dependencies as well. There's usually a non-trivial amount
of these.
If you maintain one of the packages that just need the interpreter
itself, then yes, I can see how opening a FESCo ticket is unneeded
bureaucracy. Sorry for that, but please understand that this is not a
common case.
If you maintain *many* packages like that, let us know and we'll do
something to treat them as a batch.
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.
I don't think we really had a compatibility package with that many
dependents, unfortunately.
As for the precedent, yes, I sure hope we're not setting one.
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.
It always takes extra effort to maintain the Python 2 module's
dependencies. It might not be *your* effort, but it is effort.
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.
You are quite lucky, it seems. Congratulations!
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 agree with that...
I don't see why a more aggressive removal process is needed here.
...but not with this. The graph of dependencies is too big and tangled,
and it changes too much over time (if you don't remove leaves, they stop
being leaves). And since many of the packagers involved aren't
responsive, we kind of need them to explicitly say "yes, this is
important and we should keep all the dependencies" rather wait for "no,
drop this".
Hence the whole complicated process for figuring out who should maintain
python2 modules.
For example, at my last count, Chromium had 57 Python2 packages as
transitive (build)dependencies, many of which are probably not best
maintained by Chromium maintainers. Calibre had 104. And those are
programs we know people care about; there are hundreds where we have no
idea how important they are to their packagers or users.
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.
_______________________________________________
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
