#metabrainz

This is the week where our students have to submit their Final Evaluations. (Submission time started same time as meeting.) Hopefully all students are all set and all but ready to submit, but just in case you're not, mentors should be aware that there's a hard deadline coming, so please be available for your students!

(Mentors' final evaluations start next week, so I'll ping again then. ;))

So this is just a heads up. I'll keep an eye on submissions during during the week.

Gentlecat: MeB PR #234/MEB-38

some time ago I spotted some issues in new logos (see http://tickets.musicbrainz.org/browse/MEB-38) and decided to fix it myself

:)

I've been pondering this issue for a bit.

now I created a PR with updates for MeB website, but ruaok doesn't think they look good

I personally see nothing wrong with the logos monkey created.

so we want other people to look too and tell us what they thing

they are not *perfect*. they are a little unique. each one a little special.

it's not really *logos*, just text that accompanies them

which is quite fitting for us.

and fixing them makes us look "normal".

Freso

as if we're the type of people to wear suits. our IBM logo is *perfect*.

also note that updated small versions are already used on https://musicbrainz.org/ and https://critiquebrainz.org/

CatQuest

yeah, fair point

but CAA logo for example is just incorrect

Gentlecat: thanks for asking before doing that. I'd really like you to undo that until this discussion settles out.

the kerning on the new is is really bothersome.

ruaok: He did ask before doing that, AFAIR.

ah.

next time I would like to be consulted on this, please.

ruaok: ... You were.

You told him to go ahead.

you told me we can do changes afterwards and that I can fix it myself, iirc

i actually remember that. it's true

yes, you can.

but the PR hasn't merged yet, but you deployed the logos.

This fresh diff helps to review https://github.com/metabrainz/metabrainz.org/pu... :)

which is counter to our workflow.

wait what?!

As I said on the ticket already, the current logo text is ugly, so I’m all for the update.

what did I deploy?

> also note that updated small versions are already used on https://musicbrainz.org/ and https://critiquebrainz.org/

ruaok: You gave the go for those.

....

k.

see this is what happens when we upgrade stuff. shoulda never gotten new logoes :P

anyway, the ticket and PR are there

If not perfect, these updated logos seem ready and are real improvement over previous ones. I am all for it.

i approve of cat, out of principle

New ones look better to me

but yes. i liek the newer ones

Seems like meeting agreement is for the newer ones. If you want more eyeballs on it, perhaps put it up on the forums?

👍

What’s the process? Say again on the PR that the old text is ugly, typographically?

quirky doesnt have ot be ugly. so yea

Definitely the new ones

I think this topic is done. :) Comment on PR and Gentlecat or ruaok can open a topic on forums if they want non-IRC'ers to look at it too - otherwise agreement seems to favour Gentlecat's new ones by far.

First, thanks to people currently working on docker containers and hosting issues. I could not help with this, so I just started to work on a small subset of well delimited issues instead. I have been patching tiny bits of the URL Cleanup component of MusicBrainz Server for weeks. (There will always be such tiny issues for this component as external sites continuously change.) I would like to keep

improving the code around as I get more used to this part. (Lengthy introduction done.) One of the stoppers is the lack of validation tests. http://tickets.musicbrainz.org/browse/MBS-6378 Is this development workflow appropriate so far? For this issue specifically, I proposed two ones: gradual migration or one go.

bitmap, Gentlecat ^

sorry, reading the comment there

Advantage of a flagday change: No duplication between old and new code.

Disadvantage: Difficult to see in the history when a certain test was actually added/changed last.

I'm fine with converting them all at once if you're willing to put in the work

I guess we can't avoid losing history if the current structure is insufficient

Maybe it is even more clear (for history) to have only one migration commit at one time, rather than many disparate ones over the time.

though I haven't studied the suggestion closely...you may be more of an expert on this code than me at this point

I would prefer the flagday change, if it is achievable in practice.

I generally like the idea. The sketched data format may not be sufficient, though.

If I encounter too many special cases, I might go back to the other one.

i think they mean "in one go"

Yes. Kernel speak, sorry.

ehe i guessed correctly :D

CatQuest: Yeah, that's my reading too. Just looking up where it comes from etc.

ir's close to 22 here for me, I'm to tired too :/

is the meeting

Anyway.

chirlu: the sketch is just a sketch, i already found issues in it. :)

yvanz: Did you get your answers?

Freso: well, almost, yes.

!m yvanz

You're doing good work, yvanz!

Do I jump to the second point then?

Yes, please.

There are many issues with URLs standardisation, on a regular basis. I took http://tickets.musicbrainz.org/browse/MBS-9044 as an example only, although we can also discuss this one now. Should it be discussed in STYLE beforehand? Could it be handled more systematically like recent ones (WP/Discogs): DB update with small batches?

Thanks chirlu :) WP's search wasn't being cooperative.

always chirlu with links 👍

(If this is taking too long, we can just discuss the geo.itunes (linked issue) instead.)

yvanz: The last topic is not urgent. You have 10 more minutes. :)

yvanz: in general, I don't think cleanups need style approval

Then we better have to discuss the more general standardisation issues handling problem.

Unless they involve outright blocking stuff from being linked, which I guess should be discussed

But if it just changes the URL, no problems IMO

can't itunes releases in different regions have different tracklists?

I guess the main thing is the discussion about whether to execute clean-ups silently or by generating edits. And if the latter, do them all at once or in increments.

hmm

If I am not wrong, digital releases on iTunes are considered worldwide releases.

yvanz: Not in MusicBrainz.

bitmap: probably not with the same ID, I'd expect?

(5 more minutes.)

the last comment in the ticket said it may change the item id, which made me wonder

Freso: ok, although the country release is a separate field. Changing the URL target doesn't hurt, I guess.

But not sure

Until we have more data, it's probably safer to not use the geo.itunes URLs.

yvanz: we generally consider the iTunes releases the same in multiple countries, it's just iTunes isn't really worldwide :)

as for silent cleanups...we've only done that for really large changesets so far

I'm also a proponent for generating edits. :)

there are 67K itunes urls in MB DB.

okay, that's a lot

that's a lot of edits to add to the que

unless they're auto

CatQuest: They'd be autoedits.

ah

no issue then fro mme

but not really bad compared to the wiki ones

from me, ark pressing enter instead of backward

But I don't think we'll want to convert iTunes links just yet.

Yes, it seems to need more research first.

Let's get more data on how geo.itunes URLs first.

+behave

To conclude with: no style ticket for URL-related issues, no change to geo.itunes (no standardisation to "no geo if it is already there" either?).

Freso: we can go forth and back with this "geo." prefix change.

yvanz: I think that's about right, yeah.

well, I wouldn't add any special handling wrt geo links until we know what we're doing with them

yvanz: Let's get more research done (e.g., on albums changing id) and then we can make a decision for geo.itunes or not-geo.itunes.

What bitmap said. :)

to geo or not to geo, that is the question

yvanz: Good enough for now?

As for the silent cleanup of existing URLs? Still a per case thing?

Yeah.

Freso: yes, thanks.

We've discussed such cases at the meeting previously.

Arguing about whether to deal with them one way or another.

So I'd say bringing individual cases here is the way to go.

Or at least make an MBS ticket about them.

Ultimately, I think it should be done programmatically, but it is really not a priority right now.

Anyway.

It's 1 minute past.

Thanks for your time!

</BANG>

but.. what about those

?