I’ve worked on branches with hundreds of in house devs, it is possible to run a high trust fast revert model with a lot of people
Conversation
Replying to
A high trust model could mean people can sign off on their own change and the bot tests + merges it the same as always though. Take a look at how Rust merges changes if you haven't.
2
Replying to
Open source is low trust and therefore needs a lot of gatekeeping that you don’t need for the person sitting next to you.
1
6
19
Replying to
I'd happily push a change to refs/for/master instead of to master and have CI quickly build + test and merge it for me even for projects where I'm the only person working on it. I don't do it because the tooling on GitHub is horrible.
1
2
So, basically, what I'm used to for collaborative projects with good bots + CI is that committers can approve their own change, but regardless, the bot is going to test + merge it. Especially important if you target a bunch of platforms people can't just test locally easily.
1
2
Even if just target 1 platform and the development testing environment is nearly exactly the same as production, which generally isn't the case, it's really useful to have the changes run through a build + test and merged automatically so you actually can't break the main branch.
1
2
The pain it requires is relative to build time. If build time is 1 minute, there's really no pain involved in that kind of system. There's the honor system of people approving their own changes for simple / obvious stuff but someone else doing it for more complex stuff basically.
1
2
The tooling needs to be really good though. I have a lot of problems with GitHub CI. If the builds are really long, it also starts getting increasingly annoying especially in combination with a fast moving project with many contributors. Need really good infrastructure for it.
1
2
GitHub workflow + UI + their CI is all around really bad / unreliable. I would happily pay $150 / month for GitHub if they actually gave me a really good UI and powerful CI infrastructure that worked really well. I wouldn't trust them to actually ever provide that though...
1
2
Just haven't had a good experience with those platforms / companies. It makes me dislike CI because their CI is so ridiculously bad. Same for code review. I don't exactly think Gerrit is an amazing UI for it's an order of magnitude better workflow + review UI than GitHub.
1
1
I only use GitHub because I weigh the cost of dealing with the hell of GitHub vs. having to set up and maintain infrastructure with Git, Gerrit and CI.
For open source stuff, I also feel it's lower barrier to entry since people have an account already but not relevant otherwise.
At some point, I'll get fed up enough with GitHub to start using Gerrit and my own CI as I'd actually want to do and I'll probably be happier. Maybe I should hire someone to deal with it.
1
1
Most of my work involves dealing with downstream patches so Git itself doesn't really work and has to be tortured via rebase / cherry-pick to make things sustainable, as I'm sure you're getting used to with your Chromium work. GitHub is bad at dealing with rebases so... yeah.
1
1
Show replies

