Hello there,<div><br></div><div>Renato, thank you for putting everything together.</div><div><br></div><div>Talking about second question (commits mailing list): github provides set of various web hooks. I think here we are interested <br>In 'push'es particularly.</div><div><br></div><div>Besides that it has some CI related integrations: buildbots can update pull request status to show if tests are passing or not. The builds can be also triggered using web hooks (issue_comment with specific text). IIRC swift and rust do this (and more) in a very similar way.</div><div><br></div><div>Cheers,</div><div>Alex.<span></span></div><div><br></div><div>[1] <a href="https://developer.github.com/webhooks/#payloads">https://developer.github.com/webhooks</a></div><div><br>On Sunday, 26 June 2016, Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So,<br>
<br>
It's been a while and the GitHub thread is officially dead, so I'll<br>
propose a development methodology based on the feedback from that<br>
thread. This is not *my* view, but all that was discussed in the<br>
threads.<br>
<br>
My objective is to form an official proposal to use Git as our main<br>
repository, overcoming all the problems we currently have without<br>
creating many others. In the end, I think Tanya wanted to make a vote,<br>
and see how string the community feels about it. The vote should be<br>
"Should we move to GitHub as the proposed workflow, or should we try<br>
to find another solution away from our own hosting?".<br>
<br>
The important part is that we *must* move from the current schema. It<br>
does not scale and the administrative costs are not worth the trouble.<br>
So, if we don't go with GitHub, we have to find another way out.<br>
<br>
The proposal<br>
==========<br>
<br>
Move to GitHub with N+1 projects: all current LLVM projects + the<br>
"llvm-projs" umbrella. The latter will have all other projects as<br>
"submodules" with the intent to:<br>
<br>
 1. Control the history via server hooks updating a unique and<br>
auto-increment identifier, which will apply to every commit on its<br>
submodules (ie, every other LLVM project).<br>
 2. Serve as a reference for releases, buildbots, etc., checking out<br>
only the necessary submodules for each.<br>
 3. Have additional logic to handle the additional complexity for<br>
mailing lists, tools, buildbots to deal with the umbrella project<br>
*only*.<br>
<br>
The existing LLVM projects (llvm, clang, compiler-rt, etc) will<br>
continue on their own repositories and be built locally just like they<br>
are today. You can check them out individually inside the final<br>
directory (llvm/tools/clang) or use symbolic links, just like we do<br>
today. You can also checkout "llvm-projs" and update only the required<br>
submodules, and use symbolic links.<br>
<br>
The llvm-projs umbrella will have its own versioning, and tools can<br>
report that ID as their "version", if they're not in a release branch.<br>
<br>
Release branches should be off of master and have a linear history,<br>
just like master, in the exact same way we do now with SVN. This will<br>
guarantee the umbrella project will be able to correctly<br>
auto-increment the ID and make sure current tools work as usual.<br>
<br>
We don't want private branches to end up in upstream LLVM (only<br>
upstream release branches), but that's perfectly natural in GitHub,<br>
where anyone can fork and implement their features and own releases<br>
off of the upstream official repositories.<br>
<br>
This can work as well for upstream development of "feature branches",<br>
where upstream developers contribute to both repositories, but keeping<br>
a specific feature in test separate. Merges will still have to be like<br>
it is today, one patch at a time, or risk reverting the whole merge<br>
window if the buildbots start breaking, which can be impossible if the<br>
window is large or two or more windows get committed at the same time.<br>
<br>
For "feature branches" we could use git-imerge, but that's for the<br>
future and not considered in the first stage of the move.<br>
<br>
Git Submodules<br>
---------------------<br>
<br>
There were concerns is submodules would work with our flow, but the<br>
concerns were addressed by demonstrating that:<br>
<br>
 1. Submodules can work in an umbrella project, which controls the<br>
auto-increment ID<br>
 2. You can check-out individual modules or all, so work well for<br>
releases and buildbots<br>
 3. The history is shared with the root project, so git-bisect works<br>
out of the box<br>
<br>
The Alternatives<br>
---------------------<br>
<br>
A few alternatives were proposed, but git submodules ended up being<br>
considered more thoroughly. Here are some of the reasons:<br>
<br>
 * Google repo:<br>
<br>
It's an independent tool, which may suite us today, but not<br>
necessarily tomorrow. It may work well with the infrastructure that is<br>
already set for it on other projects (mostly Google projects like<br>
Android), but it does require some tooling (like git submodules). The<br>
point is, that it's much more likely to exist tooling for official git<br>
features than third-party projects, especially on Windows.<br>
<br>
 * All-in-one:<br>
<br>
Proposals to have all projects inside one big repo were quickly<br>
dismissed due to the problems it creates to *users* of LLVM as a<br>
library, and to build systems (specific buildbots) that don't need to<br>
monitor all changes all the time. It simply won't scale.<br>
<br>
 * Multiple clones:<br>
<br>
Allowing the projects to *exist* in different conditions (clang inside<br>
LLVM, or as a stand-alone library) will not scale. CMake will have to<br>
cope with all the different styles, it doesn't solve the unique<br>
auto-increment ID nor it helps downstream projects migrate to a common<br>
infrastructure.<br>
<br>
Questions<br>
========<br>
<br>
In order to make this proposal final, I still need a few questions to<br>
be answered.<br>
<br>
1. How will the umbrella project's auto-increment hook work?<br>
<br>
Will it be one ID for every commit in every other repo? How will it<br>
know which one came first? Does it matter? If we have two commit "at<br>
the same time", do we create a priority list?<br>
<br>
Ex. LLVM commits get a lower ID than Clang ones, because it's more<br>
likely that an LLVM commit needs to go in first.<br>
<br>
2. How do we update the commits mailing lists?<br>
<br>
Can we add a mail script to the auto-increment ID hook? Or should we<br>
have a cron job that picks the new commits every 5 minutes in a server<br>
somewhere and email them (in ID order) to the respective lists?<br>
<br>
Approval<br>
=======<br>
<br>
Right now, we should not discuss if moving to Git or GitHub is a good<br>
idea or not. This is about the proposal itself. So, if you don't want<br>
Git or GitHub, wait for the voting to express that.<br>
<br>
If you do want Git and GitHub, than please keep your comments on<br>
topic, answer the questions and let's make sure we have a solid<br>
proposal that most Git proponents are happy with.<br>
<br>
If there is an alternative proposal (say, Google's repo), than this<br>
has to be separate, and well explained and accepted to be voted, too.<br>
<br>
Once we all agree in general, we should put it to vote. If there's an<br>
overwhelming majority (not sure how to measure this), and no critical<br>
problems (for example, learning new tools is less critical than<br>
breaking all buildbots), we should go with the move.<br>
<br>
For logistical reasons, if we do decide to move, I would like to do so<br>
before 3.10 / 4.0 branches.<br>
<br>
cheers,<br>
--renato<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'llvm-dev@lists.llvm.org')">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>