[llvm-dev] [RFC] One or many git repositories?
Tom Honermann via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 29 08:36:33 PDT 2016
On 7/29/2016 5:21 AM, David Chisnall via llvm-dev wrote:
> ... A lot of downstream developers
> need to patch LLVM and we benefit when they upstream their changes. We
> should not make it harder for them to do this. To give a couple of
> example downstream projects, both FreeBSD and Swift have patches on LLVM
> / Clang in their versions that they gradually filter upstream. Both
> projects have LLVM committers among their members. If the workflow that
> we recommend for them makes upstreaming easy then they benefit
> (maintaining a fork is effort) and LLVM benefits (having people provide
> bug fixes makes our code better).
While I agree with all of the above, I think the cost difference in the
mechanics of how changes are upstreamed is negligible. The much larger
cost of upstreaming changes is the engagement with the community itself.
In our local repos, we can skimp on code quality and testing (to our
own detriment of course). When we upstream, we need to ensure code
style is consistent and that unit tests are in place. We need to find
someone with commit access that is willing to commit on our behalf, go
through code review with them and address any requests for changes, and
then resolve conflicts when the upstreamed changes get pulled back into
our repo (we #ifdef our local customizations for auditing and testing
purposes, so there are always conflicts for us). This is all exactly as
it should be. The only reason I mention it is to say, don't dwell on
the mechanics of upstreaming changes too much as the cost differences
just aren't that significant *unless* those mechanics significantly
reduce the code review and commit process costs.
More information about the llvm-dev