I’d separate features and bugs. As even bugfixes by the JUCE sometimes break/regress.
The real question is what’s the balance between master/main branch and the develop one. Is just setting main to develop and calling it a release is good enough? Not sure what’s the answer and I guess it’s being discussed by the juce team.
One technical note on juce development is,
Commits in general aren’t atomic and their commit message might not include critical changes. Both of those makes bisecting sometimes less trivial and I assume also make cherry-picking (instead of moving entire master to the develop position) harder.
Thanks for sharing, could you possibly elaborate a little please? we tend to aim where possible to squash our work into the fewest sensible commits we can, aiming for commits where each one is buildable. Obviously if reports come back on the forum for the feature/bugfix we will need additional commits and we tend to avoid any squashing/rebasing/changing history on the public branches or it can cause havoc for users.
This one was especially horrible for a commit that was supposed to fix new diagnostic messages from clang/llvm 17. Instead of only touching the affected files, the commit also included, in my opinion completely pointless, changes to every single example by making their classes “final”.
Why was there a need to make the example classes final? What problem was solved by doing that?
What had that to do with fixing the clang/llvm 17 warnings?
As I understand it, it helped track down the source of an issue that clang (probably clang-tidy) was reporting, as a result we agreed we would use final wherever it makes sense to do so.
Thanks I probably won’t get to these as soon as I would like but consider it on my todo list to take a look at the examples in this repo. We know we are behind on addressing a number of bugs and I assure you the team want to, and in time will, get to as many of them as possible.
@reFX if you know any of the issues are already resolved it would be appreciated if the examples could be removed (or moved into a different directory?) as that could result in some wasted time looking into examples that can’t be reproduced with the latest version (that being said it’s possible they act as potential regression tests).
Sure: it allows us - as developers - to ensure that the thread semantics we expect actually equate with those which are granted us by the operating system, and if we have written well-behaved, multi-threaded code (we have) having the ability to set the AudioWorkgroup ensures that we can continue to organize our threads appropriately - outside the context of the DAW, sure, but … so? Not all DAW’s are equal and having this fine granularity of control over how threads behave in our own local context is very, very beneficial - both during raw development, as well as during the porting process.
Only true while it is the case that the other operating systems have to play catch up with the concept of energy-/processing- efficient cores.
I think the question is, why wouldn’t you want to use an operating-system provided mechanism for ensuring that the heuristics of your threads match the expectations of your users?
As for the discussions regarding feature/development/hacking branches - if you learn to use git properly and already have best-practices in place to do your own local testing, you don’t ever have to deal with these issues. The JUCE team have done pretty well so far - we are on version 7.x after all - so really this is just developers moaning about having to learn how to git bissect when the automatic tests have failed… oh wait, you don’t have automatic tests, and have never done a git bissect? That’s the real problem.
Suggesting that developers need to git bisect the master branch to avoid using features that have been introduced to it before they are really ready for production use is perhaps missing the point of the discussion which was to find a way to avoid some potentially brittle new features landing there in the first place.
Suggesting that developers need to git bisect the master branch to avoid using features that have been introduced to it before they are really ready for production use is perhaps missing the point of the discussion which was to find a way to avoid some potentially brittle new features landing there in the first place.
Well, “landing there in the first place” is the real issue: its called the ‘develop’ branch for a reason. These features haven’t hit main and won’t - until other competent developers validate them for broader application.
If you attempt to use a feature found on develop and yet you are are not willing to test-test-test and git bissect when necessary, then you’re not really qualified for the branch - you’re simply not the customer for the work, yet - so wait until the release has been done and validated by other developers.
I don’t see any reason for these features to be removed from develop just because a potential developer is incompetent.
I’m not questioning that using features on dev comes with risks, and a certain level of competence is required to handle that. It’s missing the point. There have been sufficient examples of changes that have made their way on to the main tree that should have either had longer in testing or that held up the main tree for longer than they should have keeping important fixes out of the hands of the masses for over half a year this year. So a separate tree could have benefitted many people - the discussion is valid. Not everybody is at an advanced level, Juce has education and beginner tiers for this very reason, but everybody deserves access to important fixes even if they are a beginner so let’s be more understanding and inclusive. Questioning the competence of developers dismissively like this is not particularly helpful and I think brings the tone of our discussion lower than we should really be aiming for.
This says Refactor nowhere you see hint this fixes anything
Here is an example where a new feature is add, but also got comments committed to another area (which isn’t related to the commit message).
Those are the ones I remember now but there were other scenarios in the past where a commit is gigantic (monolithic) and address multiple unrelated topics that makes it harder to bisect/debug/cherry-pick
Sorry, but that is just a word salad. Please provide a concrete example of how having the ability to join the AudioWorkgroup benefits you as a developer. How is that any different than just creating a realtime thread?
Sorry, but that is victim-blaming 101. You are saying it’s our own fault that the JUCE team is putting out buggy code.
What does the number of releases have to do with anything? There are still bugs in the code that have been there since version 1.0, so equating a version number with success or using it as a metric for the number of bugs is very naive. I could release 15 versions of our plugins today, but that wouldn’t mean that one version is inherently better than the previous one.
And now you’re making baseless assumptions and again blaming the customer/user (us) for the failings of the JUCE team.
We not only have unit tests, but we also have smoke tests, meaning we render audio files out of our plugins for every commit and then compare them against a set of known good audio files and raise alarms if the commit produces differences outside a configurable margin of error. So we don’t only test if our functions return the expected values, but if the whole complex system produces the right output, given a complex input. Can you say the same?
My real problem with the JUCE team is that the reason they officially state for not accepting pull requests is that
The code quality is not good enough
Doesn’t fit the style
Lack of testing or lack of manpower for testing
That it might interfere with future plans they already have
But except number 4, these are all nonsense, and they have proven time and time again that even number 4 doesn’t apply.
If their code is superior, where are all these bugs coming from?
There are tools to enforce a style, even during a commit.
It should be very obvious by now that they don’t test their code as stringently as they claim. Some things are hard to test, I understand, but some of these bugs are extremely obvious.
I don’t believe that having future plans is a good reason not to fix a bug. One never knows when these future plans come to fruition, but in the meantime the bug could be fixed for thousands of developers and potentially millions of users of the products these thousands of developers put out.
More than half of all these bugs would be long gone if they allowed pull requests. They are sometimes very simple fixes, but NOOOO. What if this or what if that, instead of just accepting and merging the pull requests? Maybe the name of the lambda function we picked is not up to their style? How about you tell us, or merge and change the name yourself?
Bug that is extremely easy to fix, has no side effect, and affects literally every developer who has a semi-complex UI:
If you set a component to opaque and wrap that component in another component that has an alpha value, you see garbage where the opaque component should be.
Here is a forum post about it from five years ago:
Jules seems to have added a check, but unfortunately, it doesn’t go up the parent hierarchy, so it only works in very specific circumstances.
Now we’ve found out the hard way and submitted this bug report:
Here is our fix:
And what is JUCEs official stance on the matter?
Why not use our fix? What could it possibly break? Is the code bad? You don’t like the static free function? Make it a lambda instead, or a class function, or whatever, but it’s VERY easy to understand and fix.
There hasn’t been a single point release since the release of JUCE 7. We’re still on 7.0.x.
Hey, let’s not fix bugs that affect thousands, but let’s instead implement a new feature (AudioWorkgroups) and fix HighResolutionTimer inaccuracies, because heaven forbid if the timer is off by half a nanosecond.
The JUCE team is showing very poor judgment of what to fix/implement and what to put on the backlog.
By not accepting pull requests, the product suffers. You’re ignoring good, working code for questionable (at best) reasons.
Was @anthony-nicholls code also not good enough before you hired him? Now it’s magically good enough?
The culture Jules established is just not healthy. Even though he’s no longer part of the team, his rigidness lingers on.
Maybe start by opening the process up a little bit? Let established, proven developers, with a good track record, help you out. I promise you will be positively surprised and everybody will benefit.
A benefit of joining an audio workgroup rather than just using a high priority thread is that you can give the OS practical timing information about when you require the work to be completed by, so if there are competing demands from many high priority threads the scheduler can make more informed decisions about which task it should actually focus on at a given moment. This kind of dynamic micro adjustments to the actual priorities being managed by the OS could be beneficial for some threaded audio applications.
Yes, but unfortunately, these are basically “hints”. You can not rely on it, nor are there any guarantees.
You can only test and hope for the best. On another system, you might get different results. Unreliable methods like this are a source of impossible-to-track-down bugs.
Pair this with the fact that it’s only for ONE of the platforms supported by JUCE (so unuseable for Windows, Android, Linux, etc.). JUCE added something that is against its own goals (multiplatform) and without a good reason. This was not released with JUCE 7.1 or 8.0. No, this was implemented as 0.0.x release. No feature branch, no extensive testing, etc.
This is the very definition of high risk, low reward. Are gamblers responsible for the planning?
I would wager that Apple is using it pretty extensively to implement the out of process Audio Unit implementation on Apple Silicon so think it’s worth looking into, it’s probably pretty robust if it’s being used for that. Waiting for a real-time OS in the mainstream computing space to solve this problem in the ideal way isn’t really an option, so I’m interested to at least give it a chance.
@reFX Stop saying BS about Audio workgroup. It’s not because you don’t see the usage that i’s not useful or reliable. Obviously the scheduler can do stuff if it has those info that just a realtime thread tag would not allow.
Still, I agree 100% with the other content of your post (a bit less the tone). There are looootts of issues reported with included bug fixes that the JUCE team discards. And I would glady see your fixes or some from soundradix put into the trunk.
Why don’t you read the docs, like a professional developer would, and find out?
They have very clear use cases and are entirely applicable to the goal of having high performance audio running on current generation systems. JUCE’ adoption of this technology is entirely appropriate.
If you still don’t understand that after reading the docs, let us know and we can clear it up for you.
Classic misdirection but not a valid argument - I’m saying its your fault as a professional developer who should know better if you get tripped up by features that are pushed to the develop branch. Entirely your fault, not the JUCE team.
Yes, this is about developer competence - you’ve challenged the competency of the JUCE team, so its fair game to challenge your assumptions about yourself as a professional developer, too. Whining about your own incompetence and then blaming the JUCE devs is just poor form.
Many of us have shipped JUCE-based products without having the issues you’ve created for yourself. The JUCE dev team are under no obligation to make sure the develop branch is suitable for your needs - wait until it smooths out and check out main when you need it, and if you’re really bothered about JUCE’ quality, you should of course run your extensive tests - which, incidentally are entirely your own responsibility. Not the JUCE dev teams…
This is your opinion and you have a right to it, but I couldn’t disagree with you more. You’re not more or less entitled to modify someone elses’ codebase than any of us. “He who owns the code, gets to say how the code is managed.” - this is F/OSS 101.
Its their perogative to choose what they want to work on and how to work on it - under what system of privilege does the demand that they service your PR’s make any sense - especially when you clearly are not willing to differentiate between develop and main in your own projects?
Perhaps through working with the rest of the JUCE dev team, he has demonstrated the competence they require. There’s a world of difference between an employee who is committed to following the coding rules and developer policies for a commercial project, and some random anti-git “developer” who demands their code take priority over all else - and then engages in community agitation when they don’t get their way.
It got us to version 7 and thousands of commercial projects, out there and shipping.
What has your culture established?
This I can agree with - but please, JUCE team, make sure you choose developer contributions that are easily ‘git bissect’-able - and I for one would welcome the ability to filter out all contributions from certain community developers whose work I feel is highly specious, so please make sure the git username persists in the commits … or create a contrib or community branch that can receive these contributions, yet not interfere with the other branches in development …
I think many of the people that are currently using “develop”, are doing so because it ends up containing the fixes to bugs that have been found in the current “master” branch.
If the bugfixes introduced in “develop” were cherry picked into “master” more often than it happens now, for example after a few weeks they have been committed to develop and showed no problems, then I believe most of us would be happy to stay on “master”.
And “develop” would be the right place where to put stuff that is in development (as the name suggest) like new features, etc.
I probably won’t get to these as soon as I would like but consider it on my todo list to take a look at the examples in this repo. We know we are behind on addressing a number of bugs and I assure you the team want to, and in time will, get to as many of them as possible.