#metabrainz

yvanzo, bitmap: throwback with expected_linktype_combinations ? :p

now the database is also on aretha

bitmap: I guess we want to keep the build time of json dumps under 24h? Would a dedicated machine help with?

either a dedicated machine or moving the DB + json-dump container to other hosts

the advantage or being on aretha was that the ftp data is hosted there too

of*

reosarevok: "link" is the other term for relationship in MB SQL code, right?

Yes, and in old perl stuff

and in some JS too IIRC.

musicbrainz_json_dump is 147 GB

reosarevok: ok then, with a _ in the middle :)

With _ in the middle we'd already have to indent the whole file one space more :(

reosarevok: or restricted_link_type_combinations ?

the json-dump process itself also needs several hundred GB of space before compression

I guess I'll space everything further and use restricted_link_type_combinations or something

reosarevok: or using a synonym? limited_link_type_combinations

Ok, limited_link_type_combinations is the maximum size without reindenting

So whatever, I'll use that :D

what do the nested arrays mean?

A combination, so either one, the other, or both are allowed

We clearly need to document this test structure further.

I think the issue is restrict is pretty new and the documentation for it is IMO not that clear itself

Here I had " // The options can be just one relationship type, or arrays of 2+ types" but we might need more than that

The only documentation so far was this commit message: https://github.com/metabrainz/musicbrainz-serve...

Oh, more generally you mean

I guess it wouldn't hurt

The array structure is documented at https://github.com/metabrainz/musicbrainz-serve...

To be honest, that section really doesn't suggest to me that in order to be able to combine types, you *need* to use multiple or a nested array, nor that multiple means that it must have both unless you also add them separately :)

It probably requires more complex example.

Maybe

Ok, I guess those two should be broken into two lines each :)

Jamendo restrict code can be used as an example of allowing more than one type at once.

yvanzo: I updated https://github.com/metabrainz/musicbrainz-serve... for now

Including a fix for the vimeoondemand bug

Mainly Norfolk restrict code can be used as an example of allowing one type or another.

(for "work" entity type)

ruaok: monkey: alastairp: for adding recording mbid to feedback, i am thinking of adding recording mbid column to the table. make recording msid column nullable. support both recording msid and recording mbid in api for some months. then remove msid support from api and delete msid column. thoughts?

Oh, so adding more examples to the same original test ticket?

*PR

Sure, can look into it

Yes

ack, broken heart is fine for hate/dislike. it's really logial and works with the heart one logically

So we can test the tests with code that we think is working already :)

for existing feedback, run a script to fetch mapped mbids and put in the table.

I will veto any vomit :grøss:

lucifer: yes I've been thinking thar would be good.

I wouldn't necessarily veto it but it's a bit gross :)

yvanzo: on it

yvanzo: jamendo already does expected_relationship_type: ['downloadfree', 'streamingfree'], since there's just one allowed option

ruaok: although that plan means unmapped listens can't be given feedback on. to keep feedback on unmapped listens we keep supporting msid forever.

i guess that is fine but we'd need a way to update that table when new msids get mapped to recording mbids.

alastairp: don't forget to actually vote in the middle of all the tickets ;)

bitmap: Would it be helpful to parallelize json-dump on different servers to lower the load on aretha? Or would it be worse for completion time since it involves more networking?

reosarevok: yes

yvanzo: mainlynorfolk does expected_relationship_type: 'otherdatabases', to test the autoselect, but I guess that suggests we should actually allow both types of testing *in combination*

reosarevok: I mean, we can refer to it in code documentation of 'restrict'

Oh

Still, we have no way to test rn that norfolk allows both but autoselects one

Hmm…

So maybe these two shouldn't be either-or, but both be allowed :)

reosarevok: It seems that Mainly Norfolk code correctly allows either 'otherdatabases' or the combination of 'otherdatabases' and 'lyrics' for works.

Yes, it does, we just don't test it

Ok, would testing it in that PR help with testing the tests? :)

I think it would help make the tests more stable long-term in any case

I'm checking

yvanzo: i'm sure it would help but it would take some time to parallelize it properly, I think, making sure everything gets synced to the same FTP dir. it adds more complexity so more places for things to go wrong

wth "mainly norfolk" ????

CatQuest: a folk website

uh folk in like about people? or uh genre

A website about mostly folk music we have in otherdbs

oic

