If extending clang-format to get the JUCE style is too much work, would you consider modifying the style slightly to a style which is automatable?
5 Likes
I think clang-format is great, but at this point Iâm not sure thereâs a good way to go about âmodifying the style slightlyâ in the JUCE repo. We want everything to look consistent, which would mean reformatting everything in one go, which in turn would introduce a giant âreformat the worldâ commit. Such giant commits are not very git-blame friendlyâŠ
An alternative approach would be to only format lines which are touched in new commits, but then you end up with slightly differently-formatted blocks in close proximity, which is a bit jarring to read. It becomes unclear whether the different formatting is trying to communicate something, or whether itâs just noise.
Additionally, Iâm not sure clang-format is robust enough for our purposes. Different versions of clang-format sometimes produce different outputs, which is annoying if your package manager has one version and the build server runs a different version. In some cases, the formatting isnât stable, so repeatedly running clang-format on the same snippet will cause the output to switch back and forth between two different layouts (only seen this once or twice, maybe itâs fixed now).
If we were talking about some new repo with no history, Iâd definitely advocate for clang-format. For a large repo with a long history and which prides itself on consistency of style Iâm not sure itâs such a good idea.
2 Likes
Git 2.23 added support for this. See Ignoring bulk change commits with git blame - Moxio | Software voor informatiemanagement for more details.
5 Likes
I recommend DeepGit for exploring the source of blame. Since using it I stopped fearing such commits since. I also know thereâs some equivalent tools emacs plugins.
2 Likes
Seeing that so few people nail the style and thereâs no desire for a formatter, and the culture for PRs is to let them amass and stagnate for the most part, the public really canât do much more except spam the forums to always attempt putting an issue/bug/change on top of the devsâ plates - exactly like weâre doing today.
So this begs the question; CLA aside, what are the expectations for contributing to JUCE as an open-source repository?
I would like to suggest inviting collaborators help to do things like PR reviews, labeling, and maybe even creating Issues. There are different levels of collaborators, and Triage might do enough good to help out - seeing what weâre dealing with is a bandwidth issue.
This could help increase the culture in GitHub itself. Iâll volunteer.
4 Likes
if we had an army of reviewers whoâd spend their time reviewing PRs for free, to a standard that satisfies us then that would be a great situation.
As a newcomer, one of the things I appreciate most about JUCE is the attention to detail and quality. I do think these things can be extracted, codified and community enforced â but thatâs a lot of work, and like you mentioned, guaranteed to come with all sorts of additional overheads, like more community politics 
But engineering that is difficult, and our current system has been working really well for us so far. Maybe in the future things will evolve, who knows.
It seems hard to imagine that great PRs could pour in or that there could be an army of community reviewers as long as there are 2 development processes (private and public). The process the core devs contribute through will be optimized for by default, so it makes sense that it would feel higher quality and more productive.
I do wonder if itâs only when code review, CI, merging, etc all happens in public, that community members even have the chance to play on the same playing field, see great examples of whatâs mergeable and whatâs not, get the chance to level up, etc. Without those mechanisms in place, it follows that very few people would be able to deliver mergeable contributions. But also, the community is filled with C++ n00bs like me, so thereâs that too
However, the incentives of being a contributor and that feeling of having your code finally merged â weeee! These are important drivers for participation and learning. For example, I would like to add to the code documentation as I learn the framework, as there are some important contextual things missing I believe would help newcomers wrap their brains around best practices. But Iâm not sure if the contribution is appropriate (are there public guidelines on docs?) and was a bit confused (until this thread) whether community contributions are truly welcome. (Iâll open a new thread on docs)
3 Likes
Can you show some examples of a PR that âworksâ but isnât formatted correctly, thus causing the JUCE team to say ânah, that ainât it, chiefâ and then how you would reformat it to match the âJUCE styleâ?
What is the objective here?
Is it to get your contribution in and getting a pad on the back, or that the feature gets added or a bug fixed?
1 Like
I think the goal would be to have an SDK that doesnât require so many of us to maintain private forks
5 Likes
Why canât it be a mixture of both?
IME a PR usually begins with an issue or requirement that is not met, and in the ideal case ends up as a contribution and a feeling of achievement when it is finally merged in (whether directly or indirectly). Nothing wrong with that IMO.
Saying that, the JUCE team are generally responsive to request and bug reports and in my recent experience issues have been addressed fairly quickly, so I havenât had the need to fork for a good while now. Of course others may have a different experience.
1 Like
I just had the impression, that some were arguing here their C++ proficiency. I understand that, I also am sometimes needy for appreciation and someone says âwell doneâ. But hey, that should not be the motivation, and especially, if that is the reason for this thread, I might save me some time and mute it, because I donât care who wrote what, as long as I can still understand the code and it is up to scratch.
The motivation is purely getting bug fixes and new features added. I couldnât care less about a pat on the back. This is not about recognition. Itâs purely about not having to maintain our own fork, if it can be avoided.
7 Likes
Once a new process has been established, I would advise closing ALL current pull requests and issues that are outdated and/or irrelevant, to give newcomers not the impression that the repository is a graveyard.
I think, from a business point of view, we can all agree that a ânot perfect but workingâ pull request is better than a broken function or in our extreme case, a completely broken and unusable framework.
There is currently LOTS of very old code in JUCE that wouldnât stand up to Julesâ current standards. Weâre not deleting that either but keep it around to be improved at a later date. Adding a one-liner that helps hundreds but doesnât suit the maintainers needs can be declared deprecated later, should it really be necessary.
Again: the perfect is the enemy of the good.
2 Likes
I agree that there needs to be some sort of policy in place.
At the very least, some kind of official response on the JUCE teamâs opinion about the pull request, be it: âThis is a good idea, adding it to the todo listâ or âThis is not a good idea becauseâŠâ. At the very least, it would resolve every pull request that has been made and never acknowledged. If someone submits a Pull Request, they obviously found a solution to some problem they had with the framework that they think could help everyone else. Itâs frustrating to never hear back from the JUCE team about these types of suggestions and forces us to maintain our own fork.
3 Likes
Also, it may be useful to add some GitHub Actions to the JUCE repo that run all the units tests on several different platforms. That way anybody who has forked the repo will have all the tests running. And anybody who submits a pull request, you can quickly look to see all the tests are still running and passing and itâs compiling cleanly without warnings.
7 Likes
I am a perfectionist, and I think Jules and JUCE are the same.
And I donât think perfect is the enemy of the good, perfect is simply PERFECT!
4 Likes
The compromise is maybe for the Juce Team try to do better on this end from now on, responding to PR and end users to trust them because âthey knows betterâ for the sake of Juce smooth development.
Just some good will of both side will probably fix the wandering we have seen from time to time.
ReFX and SoundRadix has offered some good stuff and Iâm sure both side will agree that itâs for the best and will try this time to try to reach an happy end.
Letâs start with a clean slate. Either removing all issue/PR from github OR even better lost a couple of days to close those the best possible way. Iâm sure 80% of tickets are either already fixed or are end users errors.
IMHO the official way to report bug should be github or you guys should disable it (https://help.github.com/en/github/managing-your-work-on-github/disabling-issues)
6 Likes
You shouldnât take this proverb literally.
What @Toddler-Boy means is that in reality there are limited resources and one needs to decide how to get a good result with the resources they have. As such, achieving perfection is usually impossible anyway, meaning that disqualifying something just because it isnât perfect is a mistake, because regardless of what you do the result wouldnât be perfect. Instead you should do a pros and cons analysis vs the alternatives, from which âperfectionâ should be absent as a bar for comparison.
9 Likes
i donât get why you claim juce is open source and you put it up in github if you are not even caring on contributions and you let them die under the dust, rewrite them completely after few years without even signalling the contributors about why or when. you might not understand well open source as you think you do in the end.
6 Likes
Update: JUCE recently added a contribution instructions doc with a new policy of accepting PRs!
However since then they only merged a single PR.
I made a first PR but so far there was no response for more than two weeks. For comparison in the same time this PR has been sitting there I contributed PRs to pffft and Adept where the response time was same-dayâŠ
4 Likes