+1 We use git exclusively within QC, so this looks like simplification to us. There was mention early in the thread of continuing to enforce linear history; that’s important to our internal integration machinery. We do currently use the git-svn-id as a key for some of our internal processes, but it won’t be a problem to switch to something else.
We use google repo to stitch together our build tree, so the submodule discussion is mostly a no-op for us (providing it ends up being the “llvm-project” flat tree implementation). On Jun 1, 2016, at 1:51 PM, Matthias Braun via llvm-dev <llvm-...@lists.llvm.org> wrote: > So here's a straw-man proposal for a github migration: > > 1. Register an official github project with the llvm foundation. > 2. Setup another (read-only) mirror of llvm.org/git at this github project > 3. Make sure we have ala llvm-project-submodules setup in the official > account. (Optional or necessary for the buildbots?) > 4. Update the buildbots to pick up updates and commits from the official git > repository > 5. Update phabricator to pick up commits from the official git repository > 6. Tell people living downstream to pick up commits from the official git > repository > 7. Make sure bisecting with llvm-project-submodules is a good experience > 8. Give things time to settle. We could play some games like disabling the > svn repository for a few hours on purpose so that people can test that their > infrastructure has really become independent of the svn repository. > 9. Review and update llvm documentation. > 10. Review website links pointing to viewvc/klaus/phab etc. to point to > github instead. > ... Until this point nothing has changed for developers, it will just boil > down to a lot of work for buildbot and other infrstructure owners ... > 11. Collect peoples github account information, give them push access. > Ideally while still locking the github repository somehow... > 12. Switch svn repository to read-only and allow pushs to the github > repository. > 13. Disable/remove/archive the svn repository. > > - Matthias > >> On Jun 1, 2016, at 11:31 AM, Mehdi Amini via llvm-dev >> <llvm-...@lists.llvm.org> wrote: >> >> >>> On Jun 1, 2016, at 11:18 AM, Renato Golin via llvm-dev >>> <llvm-...@lists.llvm.org> wrote: >>> >>> On 1 June 2016 at 17:02, John Criswell <jtcris...@gmail.com> wrote: >>>> Do you have a set of volunteers lined up to do such a migration? Getting >>>> people willing to do the migration will obviously be key, and that was the >>>> one thing I didn't see in the original email. >>> >>> Hi John, >>> >>> Well, first we need to know if people are in favour, then if the >>> migration won't bring any serious problem, and then we can think of a >>> migration plan. :) >>> >>> So far, it seems people are mostly in favour, with a few that reported >>> being locked into SVN. I had anticipated that, and have proposed >>> GitHub's SVN integration, which allows read-write access, so it should >>> be mostly ok. We need more tests on that side to be sure, though. >>> >>> The biggest problem we're facing right now is how to sync the repos. >>> The existing llvm-repos format with all projects as sub-modules seem >>> to be a good candidate, but I still haven't seen a consensus on how >>> we'd do that. >>> >>> About the migration plan, most people seem to agree a step-by-step >>> process is necessary. >> >> I personnally disagree with that, see below. >> >>> So, first we move to git-only, possibly with >>> sub-modules >> >> If you move to git-only without the rest of the infrastructure/scripts, >> we're losing the convenience we have today with svn, and the "user >> experience" will not be so great. We may face resistance to this change. >> I advocate to first set it up till it reaches the point of "good enough" in >> term of usability before actually migrating. >> >>> , then we move to GitHub/Lab/BB, >> >> It means we first need to host our git, write the tooling around it, to then >> migrate to github. I don't see the benefit over migrating directly to >> github: if people have to change their configuration, better have one single >> change. >> >>> then we move Phab to >>> GitHub merge requests, etc. >> >> Phab to GitHub merge requests is a totally separate discussion IMO, and this >> discussion can happen after a successful move. >> >> >>> >>> Regarding volunteers, I haven't yet asked around yet, but I'm sure we >>> have enough interested people to help. If everything else fails, I'm >>> more than happy to do all of that myself. Though, I'd have to learn a >>> lot more about sub-modules than I know today, which is effectively >>> nothing. :) >> >> I'll be happy to throw manpower into tooling/infrastructure to make it >> happen. >> >> -- >> Mehdi >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev Jim Rowan j...@codeaurora.org Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
