<div dir="ltr">Two problems:<div>1) Submodules have some UX problems for developers around updating the parent project and its effects on the submodule which make them annoying to use.</div><div>2) I find the advantage you claim especially scary and bad. Put another way: if a developer *doesn't* make a commit to clang with the new submodule pointer, clang will not actually start using the new version of LLVM until someone gets around to updating the pointer. Meaning, the next time anyone *ELSE* goes to update the submodule pointer in clang, they would have to, effectively, integrate all of the as-yet-untested-with-clang changes from llvm, and fix any problems that might cause. I really don't think we want that.</div><div><br></div><div>What I do think would be nice is a way to associate commits to llvm and commits to clang as one unit that updates a parent repository. I've mentioned before that gerrit seems to have that functionality.</div><div><br></div><div>I think it'd be a great idea to do some testing, and make a second proposal centered around using Gerrit to manage commits to the github repository, versus committing to github directly. I'm not sure if I'll have time to do that properly, though.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 10:39 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> As for updating the meta repository: We could disable write access for the normal llvm developer and delegate the submodule bumping to an external<br>
>> server. I believe this would be an easy enough job for buildbot or jenkins.<br>
><br>
> The plan is to disable all write access to this repository (otherwise<br>
> we'll create a nightmare). Having an external counter could be<br>
> problematic due to synchronisation issues.<br>
><br>
> If the hook doesn't work, we'll have serious problems.<br>
<br>
</span>So, I probably missed something, but what was the main objection to<br>
just using submodules? This would put llvm inside clang instead of the<br>
other way around. When changing an API one currently has to<br>
<br>
* Change llvm.<br>
* Quickly change clang and hope no bot picks up a revision with only<br>
the llvm change.<br>
<br>
With submodules it becomes<br>
<br>
* Change llvm.<br>
* Change clang and in the same atomic commit change what revision the<br>
submodule points to.<br>
<br>
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>