#metabrainz

yes, in addition to any trivial schema changes, we'd like to bump the versions of node.js and perl required

:O@

I've wanted those many times, they will make life easier.

reosarevok: i want both of those

I'd love to work on that one

but there was a reason for NOT using them when we designed the schema in 2008. and I don't recall what it was. nor are any of the people around who would know.

CatQuest: I know, but we have one month to write all the code and one to test, so that might need to wait for the next one

ruaok: I suspect the reason is that the ACs are a) not super stable and b) a lot

lol why did we not have this conversation in january!

ruaok: off the top of my head it feels like it might be something that changes quite a bit

oh, that's basically what reosarevok said

hm

ruaok: would be very helpful to restore the rationale behind that.

one reason I see is that we currently assume ACs are immutable, i.e. can be cached forever

then this change is now fine?

wait but they have some kind of rowid right? you can link to "edit a n artistcredit"

if we add mbids that would seem to imply you could edit them while keeping the mbid constant

hm

CatQuest: yes, they have a row id :)

bitmap: yes, I would expect if I edit an AC with Edit AC, the MBID wouldn't change

But I guess nowadays it would?

who uses "edit AC" amiright?

Hopefully someone, now that I made it so you can actually see what it changes :D

lol

well, the row ID would change for sure. we use a `find_or_insert` method to swap them (and then deleted any unused ones)

I don't think we ever actually UPDATE rows in the artist_credit_name table outside of upgrade scripts

So that find_or_insert would need to either keep gid, or if merging, add a redirect?

Sounds doable, but

yeah

it might also complicate keeping some materialized tables up to date, but

It seems that point should be more discussed/detailed?

yeah, outside of this meeting, methinks.

right

None of these seem super problematic, so if they would also be useful for LB I'd say let's try it...

ruaok: can we tentatively announce but say we might decide not to do it after further consideration?

I guess the main issue is unexpected new changes, not not doing some

(re: announcing early)

lets talk about it tomorrow and then announce the changes after the meeting.

or close the meeting and talk about it now.

fine by me if I can get a 5 mins break.

We should quickly talk about min perl version

I think?

we can probably do that after the meeting

+1

Ok :) In that case, anything in that list that seems like a bad idea that needs to be decided in the meeting?

agreed.

If not I guess we're done(ish)

So no decisive decision on the AC MBID, but other than that everything on that list?

Oh, and other than the two reosarevok already noted.

so reos snippet? becasue i'm aaaall for per medium artwork <3

aw

Freso: Probably, but I guess we'll discuss a bit more after the meeting :)

Some need tickets made still too so :)

Freso: only finished/merged stuff for now, the rest is proposed but to be decided.

Alright.

But it sounds like that’s all for now?

I think so

And no further items on the agenda.

And no okno_ that’s showed up that I’ve noticed.

So I think this wraps up the meeting!

Thank you for your time everyone! Stay safe out there!

i bet okno_ is on a dst thing

</BANG>

thanks freso

thank you Freso

threso

(and everyone else!)

you all do amazing work

Thanks Freso :)

Thanks!

Thanks everyone

[musicbrainz-server] reosarevok opened pull request #1986 (master…MBS-11448): MBS-11448: Pass Place->new() call through to_json_object https://github.com/metabrainz/musicbrainz-serve...

bitmap, yvanzo ^

Also, ruaok, bitmap, yvanzo: ok, schema change stuff then

So, what are the reasons we found *not* to give mbids to ACs?

churn.

but having AC IDs would make a lot of recommendation work easier.

tracking arrays of artist ids is not fun.

with the materialized artist RG tables I'm adding, we'll need additional triggers on the artist_credit tables to handle updates to them

so it does complicate things there slightly, but I think the benefits might outweigh the costs

would it make sense to perhaps have it as an undocumented feature for a while? in case we realize that it was a bad idea, we can undo it.

reosarevok: I don’t the reason back in 2008 ruaok mentioned, but ACs are quite volatile.

yvanzo: can you characterize that volatility?

because of constantly new collaborations?

because of frequent typos

I guess the fact that changing one tiny thing in the name throws out the old AC and replaces it with a new one

ok. makes sense.

not a dealbreaker for me.

ok, can anyone find a reason why we should not do this?

bitmap: When one renames an artist, it does not create a new MBID. Can we have the same for AC?

yes, that would be similar to the 'Edit artist credit' feature on artist /edit pages

it should be possible since ACs are refs to artists. keep the refs, update the text, but not its ID

(though that technically replaces the old AC with a new one)

I would be in favor of that.

besides remembering the invalidate the cache in that case, I don't think it should hurt

bitmap: can you add a ticket with all the things to remember? I think you have the clearest idea

That was possibly the reason it was not made in 2008. I don’t see any other for now.

but we'll want to review all triggers that watch for AC changes

any current trigger would expects the AC to materially change only if the 'artist_credit' column for the entity changes

do you need me for anything else?

should we discuss the perl version bump real quick?

debian oldstable has 5.25, stable has 5.28

ok

sure. not that I am up on perl, but hey.

sorry 5.24 for oldstable

we currently on 5.18

can we safely bump that to 5.28? or should we stick with 5.24 from oldstable?

5.28 is still pretty old, right? It doesn't seem like a huge ask

Assuming it doesn't break stuff we do too much and make us fix it :p

5.28 is from 2018

5.24 from 2016 iirc

currently required node.js 10.15 is 2018 at least

yeah, though that's EOL this april

I mean: that seems ok to require perl from 2018 if we already require node from 2018.

idk if there is a perl equivalent of the nodesource repos though

if people are stuck on old versions of debian/ubuntu, it may not be as easy

Why would someone be stuck that far behind?

most people these days use musicbrainz-docker to install their own copy of MB.

I strongly discourage people from trying their own setup.

if they still do and on an old OS.... not much love for that cause

IMHO you can go to something more recent.

why not the most recent?

bitmap: in fact 5.28.2 is 2019

I guess we could tentatively go with the most recent and see who complains?

I have been, very much so. now that is has excellent support from yvanzo, it is insane not to use it.

and see what tests break, I guess.

yvanzo: right, the .0 was 2018

and xenial (our current base image) has 5.22.1

I've already been using .32 locally, so probably nothing will break even

but we've been pretty conservative about using experimental features and whatnot

I don’t have any strong take about it: as long as latest versions are not less stable.

good point. second to last version, perhaps?

bitmap: You know better the level of stability that can be expected from perl versions :)

they are usually excellent with stability in my experience

I’m using .32 too.