If it couldn't be merged as-is that is completely understandable, but why close it then? Why not say "can you tame this back?" instead the response was "this will break things and maybe you added malware".

The project maintainer may not want to keep PRs open that are not acceptable as is.

There is zero functional difference between holding the PR open indefinitely (and many times follow-up just never happens) and closing the PR until changes are made and where a new PR is then opened.

> There is zero functional difference

This isn't true though. There's may be no functional difference for the receiver/merger/maintainer but there's a large difference for the submitter - this kind of approach can often be the demotivational difference between finishing and abandoning branch work.

Sure, 95% of such PRs might never go anywhere, but with the contribution pool being that small, is there a strong reason to shrink it further?

I get that maintainers have a lot on their shoulders & expecting them to be perfect receivers of outside contrib is expecting a lot, but it's also why there's so much on their shoulders.

First things first: I never implied (or wanted to imply) that you were introducing malware in that patchset, just that you could introduce it and I wouldn't be able to find that in a PR so big. Sorry if that came out wrong.

Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio.

And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline.

For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)

I appreciate the reply, happy to hear mainline efforts progressing too. :)

I feel you should get more encouragement here. Thanks for your great work. You did a lot. Yes, the whole state of mobile is frustrating, but here is someone improving things. If our governments weren't the corrupt authoritarian shitheads they are, these kinds of trojan horses should be illegal.