I think that llvm-mirror/llvm didn’t actually exist when we first created out fork, but nowadays we definitely follow it! Currently we follow LLVM releases (via llvm-mirror/llvm) by taking their release branches in git and starting from there.
After we branch we add some rust specific patches that are too unstable to land upstream as well as some weird build patches that also don’t make sense to upstream. After that we only take backports of already landed patches upstream.
I think using a fork is a great idea as it gives you some more agility to the exact specifics of what youre doing (aka build shenanigans or Pony-specific things you’d like to test out). @cuviper is right though in that you’ll want to maintain compatibility with stock LLVM releases (aka most of the test suite should pass) for distros and such.
Otherwise the main thing I’d recommend is to not stray too far from upstream LLVM. Projects like PNaCl (IIRC) and Emscripten both strayed really far and it ends up never going upstream and becoming obsoleted in the long run. Patches we used to carry ourselves all bitrotted eventually and made upgrading too difficult so we dropped or merged them upstream.
And finally, I’d prepare to invest heavily in sccache/ccache caching on CI! Performing a full build of LLVM on a 4-core machine on Travis takes ~10m with sccache (caching via S3), and it’s so much easier to deal with CI if you always build LLVM instead of trying to cache it in its entirety.
