Release retrospective for 3.8.0 (Developers/Translators/Contributors/Users)

[hoffie]

Similar to 3.7.0, I want to start a Discussion about the 3.8.0 release process.

My personal impression:

The good:

• I think we have a new release with lots of interesting features while still sticking to core principles and keeping Jamulus stable, compatible and maintainable.
• I think it was a good idea to create per-translation issues. It vastly simplified tracking of translations for me personally and there was also feedback by one (or more?) translators that it made things clearer. I'd like to keep doing that.
• There was a very important behind-the-scenes change which took lots of effort to do and -- if everything went right -- does not change anything visibly for end-users. :) I'm talking about the agreement on and implementation of a consistent coding style by @passing (based on clang-format)! Thanks, Martin :) Having a fixed coding style ensures long-term code maintainability. Automating the formatting and checking saves resources both on the contributor-side and on the reviewer-side and avoids frustration caused by an arbitrary-sounding coding style.
• Our release documentation, tooling and automation is getting better (well, I have to say that as I'm working on some of those parts)... This will hopefully streamline future releases even more.

The bad:

• The release took -- once again -- longer than anticipated for multiple reasons. At the same time, this is a volunteer project after all, so there is no duty to release earlier. We might have still benefited by doing so.

  • It took some time to realize that we have enough content for a new release. This is where we can get better, I think.
  • Thanks to a report by @pianojoe we found and avoided an important performance issue for macOS Big Sur users. Sadly, this took a massive amount of debugging, bisecting and testing which was mainly (solely?) performed by @softins. Thanks for that, Tony! We seem to have avoided that regression, yet, there still seems to be more to it and further fixes, workarounds or changes (@dcorson-ticino-com is working on a Qt6 build) will probably be required to keep Jamulus working flawlessly for macOS Big Sur users.

• Translation scope became a bit chaotic, both for the application and the website.

  • This was caused by multiple non-avoidable last-minute changes, either because none of us thought about doing them earlier or due to the mentioned Mac problems which required a rather large UI change in rc2 phase.
  • Communication around this was non-optimal, too. Yet, I'm still not sure what would have been better in all cases, so feedback by translators is highly appreciated! Would translators rather get multiple requests to get even the last What's this string translated properly or would they rather prefer a single task and be done with it for a given release?
    • App-wise, we (well, again @softins :)) made several manual updates to avoid running another translation around. Avoiding another round was actually something I've personally pushed for, mainly in order to avoid delaying the release and in order to avoid annoying translators with repeated requests for the same version. Some translators spotted the changes and raised PRs with updates pro-actively. In hindsight we might have well run another official translation round as the release was delayed anyway.
    • Website-wise, some important changes were not part of the translation branch and the fact that there would have been other things to translate was only mentioned in a chat conversation. In hindsight, this should have been communicated in an update to the translation tickets. I haven't been too involved with it, but as per my impression @gilgongo, @ann0see, @ignotus666, @henkdegroot and @jujudusud were those who were the most involved with trying to fix that. The newly designed po4a-based website translation workflow by @ignotus666 is expected to make several of those things easier in the future. :)

All in all, I think that the result is very good and I've really enjoyed working with all of you once again!

Happy to hear about your impressions and ideas for improvement, no matter if you are a user of Jamulus, a code contributor to Jamulus, a member of @jamulussoftware/translators or a member of @jamulussoftware/maindevelopers! :)

[henkdegroot]

As a translator and from an app translation point of view, I would not mind having to update the translation more than onces in a release when required. Of course a single translation would be nice but when a second/third round is needed, then no problem. As long as I don't have to "redo" previous translated strings. "Redo" would be acceptable if the contents/meaning of the text has changed of course.

[softins]

A big thank-you to you too, @hoffie for co-ordinating it all. We all bring different strengths to the team, and one of yours is definitely in keeping it all organised well!

Regarding the Mac issue I investigated, prompted by the initial report from @pianojoe, that was not specific to Big Sur. The issue around updating the ping and delay stats repeatedly in an open not-on-top settings window was also evident on Mojave (on which I did all my testing), and may be a Qt limitation. There were definitely other issues related to Big Sur, some of which we have yet to understand.

[softins]

• It took some time to realize that we have enough content for a new release. This is where we can get better, I think.

