+1

+1

I would prefer to get an overview about how which extensions are python3 compatible, which need to be ported and how complex it is to port them.

Also I am not sure if the test instructions are very helpful:
Launch the Nautilus file manager and verify that any functionality provided by Python-based extensions is still available.

I would not how which functionality is provided by extensions and would need to be tested.

Also the user experience contradicts the original intent of porting all extensions to Python3:

As long as Python 3 compatibility is verified for all Nautilus Python extensions, users will see no impact from this change. If any extensions are not compatible with Python 3 and must be removed, users may notice loss of certain functionality from Nautilus.

It allows for removing extensions instead of porting them but the contingency plan says to return to python2 if there are problems:
Continue shipping builds of nautilus-python based on Python 2.

It would be great to clarify this in the change proposal.

+1
Well, there aren't really many of those extensions with still active upstream development. E.g. Nitroshare and RabbitVCS developments at upstream seem to fall asleep. No idea about the other projects.

I support @till's request for additional details, more information is always good. But it seems that those details are simply not available yet — an that going through the change process will be equivalent to finding out — and I also don't think they could change my vote in this matter. The change explicitly assumes that some extensions will not be ported to Python3 and will have to be dropped. This will be disappointing to users, but keeping a Python2-based implementation is not an viable option anymore, so I prefer to treat the change as unavoidable, and start the implementation early and try to make the best of it.

@kalev @ferdnyc
FESCo voted to wait on approving this change proposal until the issues in comment 545919 are addressed.

@till

Also the user experience contradicts the original intent of porting all extensions to Python3

That was poor wording on my part, I guess. My apologies for that.

The intent of this change isn't to port all extensions to Python 3, but rather to switch the backend interpreter for those extensions to /bin/python3 — to move them into a new execution environment without changes to the extensions. Which, as @zbyszek says, will unavoidably cause any extensions which are not Python 3 compatible to fail.

Porting those extensions to Python 3 would be a solution to restoring their functionality following this change, but it wasn't intended to be stated as part of this change itself.

(Note that this applies not only to extensions we package and ship, but potentially also to extensions that the user has installed on their own. We couldn't possibly promise that all extensions in use will continue to work with the backend swapped out.)

One issue with making this switch is that, unlike Python scripts which can use their shebang lines to target a specific interpreter, the interpreter selection for nautilus-python is both invisible to, and beyond the control of, both the extension code and the user. (Hence this notification, to raise visibility. Or that was my initial thinking in suggesting it, anyway.)

We will discuss this in the FESCo meeting on Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.