<lucifer[m]> "if you cannot setup the dump..." <- The artist count for each country is shown [here](https://musicbrainz.org/statistics/countries) is there any other method to fetch this directly?
aerozol[m] joined the channel
aerozol[m]
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
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)
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-b...
I lean towards taking out the comma - thoughts?
Do you have a good entity in the DB that could be used as a series example? Ideally all fleshed out with relationships etc
Kladky joined the channel
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-serve...
<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.
i don't do much podcast editing, so i don't have any examples of series
<reosarevok[m]> "derat: can you see if you are..." <- looks good to me -- thanks!
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?
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
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.
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.
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
<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...
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.
For example playlist/playlists and `pin/delete/(row_id)/` vs. `/(user_name)/pins/`.
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?
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.
s/singluar/singular/
monkey[m]
OK, thanks for the feedback. That was also my "feeling", which didn't quite feel solid enough.
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-serve...
Deploying a new LB prod version in a bit, after testing it on beta.
Deployed.
reosarevok[m]
Thank you!
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-serve...
reosarevok[m]
aerozol, bitmap: opinion on my comment on MBS-13985 appreciated
