[PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!

Saleem Abdulrasool via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 18 08:07:31 PDT 2016


compnerd added inline comments.

================
Comment at: docs/Proposals/GitHub.rst:127
@@ +126,3 @@
+* The projects' repositories will remain identical, with a new address (GitHub).
+* They'll continue to have SVN RW access, but will also gain Git RW access.
+* The linear history can still be accessed in the (RO) submodule meta project,
----------------
jroelofs wrote:
> Do you mean `s/SVN RW access/SVN RO access/` here?
I believe @rengolin is referring to the final state here.  I agree that the current phrasing makes it hard to follow.

================
Comment at: docs/Proposals/GitHub.rst:129
@@ +128,3 @@
+* The linear history can still be accessed in the (RO) submodule meta project,
+  Which will continue to have SVN access.
+
----------------
"Which will continue to have SVN access" is redundant given the previous statement.

================
Comment at: docs/Proposals/GitHub.rst:136
@@ +135,3 @@
+Essentially, we're adding Git RW access in addition to the already existing
+structure, with all the additional benefits of it being in GitHub.
+
----------------
jroelofs wrote:
> Need to clarify here whether *write* access through SVN will be going away. If I understand the proposal correctly, it will go away, but this section makes it sound like it's staying.
The way that I read the nutshell is that it would potentially continue to exist, just at a different address.

================
Comment at: docs/Proposals/GitHub.rst:155
@@ +154,3 @@
+But some people/companies might not be allowed to use GitHub or might have
+firewalls blocking certain websites.
+
----------------
GitHub does have HTTPS based connections.  It seems highly unlikely that this is a real concern.  Companies would have to go out of their way to block access specifically to github over SSH and HTTPS.

================
Comment at: docs/Proposals/GitHub.rst:167
@@ +166,3 @@
+with the limited number of developers whose job will be to mainly merge
+thousands of patches a day.
+
----------------
I don't fully understand how this is any different from today.  We have a core set of developers with commit access.  Others are encouraged to provide patches via email (or may use phabricator depending on the reviewer).  Once reviewed and accepted, one of the core developers still commits the change.  I just see this as a process change.

The person forks the repository on github, and creates a branch, and then a PR.  The PR is reviewed and once accepted, merged by one of the core developers.  It even implicitly handles authorship tracking which has currently been done in an adhoc fashion via the commit message.

================
Comment at: docs/Proposals/GitHub.rst:222
@@ +221,3 @@
+10. Collect peoples GitHub account information, give them push access. Ideally
+    while still locking the GitHub repository somehow...
+11. Switch SVN repository to read-only and allow pushes to the GitHub repository.
----------------
Giving permissions to only the LLVM "project" is sufficient.  People can be added to the LLVM "project" as collaborators and get access that way.  This is similar to how Apple is managing swift for comparison.


Repository:
  rL LLVM

https://reviews.llvm.org/D22463





More information about the cfe-commits mailing list