[nubinetwork]

While I never submitted a patch personally, I had once conferred with some of the input devs to add a trackpad to the synaptics driver... they were queueing up an update to add other trackpads, and they said they would add mine... 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added...

On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week.

At the end of the day, people are weird sometimes. I wish all the best for marcan.

[ogoffart]

I tried once to contribute a fix to be able to use the track-pad on my laptop many years ago. But it was not accepted as the maintainer claimed it was an problem in userspace that did not process out of order events correctly. Despite none of the other drivers sent the events out of order. I had no intention to fix the problem on X11 (the only userspace for this at the time), so I used the patched kernel driver locally until I stopped using that laptop. https://bugzilla.kernel.org/show_bug.cgi?id=43591 https://lore.kernel.org/all/1340829375-4995-1-git-send-email...

[bsimpson]

FWIW, I have submitted a couple small patches to get the display and gamepad for my Lenovo Legion Go recognized correctly - probably similar levels of complexity to your change. One was to input and one was to display quirks.

They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.

[Ecco]

Thanks!

[naasking]

> 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added.

I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.

[harvey9]

this seems very inefficient and the opposite of what I assumed. repeated requests take up time on both sides and are not a very good measure of how important something is.

[nicce]

This is how the most of the open-source development works. There are many projects with thousands of issues and PRs. Those that will get most attention, typically gets prioritized.

[stusmall]

This is even how closed source development works. If you throw issues in a backlog and never follow up to advocate for it then it will never get done.

[dncornholio]

it's not perfect but it works.

[neoromantique]

well, apparently it doesn't.

[naasking]

Well, apparently nobody even noticed for 5 years, so that's 5 years that nobody had to even think about that code.

[amatecha]

Nah, people noticed, and then they thought "Linux always has these kind of issues, I'm going back to [whatever other OS]" because 99.9% of users will never even TRY to report a bug.

[samus]

People just think "that's Linux, it's buggy and we have to live with it"

[mid-kid]

why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?

[naasking]

Requiring people to advocate for their changes is not ill-intent. It handles all cases such as forgetting/missing a patch, and disagreement whether something is needed. The point is there's no system in place to track which patches "should ideally be included but weren't for some reason", it's up for the people who need them to push for them.

[adastra22]

Quite the opposite. If you “pester” for something, they’ll explicitly reject it.

[naasking]

I didn't say pester, I said advocate for it.

[adastra22]

It's the same thing.

[arp242]

People forget things etc.

Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"

[lazyasciiart]

Then you get stories like Greg in the linked mail thread, who emailed to check after not hearing anything and got told that now he'd been annoying and it would never be done.

[account42]

A story about a 17000 line patch with seemingly no discussion before dumping it on the kernel maintainers. Understandable that noone felt like reviewing it.

[samus]

Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.

[BlueTemplar]

But Github, being a platform, is a nonstarter.

Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?

[samus]

They "just" need to settle on a platform. GitLab sounds good and is used by a lot of important Open Source projects.

[BlueTemplar]

Did you miss the part where being a platform was most of the issue ?

I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...

[arp242]

> exactly the sort of problem that doesn't happen with a Github issue/PR

What? PRs or issues being forgotten happens all the time, especially for large projects.

[samus]

It would still be easier to track the progress (or lack thereof) with a proper ticketing system.

[account42]

Yeah instead the issue will be auto-closed by some bot. Yay.