#metabrainz

removed redundant code

did some optimizations along the way

learned the importance of planning out

Got an indea of my development speed. Currently planning rest of my week for optimal outputs

fin

Alright!

That’s all for reviews then. Thank you all for yours. :)

Thanks for having us :))

And ansh, Shubh, and Pratha-fish, if you wish to be regular on the meetings going forward, please add yourselves to https://wiki.musicbrainz.org/User:Freso/MetaBra... :)

also skelly37 ^^

We have a couple of items on the agenda from last week due to mayhem and alastairp both being out, so let’s get on with it.

Apologies for being late

Oh, only one topic.

Is there some time left for me?

k, well, iirc our Jira license runs out at the end of the year and we will no longer get any more updated.

updates.

so, we need to start thinking about what we're going to migrate to.

skelly37: You can give review after this item. :)

Jira online? eeek, with atlassian's outage that isn't good. And we'd likely lose our single sign on functionality.

It was expected to last until Feb 2024. Has it changed?

If not jira, what else?

yvanzo: oh, did they extend it? well, if they did, that is great.

this is OTHER-373, comments can go there too

OTHER-373: Migrate Tickets from Jira Server https://tickets.metabrainz.org/browse/OTHER-373

No, they didn’t extend it, it was supposed to be renewable until Feb 2024.

I still prefer sticking to jira unless it's a really really bad idea and/or migrating is really easy

reosarevok: the problem with post-2024 is that we can't self-host it any more

same

wat

alastairp: sure, I get that

still, the question stands. what are we migrating to. so in the interest of time I would like us to start thinking about it now. given that migrating away could be a major time sink for us.

which has user privacy/data issues

that doesnt make anysense at all

mayhem: right

reosarevok: sure, just making sure you were aware

so, I have nothing more concrete to say right now.

Jira Cloud is still an option in my opinion, until we find a big issue.

I've not used any other self-hosted bug trackers since MB used trac

let us all think about this, knowing that there is a deadline off in the distance.

not sure what the situation is like these days

Maybe even the SSO can be preserved.

privacy issues remain, however.

Alright, that sounds like this item wrapped up?

yeah

If so, let’s go back to reviews for skelly37 before un-banging. :)

skelly37: Go!

skelly37: Ping?

Hello everyone :) Basically I've finished and received good reviews for my pipe logic

Freso: can I give my last week's review as well? couldnt resist

So now I'm writing tests

I have a few things to think over but all the issues are named as TODOs and the project goes smoothly for now

I think that's all

yellowhatpro

Thanks everyone!

yellowhatpro:

Go.

Hello everyone!!

So last week I got my hands dirty with brainz player integration, read documentations and sample codes for the media player libraries.

Worked on the music service + notification required for the playback.

Updated the cb integration pr as well

Thanks Freso

(Oops. Too soon!)

Thanks yellowhatpro :)

yellowhatpro: That’s fin? :)

Yeah that's it for now

Alright!

mayhem: I confirm that SSO would still work with Jira Cloud. (The add-on we are currently using is available on Jira Cloud too.)

But the privacy issues remain.

That’s that for today’s meeting then. Thank you all for your time! Remember to stay hydrated, wear sunscreen, and wear your mask!

</BANG>

I wonder if there are many tools (open source preferably) around that can match most of the features of Jira, so we don't lose too much if we migrate. Also the existence of tools to actually import from Jira would be a good thing... Perhaps we should start to list "must-have" features, it would help to restrict options.

at this point we could just concede we should mke ticketbrainz...

FishQuest: https://blueseatblogs.com/wp-content/uploads/20...

:)

zas: yes, knowing what features we use is a good idea. for example, I know that in CB and LB I believe that we don't use very many advanced workflow features, I suspect that something almost as simple as GH issues would be OK for this, but for other projects maybe not

zas: https://test.acousticbrainz.org/ is working with nginx-proxy. I'm currently testing `pg_dump | ssh flobot psql` as a method of dumping the database, it works but I need to benchmark transfer time.

