ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก
Open Source Maintenance, 2024-07-14
ฝัง
- เผยแพร่เมื่อ 16 ส.ค. 2024
- Due to some recent travel (both for fun and for work), I've yet again fallen behind on my GitHub notifications across the various open-source projects I maintain. In this video, like the others like it in the past, we made our way through as many of those as we could over the course of a few hours! And as with the past ones of these, my hope is that by showing the maintainer side of open-source, you get a better sense for how open-source operates, what it's like to be on the receiving end of issues/PRs, and just generally what maintainer work entails. And hopefully you also learn some stuff along the way!
In particular, we spent an inordinate amount of time on getting CI to be happy for github.com/jon... and on landing github.com/jon....
0:00:00 Introduction
0:04:42 Fantoccini 0.20.0 and 0.21.0 with hyper 1.0
0:43:21 PR that fixes typos (with CI)
0:46:52 crates-index-transit dependencies
0:57:46 Fantoccini CI: aws-lc
1:18:25 Various
1:20:50 Fantoccini CI: upgrade drivers and browsers
1:37:48 Various
1:45:05 Check in on fantoccini CI
1:50:33 hdrhistogram sum feature
1:58:19 Fantoccini CI: The root cause
2:35:13 Faktory: flaky test
2:43:15 Fantoccini CI: Chrome on Windows is still sad
2:48:59 Faktory: signals and blocking handlers
3:40:56 Fantoccini CI: A Chrome bug appears
3:45:43 Tea break
3:53:55 Various
4:15:33 Fantoccini CI: Try serial Chrome tests
4:21:52 Inferno: Bump dependencies
5:03:21 Fantoccini CI: Release 0.21.0
5:06:29 Inferno: Catching up with upstream
6:05:37 Inferno: Cut 0.11.20
6:27:47 wewerewondering: bump dependencies
6:31:18 Outro
Live version with chat: th-cam.com/users/li...
I love these Open Source Maintenance VODs since it's so cool to see behind the scenes of a repository/package maintainer like this and how much work goes into it.
Really inspiring! Thanks for maintaining all the open-source projects.
Thanks for the day in the life show. I work as devops/sre and I enjoy using Rust and watching your stream 1. to learn about awesome rust things and 2. to feel like I'm working in the office again.
This whole VOD felt so frustrating to watch, 10/10
I watched this from start to finish.. and man.. this open source stuff requires a lot of time and work!
Great stream Jon and thanks for everything you do!
I really wish my ADHD doesn't restrict me from watching this for 6hours, thank you for the quality content even though i struggle to watch 😂
The content is a cut above the rest. Keep setting the bar high!
Please do more crust of rust. They are incredibly informative
Don't you get burned out??
Really fucking inspiring
6 hours, wow
git bisect around 5h40m really felt more like git blame 😅
I don't think you actually needed to install nasm. After setting that environment variable it would build without it. Would it be slower? Yes, probably by a lot as well. Does it matter for CI? I don't think so. Would also require an unoptimized build of it.
Funny, I failed an test on a job interview a year ago and I've been all this time wondering how I could actually do what they asked the way they asked, I had no idea something like Fantoccini was a thing.
Wait 6hrs of coding non stop? Really? Is that even humanely possible?
I think we’re not talking about human here
I don't know how
I'd always do a cargo publish before pushing to git. Otherwise, if cargo publish fails in one of it's misterious ways, you'd have to change the history of the repo to if a change is required to make publish work.
Then you'd lose the commit hash in the vcs file that Cargo sticks in the crate file though?
@@jonhoo Not sure which vcs file you mean, I haven't seen `cargo publish` modify any files in the repo.
doc.rust-lang.org/cargo/commands/cargo-package.html#cargo_vcs_infojson-format
@@jonhoo Why wouldn't that be accurate? Cargo publish requires you to commit all relevant files before allowing you to publish. So the changes to Cargo.toml etc. would all be part of the branch that would be pushed if and once the publishing succeeds. If cargo aborts the process you get to do over, if you pushed the branch and tag before the publishing, if it aborts, then you either have to rewrite the git history or do another version bump (and so on until it succeeds).
Oh, I see what you mean. I thought you also wouldn't commit. Even if you do though, I'd be slightly worried that you then push and end up with failing CI or some such. Or alternatively if you have a branch with succeeding CI that something then lands on main in the meantime. But then again, I suspect every ordering here has some possibility of a race.
it's ALWAYS windows 😢
"This job failed. Ok, great."