vsk added subscribers: friss, vsk. vsk added a comment. @rengolin thanks for putting this together! I chimed in with some comments in-line.
================ Comment at: docs/Proposals/GitHub.rst:68 @@ +67,3 @@ + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + ---------------- What do you mean by multiple concurrent builds? ================ Comment at: docs/Proposals/GitHub.rst:185 @@ +184,3 @@ + +Are there any other upstream systems that could be affected? + ---------------- Yes, the `llvmlab bisect` functionality is affected. IMO it is invaluable for bug triage. Could you add some kind of reassurance that initially, updating it for the new VC model will just require pointing it to github's SVN view? ================ Comment at: docs/Proposals/GitHub.rst:220 @@ +219,3 @@ +8. Tell people living downstream to pick up commits from the official git + repository. +9. Give things time to settle. We could play some games like disabling the SVN ---------------- This is tricky. CC'ing @friss to comment on how we'd need to update our internal auto-merger. ================ Comment at: docs/Proposals/GitHub.rst:233 @@ +232,3 @@ + +10. Collect peoples GitHub account information, adding them to the project. +11. Switch SVN repository to read-only and allow pushes to the GitHub repository. ---------------- delcypher wrote: > GitHub organizations support the notion of teams which can each have > different permissions (for example you'll want to make sure only the right > people have admin access and give the rest write/read access). You could also > make a team per project so that write access in one project does not give > write access to another. I think it would be good to decide on how teams will > be organized and state this in the document. I think this is an important discussion to have once the move is under-way. I don't think finer-grained write privileges should be a part of this proposal since it's (1) a separate issue and (2) not *just* an artifact of llvm-project's svn structure (i.e there are good reasons to keep the current permissions model in place). https://reviews.llvm.org/D22463 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