also can someone help define this "ANNOY" thing ? https://wiki.musicbrainz.org/MusicBrainz_Slang

Sigh, so it seems default array.sort() does not know what to do if the array has both strings and arrays in it

bitmap: any suggestions?

well, you can pass a sort function to .sort()

Sure, do we have any good ones for something like that? :)

Or do I have to come up with one?

I guess another option would be to ignore sort and just see if all the stuff in array a is in array b and they have the same length

I don't think we have anything for it

rn I had

But that just failed because one sorted to 'string', ['string', 'string'] and the other to array then string

monkey: last week we though of a mechanism by which we can make liking an now_listening track. I don't recall the details of how that was supposed to work. do you?

i'm guessing it stringifies the arrays to string,string before comparing

it is likely it requires changes indeed.

lucifer: monkey and I thought up an idea that seemed plausible last week.

bitmap: wouldn't then it always sort the same?

yeah it should

which ones are sorting different?

also plox someone explain what the definition and origin of moin is exactly

<BANG>

It’s Mitten Tree Monday!

I haven’t received any mailed in reviews, so the people I have as up for reviews today are: bitmap, reosarevok, lucifer, akshat, ruaok, monkey, yvanzo, zas, alastairp, CatQuest, Freso – anyone else who may want to give review, let me know ASAP. :)

bitmap: Go!

hi

last week I did code review and finished converting most of the release editor .tt templates to JSX

I still have to convert the actual events and actions to React though, which will take a while, so that when you click on stuff, stuff happens

Stuff happening is overrated

I thin kthat's mostly it

go reosarevok!

Hi!

sometimes it's good when stuff *doesnt't* happen

I mostly worked on MBS-11312

MBS-11312: Allow admins to modify edit notes https://tickets.metabrainz.org/browse/MBS-11312

(just sayin')

Plus I helped alastairp a bit more with genre stuff

CatQuest: you?

Meow! `😺`

⛎

fin, go zas?

Hey

I upgraded discourse & grafana instances + usual system upgrades

We also release Picard 2.7beta3, so I handled a bunch of post-releases bug reports & associated fixes

We expect to release final version in 10 days or so

apart that, I'm preparing a docker server configs patch to handle the deployment of new consul cluster

!m crew of the Enterprise

You're doing good work, crew of the Enterprise!

fin. lucifer ?

hi all!

i worked ahead on the pinned recordings api last week. reviewed troi and LB prs. worked on progressing the PR to replace username with user ids in LB.

(People still up: akshaaatt, ruaok, monkey, yvanzo, alastairp, Freso – anyone else who may want to give review, let me know ASAP. :))

i also looked into the summit document and created the remaining tickets. all topics now have tickets! :D

!m lucifer

You're doing good work, lucifer!

thank you!

!m lucifer

You're doing good work, lucifer!

+1

i also speant some time on BPM and AB stuff in the start of the last week.

that's it for me. alastairp: next?

I did more genre import stuff, thanks reosarevok for your detailed notes on what changes we should make to map more closely from these different sources to musicbrainz

this is now ready to actually import - I'll speak with zas tomorrow about seeing if we can get some API limits raised in MB to perform the actual import, it'll still take 2-4 days to do anyway

I also open a few LB PRs - fixed an issue with pinning recordings that monkey and I had spoken about the week before, and as a result of that opened a few more PRs to fix some small niggles that I found - improvements to test.sh and the listenbrain-mb release submitter

I helped lucifer get up to speed with the open PR for LB-866, and tested some of the changes that he made

LB-866: Use user ids in the listen table instead of usernames https://tickets.metabrainz.org/browse/LB-866

I opened a few tickets based on the summit notes

I helped someone with a broken spotify import (there was an error during an import so we had stopped), but that raised a few open questions about how we can improve the import and associated tools, so I opened LB-1026 and LB-1028

LB-1026: External service connection page doesn't show a spotify error https://tickets.metabrainz.org/browse/LB-1026

LB-1028: Sometimes spotify import is marked as failing but actually works https://tickets.metabrainz.org/browse/LB-1028

while talking with lucifer about user-ids in listens table, we came up with some thoughts about listens with invalid listen dates: LB-1025

LB-1025: Delete listens with too-old listened_at, and notify users? https://tickets.metabrainz.org/browse/LB-1025

finally, we had some discussions about AB data and how to improve it

monkey: next?