<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 4:15 PM Jordan Rupprecht via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/10/2019 11:40 AM, Mehdi AMINI wrote:<br>
> <br>
> <br>
> On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>>> wrote:<br>
> <br>
> On 10/09/2019 11:05 PM, Mehdi AMINI wrote:<br>
> ><br>
> ><br>
> > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > We're less than 2 weeks away from the developer meeting, so I wanted to<br>
> > give an update on the GitHub migration and what's (hopefully) going to<br>
> > happen during the developer meeting.<br>
> ><br>
> > Everyone who has added their information to the github-usernames.txt<br>
> > file in SVN before today should have received an invite to become a collaborator<br>
> > on the llvm-project repository. If you did not receive an invite and think<br>
> > you should have, please contact me off-list. I will continue to monitor the<br>
> > file for new updates and periodically send out new batches of invites.<br>
> ><br>
> > There is still some ongoing work to get the buildbots ready and the mailing lists<br>
> > ready, but we are optimistic that the work will be done in time.<br>
> ><br>
> > The team at GitHub has finished implementing the "Require Linear History"<br>
> > branch protection that we requested. The feature is in beta and currently<br>
> > enabled in the llvm-project repository. This means that we will have the<br>
> > option to commit directly via git, in addition to using the git-llvm script.<br>
> > A patch that updates git-llvm to push to git instead of svn can be found here:<br>
> > <a href="https://reviews.llvm.org/D67772" rel="noreferrer" target="_blank">https://reviews.llvm.org/D67772</a>. You should be able to test it out on your<br>
> > own fork of the llvm-project repository.<br>
> ><br>
> > The current plan is to begin the final migration steps on the evening (PDT)<br>
> > of October 21. Here is what will happen:<br>
> ><br>
> > 1. Make SVN read-only.<br>
> > 2. Turn-off the SVN->git update process.<br>
> > 3. Commit the new git-llvm script directly to github.<br>
> > 4. Grant all contributors write access to the repository.<br>
> ><br>
> ><br>
> > Is the repo configured to forbid contributors to create new branches? I'm worried about the "jungle" it can become quickly if we leave open the possibility to create branches "at will" in the repo, I rather leave this to maintainers.<br>
> ><br>
> <br>
> I haven't been able to find a way to restrict branch creation for committers,<br>
> I'm not sure if this is even possible.<br>
> <br>
> <br>
> I think you can just go to the branch settings, add a new branch protection rule, match on everything but master, and check "Restrict who can push to matching branches".<br>
> <br>
<br>
I tried this, and the branch protections only come into effect after a branch<br>
has been creating, so this doesn't prevent new branches. It's actually worse<br>
than doing nothing, because once the branch is created the branch protection<br>
prevents you from deleting it.<br>
<br>
-Tom<br></blockquote><div><br></div><div>FWIW, we're interested in periodically (weekly) tagging well-tested/stable revisions, but via a branch instead of just a tag so we can include which cherrypicks (e.g. reverts or fixes) are needed. We do this with the current svn repo so we'd just be porting existing functionality to github.</div><div><br></div><div>(Also, I'm not sure this announcement thread with all the *-dev lists is the best place to discuss branching policy, but I wanted to get this bit in since y'all brought it up :) )</div></div></div></blockquote><div><br>IMO -- we should generally discourage random developer branches, and instead encourage people to fork the repo and do their work there. But I'd concur that it's not so big a concern as to require it to be prohibited via tooling, since they're easily removable. I can imagine some cases where a temporary dev branch in the main repo might be appropriate to use, and it'd be nice not to prohibit such a valid use.</div><div><br></div><div>With regards to these sorts of "vendor release branches", though -- I'm strongly against putting those in the main repo. That usage would certainly be best handled with a separate Google "fork" of the llvm-project repository -- and similarly for anyone else who wants to do it. Putting such branches into the main llvm repo means that everyone pulling it pulls down all the google release branches by default, which is really unnecessary clutter (check out <a href="https://github.com/llvm/llvm-project-legacy-branches" target="_blank">https://github.com/llvm/llvm-project-legacy-branches</a> if you'd like to see what such clutter starts to look like...note that github doesn't even display all of them in its branch/tag selector popup because there's too many.)</div><div><br></div></div></div>