#metabrainz

/

      • dgw has quit
      • dgw joined the channel
      • ElimGarak joined the channel
      • dgw has quit
      • ElimGarak is now known as dgw
      • MRiddickW has quit
      • MRiddickW joined the channel
      • Shubh joined the channel
      • gcrkrause3 has quit
      • gcrkrause3 joined the channel
      • KassOtsimine
        reosarevok> aerozol: I'll put a patch up for now because it's better than the broken beta state
      • what broken beta state???
      • maybe this is weird but, i've been using adblocks/stylesgeets to block and remove gravatars for so long that i don't see a change on mb now
      • lucifer
        mayhem: pondering on what to do about min/max ts listen delete case. we'll need to scan the listens for that user to recalculate that user's min/max ts again. i am unsure whether we should do that scan right away or wait for the cron job and do it there.
      • i am leaning towards the latter mostly because i worry doing the scan right away may cause the delete request to timeout.
      • dgw has quit
      • dgw joined the channel
      • mayhem
        mooooin!
      • lucifer
        morning!
      • mayhem
        lucifer: I dont think we need to do a full scan -- we have old bounds -- simply do a query that fetches 1 listen that is the next nearest listen inside of the given range.
      • that could, on rare occasions, still take a long time. which is troublesome.
      • if we delay fixing the data until the next pass of the cron job, how does the cron job know to fix this entry?
      • lucifer
        yeah, it still is a scan on entire listens of the user but maybe ts can optimize this. will need to check.
      • dgw has quit
      • we'll probably need another column for that.
      • dgw joined the channel
      • aerozol
        KassOtsimine: re. broken beta page, do you see a weird icon here? https://beta.musicbrainz.org/edit/86645383
      • mayhem
        lucifer: In thinking about how to tackle this, I've come up with a reason why this is important: pagination of listens. if the limits are not right, then the pagers will be wrong at begin or end.
      • #nothelping
      • aerozol has quit
      • lucifer
        yes, right.
      • let's do the right away thing for now then and rethink if we see timeouts?
      • mayhem
        yes, but I'm still not very happy with that. let me ponder a bit more.
      • lucifer
        one way i was thinking is to make deletes more like inserts. the delete requests adds a message for a service to pickup and delete it asap. the request itself returns after putting the message. we could also add a tab for listens which a user requested to be deleted but haven't been deleted yet so that user knows the status. this way we delete it asap but get to avoid timeouts.
      • mayhem
        good thinking, but I dislike the many added levels of complexity.
      • along those lines, we could mark listens as deleted by.... zeroing out one more fields or somesuch.
      • and setting the listen data to "[deleted]", but not actually delete it yet. return from the delete command as soon as the listen has been marked for deletion
      • then when the cronjob runs, it cleans up deleted listens for real, while grooming timestamps.
      • KassOtsimine
        aerozol: weird icon? howso?
      • i don't really see any icon :D
      • lucifer
        that's possible but still leaves timestamps invalid till the cronjob runs.
      • KassOtsimine
        oh
      • the little (-) badge? yea i usually jsut block those and have a background colour diff for votes instead
      • monkey
        Regarding pagination of listens, I think that won't be a huge issue. The old bounds will still be an accurate way to navigate to oldest and newest. What might happen is that the "next" button will still be clickable despite being at the last page.
      • mayhem and lucifer ^
      • mayhem
        lucifer: dont touch the timestamps in the delete process.
      • lucifer
        we could keep deleting listens in requests and modify the listen_user_metadata table to help implement fixing timestamps thing.
      • KassOtsimine
        man where this aerozol go
      • way anyway
      • KassOtsimine heads out
      • mayhem
        monkey: yes, and then we get loads of emails about it. no likey.
      • monkey
        Bit of an edge case I guess
      • mayhem
        yeah. and this is the ... 5th time we're "fixing" this? can we please fix it right this time?
      • monkey
        Fair enough
      • lucifer
        re "dont touch the timestamps in the delete process.", right that's what i meant that if we don't touch the timestamp during delete then those remain invalid till the cronjob runs.
      • mayhem
        I disagree. they remain valid, because the listen is still there.
      • the listen only gets tossed for reals when cron runs.
      • lucifer
        oh ok, i see.
      • sgtm, thanks!
      • will update the timestamps PR accordingly.
      • mayhem
        and I would not even make any attempts at hiding that listen when loading listens. let it show up in the users listens.
      • lucifer
        right that makes sense.
      • mayhem
        and I would add a note to the "delete successful" message that says that we will clean it up within the hour.
      • lucifer
        +1
      • mayhem
        I think we need to plan a small celebration when this PR merges.
      • or better when the bug reports for listen count stop trailing in, I guess.
      • lucifer
        indeed 😆 . also the listen counts part is ready i think, we can deploy that now and migrate timestamps to the table (the table already has relevant columns for those) once that part is done.
      • mayhem
        and also deploy the cron script?
      • also, which PRs are blocking you the most?
      • I should have PR time this afternoon.
      • lucifer
        yes the cron script is ready and part of the PR.
      • mayhem
        ok, I'm curious to see how well it does.
      • " On January 31, 2022, the grace period ends for free commercial use of Docker Desktop in larger enterprises. Companies with more than 250 employees OR more than $10 million USD in annual revenue now require a paid subscription to use Docker Desktop. Read the blog or visit our FAQ to learn more about these updates. "
      • BrainzGit
        [listenbrainz-server] 14amCap1712 merged pull request #1828 (03master…fix-typo-pin-rec): Fix typo in updating pinned recs from msid metadata https://github.com/metabrainz/listenbrainz-serv...
      • mayhem
        I'm actually pretty happy to see more companies using the sliding scale model for support.
      • it works well for us.
      • lucifer
        no particular PRs blocking me currently but there are a few ready for review.
      • mayhem
        but, how does that scale up? I wonder if companies need to have a section on their web pages where they list what projects they support. so then companies can choose which parts of their OSS ecosystem are most important to them and then show that off for transparency.
      • lucifer
        this one is ready except adding more tests for API.
      • mayhem
        lucifer: if not blocking, any preferences on what I should look for first?
      • heh.
      • lucifer
      • mayhem
        oh gawd, yes, lets please close this PR. I've read it so many times!
      • ah no, not this one. another one I read many time.s
      • lucifer
      • only a couple of tests need updating.
      • re the listen count PR, its blocked by the listen user id PR. both of those are on alastairp's list to review.
      • "I'm actually pretty happy to see more companies using the sliding scale model for support." oh yeah, docker's pricing model seems nice.
      • "I wonder if companies need to have a section on their web pages where they list what projects they support." do you mean like we have a supporters page or a page supporters should on what companies they are supporting?
      • mayhem
        the latter.
      • this way people can inspect the listen of OSS orgs supported and apply pressure if they are not doing enough.
      • to feed the understanding of a moral obligation for using OSS>
      • lucifer
        oh yeah that would be a good idea.
      • mayhem
        yeah, that shit needs to stop.
      • lucifer
        i am subscribed to ~10 oss project mailing lists and have seen many such email from enterprises sent to project maintainers.
      • most companies don't know how to deal with oss 😞.
      • mayhem
        I think if they put enough $$$ on the table AND they pay for flights, hotels, etc THEN they can ask.
      • lucifer
        indeed if that were the case, it'd be fine.
      • mayhem: also when you have time, can you add description for https://github.com/metabrainz/listenbrainz-serv...
      • my guess is that this container has something to do with floating ip stuff but not sure and don't know all details.
      • mayhem
        done
      • lucifer
        thanks!
      • mayhem, alastairp: while applying feedback on the docs PR. i felt the list form to be a bit unreadable. does this format look better to you or should i let it be the list format?
      • *table format
      • mayhem
        this looks ok to me
      • lucifer
        👍 i'll make the remaining items in this form then.
      • mayhem
        uhm, if bono crashes and burns due to OOM, that would be my fault.
      • reosarevok: ^^ does that look about right for what our "friends" are asking for?
      • yields 1.25 rows.
      • monkey
        Table format is definitely better
      • lucifer
        monkey: +1
      • BrainzGit
        [listenbrainz-server] 14amCap1712 merged pull request #1804 (03master…yim-repeat): Make Year In Music runnable for past years https://github.com/metabrainz/listenbrainz-serv...
      • lucifer
        monkey, is it fine to disable frontend tests on draft PRs in CI i.e. test won't until PR is marked as ready for review?
      • i am doing the same for python tests.
      • monkey
        I think that's acceptable.
      • lucifer
        👍
      • monkey
        I think it would be interesting to have the linting step run separately, keep it on even for draft PRs, and set it up to create annotations straight in the PR. But that's for another day
      • I recently reworked the linting action for BB, so I'll see if it's transferrable.
      • lucifer
        i think i had setup the annotations thing sometime ago but maybe it broke down. using BB one sounds fine.
      • monkey, also when you have time, https://github.com/metabrainz/listenbrainz-serv... is ready for review. the failing test is because of the force_calculate thing.
      • Clint has quit
      • monkey
        Thanks, will review later this week
      • lucifer
        👍 thanks
      • MRiddickW has quit
      • reosarevok
        mayhem: sorry. was driving
      • I see you sent the data?
      • mayhem
        yeah, curious to see them choke on a giant file. as they wanted.
      • also vaguely curious if this query would complete in reasonable amounts of time.
      • turns out an idle machine with 64gb of ram will make short work of it.
      • wait, you were driving, reosarevok?
      • you, behind the wheel driving?
      • reosarevok
        Yes, we have a thing where you can drive after x hours of learning if you have an experienced driver with you
      • So I drove to the countryside
      • mayhem fears for estonia and the countryside
      • mayhem
        lol @support
      • MRiddickW joined the channel
      • reosarevok
        mayhem: what part
      • mayhem
        "you'll never hear from me again"
      • Clint joined the channel
      • reosarevok
        yvanzo, bitmap: are we ever using prove -lv t/author/eol.t ?
      • It has an error, but it's on some txt file I don't get
      • BrainzGit
        [listenbrainz-server] 14amCap1712 merged pull request #1829 (03master…draft-ci): Do not run CI on draft PRs https://github.com/metabrainz/listenbrainz-serv...
      • reosarevok
        I guess it has a Windows line ending somehow
      • bitmap
        reosarevok: don't think so, it's not in the circleci config. but it looks useful to add
      • reosarevok
        I'm confused becaus the test says return unless $_ =~ /(.tt|.pm|.t)$/;