lucifer: aerozol: Hey I fixed the bug and implemented the new terminology. I have created a PR can you please review it and tell me any further changes to implement if needed :)
jivte_ has quit
jivte_ joined the channel
jivte_ has quit
jasje joined the channel
yvanzo
O’Moin
reosarevok
moin!
yvanzo
lucifer: The logs (of both SIR --debug --sqltimings and PG) of SIR’s current master branch’s HEAD (dc96c30) are on wolf under ~musicbrainz/log-dc96c30-master
Otherwise the raiseload patch didn’t have any impact on the reindexing time.
BrainzGit
[musicbrainz-server] 14reosarevok opened pull request #2761 (03master…MBS-12738): MBS-12738 / MBS-12739: Don't assume "single" and "studio" are ETI unless inside parens https://github.com/metabrainz/musicbrainz-serve...
Finally looking at getting a clear view of what's missing as discussed during the summit with aerozol
yvanzo
reosarevok: renamed and marked as in progress, does it look better?
reosarevok
I'm just not sure what their use is, since we convert and merge stuff page by page :)
yvanzo
These just gather related stuff together.
aerozol
jivte_: sorry, I missed your message this morning and it's evening for me now zzz
Let me know if you need me to look at something @reosarevok, I've had a lazy few weeks lately, got to be honest 😁
reosarevok
Yeah, but since for some reason Jira doesn't allow subtasks of subtasks, the grouping is some half-assed "depends on" linking :(
Anyway, not the end of the world, I'm just pretty sure we'll forget to close them :D
aerozol: nothing urgent, relax as needed:)
santiagofn has quit
trolley has quit
trolley joined the channel
aerozol doesn't move from groove in the couch
ssam joined the channel
ssam has quit
yvanzo: on root/admin/attributes/form.tt - what do you think about making this 3 forms and requesting them based on the model? It feels a bit weird that the whole form content is an IF ELSIF ELSE
yvanzo: also, you converted the wikidoc forms in https://github.com/metabrainz/musicbrainz-serve... but left behind the .tt files - I'm assuming that was not intentional? :) If so and they are not needed, feel free to remove them and commit straight to master (or I can do that)
ssam joined the channel
smach joined the channel
yvanzo
Good catch, removed now.
jivte_ joined the channel
jivte_
aerozol: No worries take rest I just wanted to convey the message that I have worked on the LB-1171 ticket and can you please review the pr I have made for the same
reosarevok: If you mean 3 components instead of 1 template, sure. Maybe even a 4th component to keep some factorization. These already are 3 different forms, see sub edit in Controller::Admin::Attributes.
reosarevok
Yeah, that was my idea :) What do you mean with a 4th? Have a AttributeForm that then picks ScriptForm, LanguageForm and GenericForm?
s/and/or/
yvanzo
something like that, if there is anything to factorize
jivte_ has quit
reosarevok
A little bit, yes :)
Why not
I think MBS-8609 has most stuff listed now - I'm sure I missed some though
akshaaatt: Fixed some very visible bugs and expanded on previous PR.
lucifer
mayhem, alastairp: hi! working on a spotify-reader like implementation of the lfm importer. i want to add a user name and jsonb metadata column to external_service_oauth table. thoughts?
optionally we can get rid of the error message, merge it into jsonb metadata column. the intent of the jsonb column is to store things like total listens imported so far and count of invalid listens discarded because one of the complaints with the frontend importer has been that it oftens drops listens.
jasje has quit
alastairp
hi lucifer
lucifer
hi!
alastairp
any reason why you can't put lastfm username into the jsonb too?
lucifer
hmm, good question. i wanted to store the username for spotify too fwiw so that we could avoid redundant lookups in troi so its common for all services we support and probably deserves its own column
but putting it in jsonb would also work i guess.
alastairp
if there are 2 services that need the same named column then perhaps that's a good argument about making it a separate column
however if the semantics of that column changes depending on what service uses it, I would recommend putting it in the jsonb
lucifer
in the lastfm case, we want the user to be able to change the username manually. in the spotify case, probably not needed?
alastairp
ah true
to me that sounds like service-specific configuration
lucifer: sorry, this week in spain is a bit chaotic, there are public holidays tuesday and thursday, so I'm actually in the mountains on holiday today :)
mayhem: hi! are you around today for misc discussions?
mayhem
Now is good.
Let me grab my lappy.
lucifer
cool, i was thinking about adding a year column to Year in Music table so that we can add this year's YIM while retaining older one.
mayhem
yes, that was my original goal.
lucifer
i think you also had other ideas about archiving YIM's html page directly but i don't remember it now.
mayhem
not sure how possible it is for us to keep it permanently, but I suspect we can keep a year or two before they bitrot too much
lucifer
keep the json data or html pages?
mayhem
that is for when bitrot sets in. we'll just make a static HTML opy.
copy
lucifer
i see, makes sense.
yes storing the data probably wouldn't be an issue, maintaining multiple frontend pages probably will be.
mayhem
exactly that.
but lets burn that bridge when we get to it
lucifer
cool, sounds good.
another thing, i was looking to add support for exporting user's listens data in background process. but that means we need to store the dump somewhere.
can't put it on ftp directly, because needs to be authenticated by the user. thoughts?
mayhem
another docker volume?
lucifer
i see. makes sense
will need to work out some details but let me start implementing with that to get a better idea.
mayhem
and then a cleanup job that deletes the old ones?
lucifer
yup cleanup after a week or so
mayhem nods
i have to go for a bit. but if you around by the time i am back, have metrics writer to discuss.
otherwise some other day is fine.
mayhem
unsure, this week is all a bit here and there for me.
but we'll see.
lucifer
ah cool. no worries. next week it is then
just let me know if there are some other tasks you want me to work on next
mayhem
have you worked through everything on that github thing?
but release support in the mapper is getting to be more important now.
lucifer
mayhem: quite close on the github thing.
ah right, mapper support. adding to github projects lits.
yvanzo: what do you think about only returning MBIDs from solr to MB and then MB adds all the data by DB lookup? intent is to keep fields between WS and search consistent. additionally, it would make it possible to use `inc` params with search. i guess it would probably also shift some load from solr to database so a tradeoff.
yvanzo
lucifer: slowness?
lucifer
yes, indeed. i am not sure about the performance.
yvanzo
I think that is the whole point of Solr.
lucifer
i see. makes sense.
yvanzo
lucifer: My latest sir PR is based on v3.0.1 (branch released-master atm) because it can run it locally, so there is no rush about stabilizing master branch.
lucifer
cool, sounds good.
yvanzo
It isn’t really worth merging until its companion PRs in mb-rngpy, mb-solr, and musicbrainz-server gets merged.
If that happens sooner than expected we can still revert master to v3.0.1, merge it, release, and restore the commits for SQLAlchemy 1.4.
lucifer
could also merge to master, create a new branch off v3.0.1 and cherry pick the commit on that branch. but yes fine either way
yes, either way is fine, we are not stuck for release, that's the most important
jivte_
lucifer: Hey for the LB-1171 ticket the PR which I made is #2274 (Terminology Updated) and one more thing I would like to work on LB-1157 can I work on it?