[lsdlsd88]

https://github.com/noisymime/speeduino/pulls

is there a plan / roadmap to go throught the pull requests? some have been sitting for months with not even a comment.

I assume there are reasons behind not having them accepted but I'm sure the contributors that put several hours into them would expect at least an answer / a discussion on what needs to be changed if anything.

a few of them have very useful features imho.

I hope someone can clarify what's the idea behind leaving them so long that they go out of "sync" with the current code, failing checks and possibly need rewriting etc.

[Eric H]

This is pretty funny.
I just wrote my own longer-winded version of this in the general section before seeing this.

I hope they don't feel like we're whinging.

[lsdlsd88]

lol that's a hell of a coincidence indeed. some stars probably aligned xD

no whining, I love the project and appreciate everything that's been done up to now, but there's always room for improvement.

this needs a better process to deal with the problem when users and contributions numbers skyrocket in the future..

[ric355]

I do agree that any pull request made ought to have some sort of response to it, even if it's "sorry but we can't include this". All it needs is a one-line acknowledgement or rejection. Josh is more responsive on slack if anyone makes a request and wants to know if it will be included. I suspect this is because you can tag him there and he gets a notification.

I suspect asking first, before doing any work you want pulled into master, is better.

There are some requests that clearly can't be integrated, and in my opinion these ought to be just closed to keep things tidy. Not everyone sees it the same way though, I know.

[noisymime]

OK, this will be a bit of a rant

Firstly, you're 100% right that these need a bit of a cleanup.

To give some background around why PRs are difficult, somewhere around 80% of the regressions (ie existing things breaking) in the codebase come from pull requests. This is usually as a result of people writing a new feature, testing that it works and then submitting the PR without testing other areas that they have impacted.
It's completely understandable as having an understanding of the entire codebase is difficult and people tend to just focus on the thing that they're working on. It's the primary reason why I'm continually trying to grow the coverage of the unit testing.

The result of this is that I'm more reluctant to accept a PR until I've done testing with it, which can easily take just as long as the writing of the original code. This is the main reason why things tend to sit, waiting until I get a chance to test them.

Compounding the above is that many of the pull requests are a shotgun type thing. Rather than adding a single function or purpose (ie are 'atomic' in nature) they are a mashup of someone's fork where they've changed a whole bunch of things and the PR has changes across 10+ files and are a nightmare to test. Again, I fully understand how this happens (and SOMETIMES big PRs are unavoidable), but it makes it very difficult to review and have any confidence in.

Finally there's the PRs that are, for lack of a better term, a bit crap. It might be that their code is confusing/illegible/downright nasty, or that they're using great gobs of memory unnecessarily or introducing big slowdowns without realising.

SO with all of that said, the best advise I can give when submitting a PR is to jump on to Slack and raise it for discussion. Not only will that bring it to my attention more than just the GH notification email, but we can discuss in real time (or near) any concerns I might have with it. It's not perfect, and unless I quit my job and work on this full time it never will be, but it should help in getting things merged.

[Eric H]

Thanks for the response.
The only thing I take issue with is Slack . I cannot stand those "We're taking over all forms of communication" apps.
I'm very particular with my working setup, I've spent decades getting it just right, then these horribly designed UI/workflow nightmares show up and want to screw it all up.

The feature I really want pulled is #402, Incorporate AFR. https://github.com/noisymime/speeduino/pull/402
We're going to the dyno soon to tune the race car and I'll probably pull that change into my repo because I can't imagine that functionality is not already part of the standard default setup.