#metabrainz

Hi !

Lst week on the LB side I worked on the year in music PR

Making some good headway there

Also reviewed and helped in a few PRs

On the BookBrainz side I onboarded new contributors, and with their help found and fixed some issues with local development setup and docker image building

I also moved our CI setup to use Github actions

Bye bye Travis !

is that the last travis app we had?

dont the door hit you in the ass on the way out.

I also reviewed many PRs from said new contributors

All the activity is nice to see :)

!m new contributors

You're doing good work, new contributors!

And some well needed cleanup of the BB repo, issues, dependencies, etc.

That's it for me ! O'yvanzo go !

Hi!

(People still up: akshaaatt, ruaok, Freso – last call for anyone else who may want to give review!)

For Picard 2.7 beta 3 previously announced by zas, see https://blog.metabrainz.org/2021/12/02/picard-2... thanks to outsidecontext!

Last week I mostly coded and deployed a patch to lower the I/O load due to MB dump builders.

But no significant improvement has been observed on Saturday, so that failed.

(The only positive outcome is it allows for more flexibility in deployment.)

zas: It seems that offloading may be the only solution.

Otherwise I reviewed a few pull requests.

I think the issue is what bitmap said: pg + dumps on same machine, using slow disks

Also fixed another small bug in MBS deployment script.

Updated BrainzGit to the latest version of irccat.

Finally, I planned to update Jira server this week.

Go akshaaatt!

My week started really strong with work on the brainzplayer, lb redesign stuff and year in music

I also made quite some progress resolving issues with my mb PRs

Last part of the week was not so good due to some medical reasons at home.

Hopefully things get better and my work goes as I've planned this month! Excited for the work upcoming

That's it for me. ruaok next?

hiya

last week was the usual MeB stuff and paying people...

I also finished my playlists for YIM, but I still need to delivery the previews to the YIM datastore on the LB server, but I hope to finish that tomorrow.

I spent a lot of time making troi improvements -- I've now written a lot of the core functions needed to build this playlist tool.

so I spent 2 days trying to work with the annoy indexes in AB, but it didn't work out so well.

there is one more thing I can try, but I am not that hopeful at this point.

what disturbed me the most were my realizations about AB.

we knew the high level data was crap and that we needed to run all that data once the algs were updated.

fine. not a good place, but recoverable.

then we found last week that the BPM code is rather quite unreliable. it was promised to be reliable.

and then digging deeper into AB with the annoy stuff, I strongly suspect that the low level data we have in AB is worthless.

which is a really sad note to end the week with.

not sure how to proceed with that yet, looking forward to a chat with alastairp this week.

that is for me. fin. Freso?

🙋

personally, I think it's not the end of the world, but clear that the continual improvements that we wanted to do originally are something that we need to look in to

On less sad news, it _looks_ like theless has gone away? Or taking a break at least. I spent some time dealing with them last week, including one day where we happened to be online at the same time, so I spent a few hours whacking their mole accounts as they popped up.

Freso: great.

Other than that, looking at general flags/reports and had my brain eaten by reosarevok about the edit note editing.

loi reozombie!

And being around/about-ish. :)

fin.

No more people up for reviews, and (!!) no more items on the agenda.

Good job everyone getting tickets made from the summit notes. :)

I just read this article about someone leaving the MySQL team: xxxhttps://blog.sesse.net/blog/tech/2021-12-05-...

Thank you for reviews and for your time. Take care of yourselves out there!

</BANG>

Thanks Freso

he says to MySql is shit. the tide might finally be turning on the truth about postgres.

thanks freso!

Thanks!

And without the triple-X: https://blog.sesse.net/blog/tech/2021-12-05-16-...

yvanzo, bitmap: pushed https://github.com/metabrainz/musicbrainz-serve... again with an actual fix, AFAICT

nice short meeting, thanks everyone

I feel like MySQL is kind of the PHP of RDBMSes.

xxxhttps? that must be the new pr0n HTTP protocol I've heard about

Which might be why they’ve been used together so much. :p

reosarevok: Thanks, will look at it after food.

Freso: pretty much. was good for its day. but it couldn't hang on. not necessarily due to its own faults.

like many things, mysql was in the right place at the right time

ruaok: "MySQL is a pretty poor database, and you should strongly consider using Postgres instead", open secret really :D

yvanzo, bitmap: I think I'll call it quits for the day, and release beta tomorrow morning :)

Or actually

I might release a beta now, then another tomorrow evening?

I still remember how annoyed I was at how the default postgres (7-ish?) auth setup worked, way more complex compared to mysql's simple 'create user'

yvanzo: you should tell that to the people who can't use MB because they are a "mysql shop"

(if we merge a bunch of this stuff)

i think most people do agree that postgres is better than mysql as a single node db. i have heard many say that mysql clusters are easy to manage for a distributed db than pg but never handled that myself so don't know.

Or even Wed morning

I have to explain this all the time to prospective customers

alastairp: yep. "\q" bugged me the most, lol.

ruaok: I would have probably still been using MySQL/MariaDB for my pet projects if it wasn’t because of MB. Thank you. :)

