#metabrainz

No strong objections, i think it's sensible.

Returning a 403 makes more sense to me

Not sure if we do that at all yet, but we have talk of it at least

does it depend on wich place they are spamming?

eg listen sapmmers or music spammers or book spammers

CatQuest: all of it is MB based rn, so probably not

(as in, based on MB accounts)

some are listenbrainz

a new account flags sounds sensible to me

I guess if someone is only spamming on one non-MB site but acting normally on MB then we should have a more calm talk, but that seems unlikely :)

Anyway. Seems like there is general agreement on it not being completely far-fetched.

The ticket is open for implementation discussion/questions/comments. :)

Alright, last item!

Will do

:D

so I got an idea: what if we, before the summit, all send some chocolate to barcelona, and then ruaok and monkey all create fair piles to everyone and sent it back to us! (poss together with t-shirts/whatever surprise it was?)

good/bad idea? :​D

bad.

oh :(

I guess "too much effort", mostly :p

a shipping nightmare

aw

We're not going to handle the t-shirt shipping logistics, and that was really helpful last year

I don’t think I’d be able to manage that. :\

I will have no part of that.

ok ok, it was jsut an idea

finish then

If something, then having some sort of "each one gets assigned one other person to send chocolate to" would be more manageable

Although I dunno how easy it is to ship it :)

Might be it all just melts

honestly it's just becasue i want to taste that damn mapelsyrup canadian chocolate again :P

Not sure chocolate travels that well unrefrigerated, to be honest

not here. it will rain away :D

honestly it's usually fine

too hot in many places still to ship chocolate

I think the idea is a no-go. Sorry CatQuest. :\

Which, I think, also (chocolate?) wraps up this meeting!

yea I already got that freso ¬__¬

aw well

[musicbrainz-server] 14reosarevok merged pull request #2268 (03master…MBS-11968): MBS-11968: Allow VIAF, DNB, LoC links for series https://github.com/metabrainz/musicbrainz-serve...

Thank you all for your time. Stay hydrated, don’t eat _too_ much chocolate, and stay safe!

</BANG>

there should be some "we will distribute chocolate to your selected group of people" type service

[musicbrainz-server] 14reosarevok merged pull request #2260 (03master…MBS-11957): MBS-11957: Clean up twitch.com to twitch.tv https://github.com/metabrainz/musicbrainz-serve...

Freso: I think the spammer flag could be complementary with spam reports designed to work with SpamBrainz, I will check that.

Thanks everyone!

It's called a CDN, isn't it? Chocolate Delivery network? :p

:D

Thanks Freso :)

tandy[m]: the sitewide api endpoints changed the format of json returned by them. the sitewide had not been calculated for over a year so we thought no one used it. sorry. i think you'll need to update the client code.

lucifer: thats no problem, i maintain the nim bindings for the listenbrainz api and i dont actually interact with the json, just return it :)

if it gets calculated again it should work right?

bitmap: what do you think about https://github.com/metabrainz/musicbrainz-serve... then? IIRC you weren't too convinced about it making old edits extra borked

Wonder if we have a good way of detecting those and not showing the borked info

Also, can you take a look and see if you feel https://github.com/metabrainz/musicbrainz-serve... and https://github.com/metabrainz/musicbrainz-serve... are ready?

(yvanzo's URL stuff)

tandy[m]: i am not sure what caused the error in your CI. the endpoints should still be working but the data they return might not be up to date or useful.

should this produce any results?

currently, its returning 204 as expected. once we trigger stats generation, it should return actual stats.

reosarevok: well, I'd like to avoid merging something that makes those edits even more broken -- ideally we'd add back the old relationship types and fix the IDs in those older edits

lucifer: oh yep, thatd be why the CI fails, tests raise an exception if the response isn't 200

or for now we can have a list of type IDs that were re-used and avoid loading those if the edit is pre-ngs

makes sense. fwiw, 204 is documented in LB docs if there are currently no stats. for example, a new user might not have stats as soon as they create an account. or say a user didn't listen anything in the last week.

ruaok: one quick question, should i delete the test dump and reuqest a usual dump import? otherwise stats and other stuff won't run tommorrow.

lol https://twitter.com/LeahNeukirchen/status/14424...

Damn I never thought the issue would be this big

I read on hackernews once that there exists some standard that always calls for writing version tags as 0.x.* or something

you probably mean semver

Probably, but what struck me as odd was that they wanted all your versions to start with 0

And not only this, they had a table in the home page showing the open source repos already adhering to the standard

that's in development versions iirc.

I see, they wanted major releases to be tagged such way too, which I found very odd

I see

Lemme look for the link, if I can find it for you

Also people's reaction to it was kind of interesting

you realize that's a parody/joke, right? :)

on the other hand, it's kind of, well, all too realistic; a lot of projects end up getting used and stabilizing while still keeping the 0.x version numbers

At first I thought it was a joke, but then it had a list of repos at their home page. So I thought maybe it's serious?

I didn't know that actually

they're basically calling out projects that have stuck with version numbers starting with 0 for a long time.

The whole site is written in a sarcastic tone, and the original publish date is April 1. it's not something to take seriously.

Lmao I see

and also right on their About page: "ZeroVer is satire, please do not use it."

Yeah i just checked rn lmao

This was embarrassing lmao

[bookbrainz-site] 14dependabot[bot] opened pull request #702 (03master…dependabot/npm_and_yarn/elastic/elasticsearch-7.15.0): chore(deps): bump @elastic/elasticsearch from 5.6.22 to 7.15.0 https://github.com/bookbrainz/bookbrainz-site/p...

[bookbrainz-site] 14dependabot[bot] closed pull request #695 (03master…dependabot/npm_and_yarn/elastic/elasticsearch-7.14.1): chore(deps): bump @elastic/elasticsearch from 5.6.22 to 7.14.1 https://github.com/bookbrainz/bookbrainz-site/p...

[bookbrainz-site] 14dependabot[bot] opened pull request #703 (03master…dependabot/npm_and_yarn/eslint-plugin-react-7.26.0): chore(deps-dev): bump eslint-plugin-react from 7.21.5 to 7.26.0 https://github.com/bookbrainz/bookbrainz-site/p...

[bookbrainz-site] 14dependabot[bot] closed pull request #700 (03master…dependabot/npm_and_yarn/eslint-plugin-react-7.25.3): chore(deps-dev): bump eslint-plugin-react from 7.21.5 to 7.25.3 https://github.com/bookbrainz/bookbrainz-site/p...

bitmap: I guess the easiest way (but maybe overkill) is not load those for any pre-NGS edits?

sure looks like it. :)

lucifer: yes, delete dump and run the usual proces