reosarevok> aerozol: I'll put a patch up for now because it's better than the broken beta state
2022-01-26 02615, 2022
KassOtsimine
what broken beta state???
2022-01-26 02603, 2022
KassOtsimine
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
2022-01-26 02643, 2022
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.
2022-01-26 02627, 2022
lucifer
i am leaning towards the latter mostly because i worry doing the scan right away may cause the delete request to timeout.
2022-01-26 02637, 2022
dgw has quit
2022-01-26 02655, 2022
dgw joined the channel
2022-01-26 02624, 2022
mayhem
mooooin!
2022-01-26 02644, 2022
lucifer
morning!
2022-01-26 02645, 2022
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.
2022-01-26 02613, 2022
mayhem
that could, on rare occasions, still take a long time. which is troublesome.
2022-01-26 02649, 2022
mayhem
if we delay fixing the data until the next pass of the cron job, how does the cron job know to fix this entry?
2022-01-26 02604, 2022
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.
2022-01-26 02647, 2022
mayhem
#nothelping
2022-01-26 02618, 2022
aerozol has quit
2022-01-26 02625, 2022
lucifer
yes, right.
2022-01-26 02641, 2022
lucifer
let's do the right away thing for now then and rethink if we see timeouts?
2022-01-26 02653, 2022
mayhem
yes, but I'm still not very happy with that. let me ponder a bit more.
2022-01-26 02605, 2022
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.
2022-01-26 02620, 2022
mayhem
good thinking, but I dislike the many added levels of complexity.
2022-01-26 02652, 2022
mayhem
along those lines, we could mark listens as deleted by.... zeroing out one more fields or somesuch.
2022-01-26 02632, 2022
mayhem
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
2022-01-26 02602, 2022
mayhem
then when the cronjob runs, it cleans up deleted listens for real, while grooming timestamps.
2022-01-26 02648, 2022
KassOtsimine
aerozol: weird icon? howso?
2022-01-26 02653, 2022
KassOtsimine
i don't really see any icon :D
2022-01-26 02656, 2022
lucifer
that's possible but still leaves timestamps invalid till the cronjob runs.
2022-01-26 02624, 2022
KassOtsimine
oh
2022-01-26 02653, 2022
KassOtsimine
the little (-) badge? yea i usually jsut block those and have a background colour diff for votes instead
2022-01-26 02602, 2022
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.
2022-01-26 02613, 2022
monkey
mayhem and lucifer ^
2022-01-26 02618, 2022
mayhem
lucifer: dont touch the timestamps in the delete process.
2022-01-26 02622, 2022
lucifer
we could keep deleting listens in requests and modify the listen_user_metadata table to help implement fixing timestamps thing.
2022-01-26 02622, 2022
KassOtsimine
man where this aerozol go
2022-01-26 02625, 2022
KassOtsimine
way anyway
2022-01-26 02630, 2022
KassOtsimine heads out
2022-01-26 02642, 2022
mayhem
monkey: yes, and then we get loads of emails about it. no likey.
2022-01-26 02658, 2022
monkey
Bit of an edge case I guess
2022-01-26 02622, 2022
mayhem
yeah. and this is the ... 5th time we're "fixing" this? can we please fix it right this time?
2022-01-26 02656, 2022
monkey
Fair enough
2022-01-26 02650, 2022
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.
2022-01-26 02625, 2022
mayhem
I disagree. they remain valid, because the listen is still there.
2022-01-26 02635, 2022
mayhem
the listen only gets tossed for reals when cron runs.
2022-01-26 02651, 2022
lucifer
oh ok, i see.
2022-01-26 02627, 2022
lucifer
sgtm, thanks!
2022-01-26 02652, 2022
lucifer
will update the timestamps PR accordingly.
2022-01-26 02605, 2022
mayhem
and I would not even make any attempts at hiding that listen when loading listens. let it show up in the users listens.
2022-01-26 02631, 2022
lucifer
right that makes sense.
2022-01-26 02640, 2022
mayhem
and I would add a note to the "delete successful" message that says that we will clean it up within the hour.
2022-01-26 02633, 2022
lucifer
+1
2022-01-26 02620, 2022
mayhem
I think we need to plan a small celebration when this PR merges.
2022-01-26 02636, 2022
mayhem
or better when the bug reports for listen count stop trailing in, I guess.
2022-01-26 02640, 2022
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.
2022-01-26 02612, 2022
mayhem
and also deploy the cron script?
2022-01-26 02610, 2022
mayhem
also, which PRs are blocking you the most?
2022-01-26 02616, 2022
mayhem
I should have PR time this afternoon.
2022-01-26 02602, 2022
lucifer
yes the cron script is ready and part of the PR.
2022-01-26 02616, 2022
mayhem
ok, I'm curious to see how well it does.
2022-01-26 02635, 2022
mayhem
" 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.
2022-01-26 02640, 2022
lucifer
this one is ready except adding more tests for API.
2022-01-26 02645, 2022
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.
2022-01-26 02602, 2022
lucifer
"I'm actually pretty happy to see more companies using the sliding scale model for support." oh yeah, docker's pricing model seems nice.
2022-01-26 02614, 2022
lucifer
"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?
2022-01-26 02634, 2022
mayhem
the latter.
2022-01-26 02653, 2022
mayhem
this way people can inspect the listen of OSS orgs supported and apply pressure if they are not doing enough.
2022-01-26 02618, 2022
mayhem
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?
2022-01-26 02616, 2022
lucifer
*table format
2022-01-26 02643, 2022
mayhem
this looks ok to me
2022-01-26 02626, 2022
lucifer
š i'll make the remaining items in this form then.
2022-01-26 02658, 2022
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?
2022-01-26 02653, 2022
lucifer
i am doing the same for python tests.
2022-01-26 02604, 2022
monkey
I think that's acceptable.
2022-01-26 02616, 2022
lucifer
š
2022-01-26 02641, 2022
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
2022-01-26 02608, 2022
monkey
I recently reworked the linting action for BB, so I'll see if it's transferrable.
2022-01-26 02658, 2022
lucifer
i think i had setup the annotations thing sometime ago but maybe it broke down. using BB one sounds fine.
.png){kind=link}