[listenbrainz-server] 14amCap1712 merged pull request #2021 (03master…mapping-check-again): Add check_again column for MBID mapping writer https://github.com/metabrainz/listenbrainz-serv...

yvanzo: I'll wait for that review, then release, I think :)

reosarevok: I don’t really see why instrumental and karaoke would have to be exclusive to each other.

Because the way we define instrumental for the attribute since the beginning is "lyrics are not relevant for this recording"

It seems that the recordings that would be listed by this report are missing a “karaoke” performance relationship to the work, but the “instrumental” performance relationship doesn’t necessarily have to be deleted.

reosarevok: Indeed, the way it is defined in MusicBrainz seems to be problematic.

The whole point was to have a way to indicate to data users "you can ignore lyrics-related stuff for this recording"

karaoke is something that usually has lyrics but here we havea version witotuh while insturmntal never had lyrics

The only reason we added karaoke separately for recording-work was to have a separate option for karaoke :)

karaoke always is a version of something that has lyrics

So that when the lyrics *are* wanted but it's instrumental, we can use it

FishQuest: "instrumental" as a recording-work attribute is also only for stuff with lyrics, really

(otherwise there's no use for it, since it's instrumental by definition)

hmm

The difference is "karaoke" -> the recording is instrumental, but we care about lyrics data, "instrumental" -> the recording is instrumental and we do *not* care about lyrics data

yes

So they're explicitly meant to be mutually exclusive by design :)

yea

(both of these are only meant to be used with works that have lyrics to begin with, since if not they're already [no lyrics])

If you were to allow both at the same time, you could have “instrumental”-only to still be what it currently is, “karaoke”-only to be karaoke recordings that have some vocals but still allows you to sing on top of it, and “karaoke”+“instrumental” to have no vocals and allow you to sing on top of it. It would require to adjust the definitions.

Maybe so, but nobody who deals with karaoke has ever asked for the distinction, really :)

So it seems like a lot of effort for no big gain. If that changes, we could consider it

yea that doesnt make sense to me

The benefit is not this distinction, it is to have a definition of “instrumental” that is closer to the common meaning: no vocals.

But then we'd also expect to set it for every [no lyrics] work :)

except that karaoke *can *have some lyrics, but it doesnt make sense for karaoke to separate *completely no lyrics*and *some lyrics*

I mean, we could rename the attribute if you have a better idea, tbh

I just don't, but I feel it's useful to have a "ignore lyrics" attribute :)

+1

(or well, other people who asked for it feel it's useful :D I don't care too much myself, but I can see the usefulness)

I totally understand the "the name as written is a bit confusing" angle though :) It's similar with "recording" which is not literally a 1:1 map with things that are recorded

It's just I don't have a better name

Is there any issue with the proposed solution?

You'd have to ask the karaoke people :)

If you want to start a discussion about it and get opinions, we can postpone merging this

It's not really urgent anyway, so :)

Indexed search doesn’t allow to filter by relationship attribute, that would not cause a regression here at least.

The main issue I can see from my side is that if someone is currently operating under the assumption (with their app or whatever) that instrumental -> automatically ignore lyrics, we would break that by having some which have instrumental but should not get lyrics ignored

Yes

But not sure if there's an issue from the actual understanding / style POW, not without asking the people who use instrumental and karaoke often :)

I know *I* don't want a conflation of the two

reosarevok: Made a comment, let’s postpone merging it.

Ok

I'll release then

lucifer: https://twitter.com/thingskatedid/status/153602...

Updating beta

alastairp: hehe lol 🤣

alastairp: mayhem: fyi, my laptop is having display issues again. while waiting for the display to be replaced (probably this entire week), i am on a spare machine. don't have ssh keys on this one so currently don't have access to MeB infra.

if needed, i can create a new key and someone can add it to servers till the situation is resolved.

lucifer: ok, ping me if you need me to do anything for you

thanks, will do!

Ok, I'm around so should be ok.

[listenbrainz-server] 14chinmaykunkikar opened pull request #2039 (03master…listens-page-updates): Add useful messages and call to actions for empty states on listens page https://github.com/metabrainz/listenbrainz-serv...