rengolin added inline comments. ================ 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. + ---------------- compnerd wrote: > "Which will continue to have SVN access" is redundant given the previous > statement. good point. I'll try and re-write those points to be more clear.
================ 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. + ---------------- compnerd wrote: > 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. I have had this problem in China... Though no one has raised this issue, so I'll just remove and let people complain about this in the survey. ================ 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. + ---------------- compnerd wrote: > 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. Today we all commit to SVN, which is linear. In GitHub, we'll be committing to git. If we can have hooks forbidding merges, it'll remain linear, but then pull requests will be blocked. Additional hooks will need to be in place (please suggest all of them here and I'll update the doc). ================ 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. ---------------- compnerd wrote: > 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. That's what I meant but I will change the wording. Repository: rL LLVM https://reviews.llvm.org/D22463 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
