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.
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. "
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?
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>
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.
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.