[JoshTriplett]

GNOME (and many others) have spent years telling anyone who has issues with Wayland that lead them to run an X session to report bugs, and has put a lot of effort into fixing those bugs. This seems like a reasonable next step.

> This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland.

Or, more reasonably, to maintain less code for alternate paths in favor of fixing the issues that lead people to use those alternate paths.

Wayland has bugs. X has bugs. Fixes to one largely don't help users of the other. Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place. A project taking a step like this allows it to consolidate those efforts.

[koito17]

Yup. I think consumers of FOSS rarely understand the amount of effort that goes into maintaining code, whether that is keeping the test infrastructure up to date, fixing bugs, or adding new features.

In many cases, a large codebase like GNOME will undoubtedly have huge swaths of unmaintained code that doesn't have good test coverage and corresponds to rarely used features of the software. It also becomes a frustrating game of whack-a-mole when attempting to fix bugs in software with inadequate test coverage.

Another infrequently acknowledged point: writing tests isn't simple, it requires you to have thorough understanding of all the moving parts involved. If the current maintainers do not understand the architecture in some obscure corner of the software, then there is a significant upfront cost to expanding existing tests around that code -- time that can be spent improving frequently used parts of the software.

When nobody steps up for maintenance despite welcoming patches and calling for new maintainers, there is simply no reasonable option besides "remove this unmaintained source of bugs that none of the maintainers know how to properly test"

[JoshTriplett]

Exactly. Given the nature of Open Source, anyone is free to fork something and say "I'm going to keep maintaining the old thing forever". But that's often not feasible solely with the handful of people and energy of those people interested in a given older technology, especially in a world in which people expect pieces of the ecosystem to cooperate and interoperate with each other.

So, instead, the standard tactics are to 1) push people and projects to maintain the old thing for them as long as possible, 2) treat any new technology that doesn't give you free support as a threat, and respond to it with fear, disparaging and attacking the people and projects who are no longer willing to maintain the old thing forever, trying to rally others to pressure them, and 3) disparage and attack technologies that require integration/cooperation between projects, because it raises the bar for the amount of maintenance effort expected.

New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.

[jeroenhd]

> New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.

Not just new projects. Existing projects can do with a clearer roadmap in my opinion. "Gnome 48 will drop X11" is easier to communicate than a merge request titled "session: Remove x11 session targets".

[bandrami]

Except for the guy who tried to do that with Python2 and the Python Foundation threatened legal action

[jeroenhd]

When did they do that? All I can find is the Python foundation protecting their trademark. Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. Surely everyone in open source learned from the Iceweasel debacle.

Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7, though I don't see many contributors to that fork.

[bandrami]

> without any affiliation to the Python Foundation

Sorry, no dice. The Python team said for years as the 2 to 3 rollout grew increasingly catastrophic "If you wan't to keep Python 2 all you have to do is maintain it" and then threatened to sue the guy who called their bluff. It was a real low point in free software.

[jeroenhd]

This guy wasn't maintaining Python, he as creating a new version incompatible with either Python 2.7 or Python 3.

Red Hat and other large companies have maintained Python for years after 2.7 died (EOL date was January 1st, 2020). IBM/Red Hat offer Python 2.7 including security fixes and bug fixes until 2024 (https://access.redhat.com/solutions/4455511).

Had he just provided patches to Python 2.7, nobody would've batted an eye. Instead, they created an alternative language that was completely different (https://web.archive.org/web/20161210161837/https://www.nafta...).

Founders and core devs indicated that the name was the only problem (https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) and that even things like the header file names could continue to be named Python because of API compatibility.

You can fork any open source project you like, but you still need to stick follow trademark law. You can't just release Linux 2.7 because you disagree with breaking changes in 3.0 either, but you're free to take the Linux code and release Twonux if you really care.

[codetrotter]

> Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. […]

> Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7

I was curious and did a search for Python 2.8 and found:

- https://news.ycombinator.com/item?id=13144713

- https://news.ycombinator.com/item?id=13159144

Clicking on the GitHub repo it seems that in fact the project making unauthorised use of the name “Python 2.8” was the one that ended up changing its name to Tauthon. Neat!

[bandrami]

Also "without any affiliation" is a stretch. He picked up a codebase they abandoned and they got pissy because he kept its name. It was really not a good look.

[adastra22]

This is more than a little ironic since Python stole its name from a British comedy show.

[jeroenhd]

Monty Python didn't register Python as a name for computer software was far as I know. Nobody was going to confuse the two.

Releasing Python 2.8 would definitely confuse people.

[aragilar]

My impression though is that for enough people, the wayland code doesn't exist (see this comment from a GIMP dev on the aforementioned MRs for example: https://gitlab.gnome.org/GNOME/gnome-session/-/merge_request...). It's one thing to choose between different buggy behaviour, it's another when the new way does not allow you to do your job.

[BeetleB]

> Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place.

What fraction is that? I thought X still had the larger user share.

[BeetleB]

To answer my own question: 70% of Linux gamers use X. Definitely not a small fraction.

https://www.gamingonlinux.com/users/statistics/

[M95D]

They don't care about user shares. Why would they?

[JohnFen]

It's not just about bugs. It's also about functionality X has that Wayland won't.

[justinclift]

If the article is still correct, and Wayland doesn't work with the Nvidia binary drivers then that's a hard blocker for at least myself. :/

That being said, I'm still using Ubuntu 20.04 LTS on my desktop as I prefer stable systems. That way I can put time into the things I'm interested in more. :)

So, as long as it all works nicely by the time I need to change from Ubuntu 20.04, then I likely won't particularly care if it's wayland or X underneath.

[abenga]

It works perfectly fine on Debian testing (in fact the X session developed show-stopper bugs that forced me to use Wayland), so it should be on Ubuntu soon.

[justinclift]

Cool, thanks. :)