[llvm-dev] [RFC] One or many git repositories?

[Tom Honermann via llvm-dev]

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.

Tom.