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

[ann0see]

Similar to 3.9.0, I will try to follow the procedure by hoffie from #1825.

Again, we needed quite some time to get this release out. I think, we should really simplify the release process and tighten the timeframe a bit.

The following points are my personal impression:

The good:

• We've adapted to Weblate and most translators seem to be fine with it. Even some more translators got on board. There are still some open questions. E.g. how should we handle per translation issues? Are they still needed or can we use one big one, as most stuff happens on Weblate.
• The community, including the development team still seems to be functional, even though concerns of the project being dead have been raised. Discussions and issues are mostly answered withing a short timeframe. However, the creation of this discussion should make us think about it.
• We finally got the Debian Repository, SRV records and a lot of other features out. That's great!
• We are still in close contact to Volker (@corrados) but the project also runs without him
• Communication with the most active translators works well. Even if there are last minute problems (like me force rebasing the Weblate Repo)

The bad:

• The release process still seems too be too complex. Especially with Weblate, I believe there are ways to simplify the release process vastly.
• Also connected to Weblate: I hope, that once we add more documentation about how to handle Weblate, this complexity should get better. https://github.com/orgs/jamulussoftware/discussions/3140 should be the place where this is discussed.
• The release process for the Website has improved, but is still not as good as the app one. We should streamline both.
• There seem to be longer lasting disagreements between community members which the Jamulus Dev team can't solve. This has already happened before the current one. We have the Jamulus Forum Etiquette but no Code of Conduct yet. Unfortunately, I don't think adding one will resolve disagreements. We should still agree on how to handle situations like this.
• There are still a lot of open topics we didn't touch from the last retrospective

Applied from last retrospectives:

• From Retro 3.8.0: I believe we got better in detecting when a new release should get out. Not a lot happened code wise between the releases.

All in all, after almost a year, we got the release out. Again huge thanks to all the contributors!

Happy to hear about impressions, ideas etc for the next release and the time between. Did I forget to mention something? I think so! So, no matter if you're a translator @jamulussoftware/translators Main-Dev @jamulussoftware/maindevelopers user or anything else, please add your thoughts below.

[rdica]

Thank you all for your hard work in creating and maintaining Jamulus!

I'd like to mention expansion of the feature set in JSON-RPC for both client and server. I can attest to using it successfully to manage server naming and server welcome message changes on a regular basis. I thnk there are some existing PRs that add some ACL functionality already?

[ann0see]

Yes! Thanks for adding JSON RPC

ACL functionality

I remember reading about it. @Rob-NY or @dtinth implemented that. If they open a PR, we can try to implement it. As this was a quite controversial topic in the past, this would require explicit approval by more than 2 main developers and/or long term contributors in my opinion. It would receive my vote.

[Rob-NY]

I do have completed and tested code for RPC extensions that include server-side ACL, chat hooks, welcome hooks, and a few other management-related methods. I can split out the ACL from the rest. Both potential PR’s would likely start long and protracted dialogs which, frankly, after my last PR (which was far less polarizing) was a rather bitter experience for me here. While I’m willing to share this code, I just do not have the energy to endlessly iterate on these topics. So when there are two main developers who support these features, I’d be more than happy to submit the work and debate the quality of the PRs - but not their goals.

[dtinth]

@Rob-NY I agree with your sentiment — it’s one thing to make a quick improvement to make it better for my own use, and it’s a whole another thing to get the changes to a point where most people are happy with it¹.

I’d encourage publishing your patches in your own fork, so that in the meantime, people who also want the feature can apply them to their own copy and compile it themselves. Maybe someone might come along who wants the feature in the official release and are willing to put in the necessary work to get it shipped.

Footnotes

1. My original JSON-RPC PR has 300+ comments (broke the record of most number of comments I received in a single PR) and took 7 months to merge, but the discussion was all productive, improved the quality of the feature, and I learned a lot along the way, so I understand why this process is in place. ↩

[ann0see]

I agree with all of you. The review process is sometimes way too slow (I know it's also my fault).

[mcfnord]

If this code becomes available on a fork, I welcome concrete anecdotes of its value in the field.

[pljones]

As mentioned, one of my main areas of concern was the integration of the Release Process documentation and the Weblate processes. As I've had no involvement with translations, understanding how the two relate without supporting documentation was... fraught. The discussion raised should be used for investigating and developing a plan for future improvements / simplification.

The other area, also one touched above, is the duration of the iteration cycle.

We're currently slow at releases. This is partly because the release process is unpleasant to use, I think -- there's back-pressure to avoid having "too many releases" as having to go through the process is something to be avoided.

That leads to two things:

• the project looks stagnent
• expectations for a new release aren't met - this release, for example, gives the vast majority of Jamulus users nothing at all

If we had a much shorter iteration cycle - i.e. four to eight weeks - we could keep expectations lower whilst raising awareness that new development continues, incorporating fixes and new features.

So I agree - we need to look at the whole release process and say "what's actually needed to put out a release?".

Ideally, we'd have a "nightly release" process, where the nightly could simply be tagged and become a full release - and any accepted changes to that point would be included. Translations would need, then, to be included with each PR, however, along with website changes. I don't know how easy that would be on Weblate - translating multiple branches at the same time, rebasing and merging, etc.

[ann0see]

I don't know how easy that would be on Weblate - translating multiple branches at the same time, rebasing and merging, etc.

I believe that is a big hassle.

[jujudusud]

Hi everyone, As you know I'm translating both APP and website.
Weblate looks like an interesting tool. I think it is good to be able to use it and also to use git or anything else to translate.

I personally have a problem with two things:

• I find that having "Jamulus app" in the middle of the other files to be translated doesn't help you see that you have to translate that file first, and then, in a second time, start working on the website. I think it would be a good idea to separate these two parts for translation as it for the repositories.

• I think only one PR should be opened per language linked to the issue opened for translation. One PR for APP translation and PR for Website translation. So changes in weblate should show up in github as commits related to that PR and issue and not like new PR.

[ann0see]

I don't have access to any of the management features under the 'Manage' tab in Weblate. I'm signed in but I don't have any administrative rights.

Same here for "Verwalten" = Manage tab.

[ann0see]

@gilgongo @comradekingu does anyone of you have access?

Maybe I did something wrong and removed all admins? But not sure why nobody then has access. Shouldn't there be at least one person who has access?

In my profile teams says this:

Maybe the Administration team has lost admin access.

[pljones]

"Access only" doesn't sound right, no.

[ignotus666]

We seem to have locked ourselves out somehow, but as you say, at least one person should have access - I guess that should be me since I created the account and didn't lock myself out. Maybe it's some kind of glitch but we'll have to contact Weblate support.

[ann0see]

I just filled and sent the contact form: https://hosted.weblate.org/contact/ hopefully, they'll respond.

[pljones]

[ ] Update this template in https://jamulus.io/contribute/Release-Process with any improvements if needed.

One result of the retro needs to be the above -- the retro should have capturing release process improvements as its goal, so its output should be updating the release process document.

Hence one output is to update the template to move updating the template to the retro. We could also think about having a retro template (i.e. areas we commonly want to look to improving iteratively).

[ann0see]

Yes. A retro template would be good