that being said, mysql's commandline is terrible. I frequently have to use it, and it doesn't do readline :(

ruaok: Now you can use this citation from Steinar H. Gunderson, former Oracle software engineer working on MySQL.

"Don't believe for a second that MariaDB is any better. Monty and his merry men left because they were unhappy about the new governance, not because they suddenly woke up one day and realized what a royal mess they had created in the code." XD

and much like php, people still just assume that [mysql, postgres, anything else here] is still as terrible as it was when they first learned that it was terrible

php, mysql _and_ postgres are a lot better than they were 10 years ago

but php is still that terrible!!

i didn't write php 10 years ago though so i guess it might have been even more terrible then :D

For sure. And a lot of the problem with PHP is more that most prominent projects in PHP are terribly written more so than the language itself. I did not like working with PHP when I did some hacking on phpBB or Wordpress, but PHP was perfectly fine when I worked on Drupal.

[listenbrainz-server] 14amCap1712 opened pull request #1769 (03master…msid-no-data): Fix loading recordings from msids https://github.com/metabrainz/listenbrainz-serv...

[listenbrainz-server] 14amCap1712 opened pull request #1770 (03msid-no-data…mbid-from-msb-no-more): Remove load_recordings_from_mbids https://github.com/metabrainz/listenbrainz-serv...

yvanzo, bitmap: I'll actually release two betas, I think :)I

Since we have a few merged bugfixes

ruaok: monkey: lmk the method you discussed last week when you remember it :)

reosarevok: thanks :)

I can't really remember. We talked about mapping incoming listen_now faster to be able to have rec_mbids available when we send them to the front-end

I don’t know about MySQL’s potential design issues, but things have been worse for MySQL since Oracle acquired it.

We also talked about liking a track using artist and track name, and resolving that to an MBID in the endpoint itself , but maybe I'm misremembering. Ring any bell ruaok ?

yeah that artist and track name way is the proposed solution in the currently open PR too. but the current msid dict considers many other fields as well so the endpoint will need to accept those optionally as well.

Wright's plane wasn't that bad if one considers it was a necessary step to modern airplanes (but it was an awful plane by today's standards). I think of PHP & MySQL somehow the same, they were a necessary step towards 21th century web. Time to move on, but it makes no sense to say they are/were "bad".

And don't worry, your favorite technology of today will get old too, and likely follow the same road ;)

[bookbrainz-site] 14dependabot[bot] opened pull request #735 (03master…dependabot/npm_and_yarn/core-js-3.19.3): chore(deps): bump core-js from 3.19.2 to 3.19.3 https://github.com/bookbrainz/bookbrainz-site/p...

[bookbrainz-site] 14dependabot[bot] opened pull request #736 (03master…dependabot/npm_and_yarn/clean-webpack-plugin-4.0.0): chore(deps-dev): bump clean-webpack-plugin from 3.0.0 to 4.0.0 https://github.com/bookbrainz/bookbrainz-site/p...

(small aside, seeing these BrainzGit messages - are there any plans on switching the main branch to 'main' instead of 'master'?)

Not that I know - I don't see the point either, "master" is not connected to slavery here at all AFAICT, but to master copies, no? So it'd be a bit like changing "master of arts" or whatever

I understand github made the change for new repos, but it still makes no sense to me

i have no dog in the race either, but I figure it's a small enough change (rename is trivial on GH, and people with clones only need to run 4 or 5 commands, once)

Another proposed alternative to the poop emoji: https://tickets.metabrainz.org/browse/LB-1023

LB-1023: Consider replacing the broken heart emoji as the "hate" icon

*why* do we need to replace it?

ag

sleeep

oh man, I'd be fine with 20 being off since it's so close to jul

Because saying, "This song breaks my heart" doesn't necessarily mean that you hate it. You may love the song, but it breaks your heart for sentimental reasons.

who says anything abou breaking heart?

it's more like "this isn't totest not love"

That's what the "broken heart" emoji says.

i guess i see the emoji differently

anyway I'm tired and going to bed. natta everyone

I only raised it because it wasn't intuitive that this meant that you hated the song. The broken heart concept just didn't make sense to me in that context.

hm

i think tis is one of those things where an user prefrence woudl be really neat

> We also talked about liking a track using artist and track name, and resolving that to an MBID in the endpoint itself , but maybe I'm misremembering. Ring any bell ruaok ?

that was it, monkey, thanks!

lucifer: what monkey said -- I think when we receive a now listen, we should do a lookup in the mbid_mapping_meta table, but not do a full MBID lookup. if that fails, don't show the heart button.

that should scale acceptably.

ruaok: lookup for an exact match of the artist name and track name in the mapping table?

yes

i see. do we still keep feedback on msid?

i mean allow feedback for msids that could not be mapped to a mbid.

I have a feeling it would be good to keep that for a while.

in other words, support mbid or msid for a piece of feedback

makes sense.

as a stopgap, i think that is fine. but if we want to support msid forever then might as well, do a msid lookup for feedback.

*for feedback on nowplaying