This is a double-edged sword. Given the amount of work involved in a release, particularly with betas and rcs (which have been valuable, although Volker never did them), more frequent releases could make this workload higher. On the other hand, if a release has less new stuff in it, there is not so much that needs validation.

There is also the pressure of a continual stream of new, good PRs from people keen to see their feature or fix make it into the soonest possible release. A feature freeze, bug-fix only phase addresses this, which is what I know we tried to do.

[ignotus666]

Speaking for myself, I have no problem with receiving additional post-freeze translation requests - I find it more annoying to find a small translation update taking 5 minutes didn't make it in due to not receiving an alert, than receiving an alert I can choose to act on - or not. I appreciate this wasn't done precisely to avoid annoying anyone; just making it known that if it came to it, I would prefer to receive an alert.

Regarding website documentation tasks, maybe it would be good to have a todo checklist with items added as they arise and the option of assigning them to members. Something like this. My impression is that we have a bit of a haphazard approach where issues are opened or commented in passing in a conversation that then get buried and lost/forgotten. Things like "Add X feature to documentation", "Check links in EN/ES/XX", "Update screenshots for EN/XX", etc. I think it could provide a clearer overview of what needs doing/who will do it/if it's been been done, rather than searching through the list of issues.

[hoffie]

I would prefer to receive an alert.

Understood, thanks.

My impression is that we have a bit of a haphazard approach where issues are opened or commented in passing in a conversation that then get buried and lost/forgotten. Things like "Add X feature to documentation", "Check links in EN/ES/XX", "Update screenshots for EN/XX", etc. I think it could provide a clearer overview of what needs doing/who will do it/if it's been been done, rather than searching through the list of issues.

I wonder whether it would be possible to keep using Github issues for that and just ensure that a proper visualization is available? Filtering by milestone, using the project board or using labels might help?

(BTW, I was surprised to see the name "corrados" on the page you linked ;))

[ignotus666]

I just thought it offered an easy way to visualise tasks in a single place and the possibility of (self-)assigning "who" will take care of "what". More than a roadmap per se, where a set of targets are established, I was thinking more of those tasks that "arise" along the way, like editing a certain document, correcting a link in all languages, etc. But it might cause more work than it saves though - IDK, just throwing it out as an idea.

(BTW, I was surprised to see the name "corrados" on the page you linked ;))

Ha ha, yes! I forgot to mention that. He's working on a DIY edrum module that will apparently use Drumgizmo. As the user of a DIY electronic kit I'm following his progress closely and will very likely build whatever he comes up with.

[ann0see]

Also a big thank you from my side! I haven't been active during a critical phase of the release and can't comment much on that ;-).

Yes, the website was a bit of a chaos and still requires some work. @ignotus666 is working on getting po4a ready which will probably streamline the whole process on the website. I am quite sure that we can improve in this area in future.

Having a well documented release process is certainly good and very valuable. Thank you @hoffie!

However, the whole process is getting more and more complex. Automation or shell scripts might simplify the process. Also deciding early (= after each release = now) on what to include and what not to include for the next release might make finding a release date easier. This would go with @ignotus666 proposal of having a roadmap.

[hoffie]

Thanks :)

Also deciding early (= after each release = now) on what to include and what not to include for the next release might make finding a release date easier. This would go with @ignotus666 proposal of having a roadmap.

I think @gilgongo also suggested something like this in the past.
I'm not convinced that roadmaps scale well on a fine-grained level, especially when working with volunteers, both on the contributor and on the developer side. The current approach is "what is accepted and ready by date X gets in". Personally, I think, this is fine. I think that's comparable with the Linux kernel where there is a "merge window", e.g. a timeframe where PRs are accepted. I think it also depends a lot on the maintainer vs. contributor ratio. My gut feeling is that currently, a large part of new features is contributed by non-maintainers (which is good!). However, this also limits the amount of active planning we can and should do. We should, however, make sure that all such contributions match the Jamulus core principles, of course.

Having a roadmap makes sense to me when thinking about long-term topics (TCP, auth come to mind) which require coordination. @gilgongo had a list for that as well, I think.

[gilgongo]

Thanks for this analysis!

The main reason why the website translation process went wrong this time was that I forgot some features were being included in the release, so I added this PR "addendum". I don't know if we can have anything in the process that could easily safeguard against missing a "doc-breaking change" though. Perhaps prioritising the writing of the change log at the start might focus minds more than simply listing tagged PRs? Hard to say.