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.
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.
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 know the struggle, I've finally finished watching this video after what, 2 months? Sometimes you get into the flow, but sometimes you get distracted after 5 minutes. But the educational value of these is immense, so I always try to return after breaks.
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.
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.
@@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.
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.
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!
Please do more crust of rust. They are incredibly informative
This whole VOD felt so frustrating to watch, 10/10
The content is a cut above the rest. Keep setting the bar high!
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 😂
I know the struggle, I've finally finished watching this video after what, 2 months? Sometimes you get into the flow, but sometimes you get distracted after 5 minutes. But the educational value of these is immense, so I always try to return after breaks.
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.
Really fucking inspiring
6 hours, wow
git bisect around 5h40m really felt more like git blame 😅
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.
Don't you get burned out??
When you truly love what you do, it becomes much less of a chore. Passion is a fuel that can drive a train for hours without ever slowing down.
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."
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
6 hours of non stop programming? Sounds like a typical programming session in college.
If you love what you do, 6 hours is gonna feel like 10 minutes.
@@troyb4533Or a job...?