Thanks for helping with the country query for holycow23, lucifer! For the "play music from this country" LB ticket. I already mentioned this on the ticket holycow23, but if it's too tricky there are things we can hardcode on that row/to fill that space instead. Grabbing dynamic stuff/stats is always more interesting though
2025-04-15 10512, 2025
aerozol[m]
bitmap: reosarevok: Re MBS-13984 I also initially thought to just hide them. But if I think of a future where we use those recording relationships a lot/use them in LB and I (as an editor) am interested in adding them everywhere, it becomes important to not have to click through to each recording to spot where they are missing.
If it's really complicated then let's hide em, but otherwise I don't see a downside to collapsing and expanding them. I left an example on the ticket that could even be an upgrade for everyone, if anyone is feeling extra keen (summarize the data in a useful way, when collapsed)
2025-04-15 10527, 2025
aerozol[m]
derat: I gotta run, but thanks for reminding me! I thought the comma looked stupid so I brought it up in the forum thread, but I guess nobody replied and then I forgot: https://community.metabrainz.org/t/style-2606-bro…
2025-04-15 10516, 2025
aerozol[m]
I lean towards taking out the comma - thoughts?
2025-04-15 10555, 2025
aerozol[m]
Do you have a good entity in the DB that could be used as a series example? Ideally all fleshed out with relationships etc
2025-04-15 10529, 2025
Kladky joined the channel
2025-04-15 10513, 2025
BrainzGit
[musicbrainz-server] 14reosarevok opened pull request #3519 (03master…extra-wording-for-mbs-13711): Add short note about exceptions to new capitalization warning https://github.com/metabrainz/musicbrainz-server/…
<aerozol[m]> "I lean towards taking out the..." <- i think that "Podcast #123" looks much better than "Podcast, #123", so i'd agree with removing the comma. i don't have much of an opinion about "Podcast 2025-01-02" vs. "Podcast, 2025-01-02", but maybe dropping the comma there as well would simplify things.
2025-04-15 10527, 2025
derat[m]
i don't do much podcast editing, so i don't have any examples of series
2025-04-15 10547, 2025
derat[m]
<reosarevok[m]> "derat: can you see if you are..." <- looks good to me -- thanks!
2025-04-15 10515, 2025
derat[m]
i guess there's a small risk that it makes beginners more likely to take the easy way out and click the checkbox without reading the guidelines, but i still see people submitting titles containing featured artists, so there's probably not much that can be done there
julian45[m]: that is interesting. from a security perspective this makes total sense. from a commercial perspective? and did lets encrypt have anything to do with this shift?
2025-04-15 10548, 2025
zas[m]
I'm thinking about reworking gateways so we can finally switch to LE certs for all domains, moving certs management from openresty to haproxy. That's not a trivial change. My idea is to use lego to manage LE certs, along a script to deploy certs on gateway servers. It is possible to update haproxy certs without downtime using the API, we'll still use consul as source for domains to get certs for. Compared to current setup, haproxy will
2025-04-15 10548, 2025
zas[m]
talk http/s/2 rather than tcp, it will also help with rate limiting and traffic filtering. It will also open the door to skip openresty completly for some services. Still thinking about the whole thing, but clearly we have to get rid of paid certificates and lua autossl.
2025-04-15 10509, 2025
zas[m]
Once my plans are clear, I'll order new servers to replace current gateways (so we can fully test the new setup before the switch). We should be able to do that without downtime.
2025-04-15 10529, 2025
julian45[m]
no complaints from me; if you wanted to keep a non-LE CA for some reason, a decent amount of them support the ACME protocol (using EAB for auth) and certs can be trivially obtained through compliant clients like certbot; i've done this with my day job before since our federation's cert service is provided by sectigo
2025-04-15 10533, 2025
julian45[m]
<mayhem[m]> "that is interesting. from a..." <- LE appears not to have been involved in this particular CA/browser forum vote, at least as an issuer: https://groups.google.com/a/groups.cabforum.org/g…
2025-04-15 10559, 2025
mayhem[m]
from speculation to fact checking. awesome. thanks!
<mayhem[m]> "consistency is key, but using..." <- I looked in the codebase a bit before asking here, and I do see a few plural+singular uses in our api endpoints.
2025-04-15 10545, 2025
monkey[m]
For example playlist/playlists and `pin/delete/(row_id)/` vs. `/(user_name)/pins/`.
2025-04-15 10545, 2025
monkey[m]
So should "consistency" here mean that we do use singular in other places, so let's do it here too? Or that all the other feed events endpoints are plural, so let's do plural here too?
2025-04-15 10543, 2025
mayhem[m]
I think in this case, we should make them consistently plural since we didn't really set the "only singluar" rule for endpoints. we have that rule for DB tables.
2025-04-15 10551, 2025
mayhem[m]
s/singluar/singular/
2025-04-15 10507, 2025
monkey[m]
OK, thanks for the feedback. That was also my "feeling", which didn't quite feel solid enough.
2025-04-15 10548, 2025
BrainzGit
[musicbrainz-server] 14mwiencek opened pull request #3520 (03schema-change-2025-q2…mbs-13964): MBS-13964: Some recordings are missing a first release date https://github.com/metabrainz/musicbrainz-server/…
Deploying a new LB prod version in a bit, after testing it on beta.
2025-04-15 10504, 2025
monkey[m]
Deployed.
2025-04-15 10532, 2025
reosarevok[m]
Thank you!
2025-04-15 10531, 2025
BrainzGit
[musicbrainz-server] 14reosarevok opened pull request #3521 (03master…MBS-13985): [WIP] MBS-13985: Show inline primary alias for work authors and artists https://github.com/metabrainz/musicbrainz-server/…
2025-04-15 10552, 2025
reosarevok[m]
aerozol, bitmap: opinion on my comment on MBS-13985 appreciated
