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.
see this is what happens when we upgrade stuff. shoulda never gotten new logoes :P
Gentlecat
anyway, the ticket and PR are there
yvanz
If not perfect, these updated logos seem ready and are real improvement over previous ones. I am all for it.
Freso is indifferent towards monkey's vs. cat's logo texts
CatQuest
i approve of cat, out of principle
zas
New ones look better to me
CatQuest
but yes. i liek the newer ones
Freso
Seems like meeting agreement is for the newer ones. If you want more eyeballs on it, perhaps put it up on the forums?
CatQuest
👍
chirlu
What’s the process? Say again on the PR that the old text is ugly, typographically?
CatQuest
quirky doesnt have ot be ugly. so yea
reosarevok
Definitely the new ones
Freso
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.
Freso
bitmap, Gentlecat ^
bitmap
sorry, reading the comment there
chirlu
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.
bitmap
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
yvanz
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.
bitmap
though I haven't studied the suggestion closely...you may be more of an expert on this code than me at this point
yvanz
I would prefer the flagday change, if it is achievable in practice.
chirlu
I generally like the idea. The sketched data format may not be sufficient, though.
Freso looks up flagday change
yvanz
If I encounter too many special cases, I might go back to the other one.
CatQuest
i think they mean "in one go"
chirlu
Yes. Kernel speak, sorry.
CatQuest
ehe i guessed correctly :D
Freso
CatQuest: Yeah, that's my reading too. Just looking up where it comes from etc.
chirlu is reading too much LWN. ;-)
CatQuest
ir's close to 22 here for me, I'm to tired too :/
Freso wants to read more
is the meeting
Freso
Anyway.
yvanz
chirlu: the sketch is just a sketch, i already found issues in it. :)
Freso
yvanz: Did you get your answers?
yvanz
Freso: well, almost, yes.
CatQuest
!m yvanz
BrainzBot
You're doing good work, yvanz!
yvanz
Do I jump to the second point then?
Freso
Yes, please.
yvanz
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.
CatQuest
always chirlu with links 👍
yvanz
(If this is taking too long, we can just discuss the geo.itunes (linked issue) instead.)
Freso
yvanz: The last topic is not urgent. You have 10 more minutes. :)
reosarevok
yvanz: in general, I don't think cleanups need style approval
yvanz
Then we better have to discuss the more general standardisation issues handling problem.
reosarevok
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
bitmap
can't itunes releases in different regions have different tracklists?
Freso
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.
CatQuest
hmm
yvanz
If I am not wrong, digital releases on iTunes are considered worldwide releases.
Freso
yvanz: Not in MusicBrainz.
reosarevok
bitmap: probably not with the same ID, I'd expect?
Freso
(5 more minutes.)
bitmap
the last comment in the ticket said it may change the item id, which made me wonder
yvanz
Freso: ok, although the country release is a separate field. Changing the URL target doesn't hurt, I guess.
reosarevok
But not sure
Freso
Until we have more data, it's probably safer to not use the geo.itunes URLs.
reosarevok
yvanz: we generally consider the iTunes releases the same in multiple countries, it's just iTunes isn't really worldwide :)
bitmap
as for silent cleanups...we've only done that for really large changesets so far
Freso
I'm also a proponent for generating edits. :)
yvanz
there are 67K itunes urls in MB DB.
bitmap
okay, that's a lot
CatQuest
that's a lot of edits to add to the que
unless they're auto
Freso
CatQuest: They'd be autoedits.
CatQuest
ah
no issue then fro mme
bitmap
but not really bad compared to the wiki ones
CatQuest
from me, ark pressing enter instead of backward
Freso
But I don't think we'll want to convert iTunes links just yet.
chirlu
Yes, it seems to need more research first.
Freso
Let's get more data on how geo.itunes URLs first.
+behave
yvanz
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.
Freso
yvanz: I think that's about right, yeah.
bitmap
well, I wouldn't add any special handling wrt geo links until we know what we're doing with them
Freso
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. :)
CatQuest
to geo or not to geo, that is the question
Freso
yvanz: Good enough for now?
yvanz
As for the silent cleanup of existing URLs? Still a per case thing?
Freso
Yeah.
yvanz
Freso: yes, thanks.
Freso
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.
yvanz
Ultimately, I think it should be done programmatically, but it is really not a priority right now.
Freso
Anyway.
It's 1 minute past.
Thanks for your time!
</BANG>
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | MeB meeting agenda: Reviews, GSoC Final Evaluations!! (Freso), splitting Discourse's MB category (Freso)
