> On Jun 2, 2016, at 12:18 PM, Mehdi Amini <mehdi.am...@apple.com> wrote: > > >> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev >> <llvm-...@lists.llvm.org> wrote: >> >> I personally find this email thread very hard to follow and read (this isn’t >> anyones fault.. its just a lot of replies). I am sure others do as well. I >> think it would be good to have a form/survey of some sort that can get >> feedback from users such as: who they are, how they use >> LLVM/contributions/etc, if they are pro-github move, how it impacts them, >> etc. People could then submit their feedback in an organized way and we >> could get a better idea of how the community feels on the topic. >> >> I am happy to try to set something like this up. > > I don't think it is a good idea to set this up like that without having a > well defined plan first. > My idea is rather that we should first try to see what is doable in term of > server-side hook and integration so that the "poll" is not about naked "svn > vs git", but about "svn vs > git-with-this-server-side-setup-that-preserve-our-workflow". >
Sure, I am fine with flushing out those details out. Just an idea to get a better idea of the consensus when the time comes. -Tanya > -- > Mehdi > > > >> >> -Tanya >> >>> On Jun 2, 2016, at 8:48 AM, Renato Golin via llvm-dev >>> <llvm-...@lists.llvm.org> wrote: >>> >>> A little summary... >>> >>> After a lot of discussion, I think we converged to a few issues that >>> we need to solved before we finally decide to move. >>> >>> Firstly, the responses were overwhelmingly positive (I counted 20 of >>> the ~25 people strongly supporting and another 2~3 weakly supporting). >>> This is a good indication that the move could be very beneficial to >>> the community as a whole, including downstream infrastructure, not >>> just the reduction in upstream infrastructure admin costs. >>> >>> But that doesn't mean we have cleared up all the issues... >>> >>> >>> The benefits I gathered from the thread: >>> >>> * Infrastructure admin (not just server costs) is too expensive. >>> We're not sysadmins and maintaining all the tools is a full time job. >>> Volunteering works for odd problems, not for production services. >>> Furthermore, most of the infrastructure we need is covered by >>> GitHub/Lab/BB for free, on a scale that we would not have, even with a >>> full time sysadmin. Gratis. >>> >>> * Having one official repository instead of two is beneficial to most >>> developers. A lot of people (most people replying on this thread), use >>> Git in addition to SVN. Git also seems to be used more on validation >>> infrastructure than SVN (no example was put forward on this thread, at >>> least), due to the simplicity of controlling the repository and the >>> tools available. Reports of how teams decided to script Git to have >>> linear behaviour instead of falling back to SVN are enlightening. >>> >>> * Git developer tooling is a growing trend, while SVN tooling is >>> dying. This is not just about GUIs, but repository management (GitHub, >>> GitLab, BitBucket, etc versus SourceForge), bisects, branches, >>> remotes, hooks, workdir, submodules and all the new development seem >>> to be done on Git nowadays, not SVN. Windows may be an odd one related >>> to GUIs, but Visual Studio has Git integration and I hear it's similar >>> to the other MSVC VCSs. GitHub's desktop interface seems pretty cool, >>> too. >>> >>> * Web repositories make it *a lot* easier to create add-hoc pull >>> requests by non-developers, which could boost the number of >>> contributions and future contributors, as well as external projects >>> using LLVM components. >>> >>> * GitHub's SVN RW interface has been reported to work well for >>> simpler projects, but we need a more thorough examination before >>> declare it good enough for our purposes. >>> >>> * All reports on the thread pointed that downstream infrastructure is >>> already using Git, so that's one less problem to worry about if we do >>> move. >>> >>> >>> The issues that were raised: >>> >>> * Co-dependent patches already break buildbots, but the sequential ID >>> helps us identify and ignore. They will continue to break, even if we >>> use git sub-modules, so that doesn't change much, but it will be >>> harder to spot the issue. Server side hooks may help, as well as >>> sub-modules. >>> >>> * Windows tooling may be an issue. There's a separate thread handling >>> that part, so I won't cover it here. But I have to say it wasn't by a >>> long shot a resonant problem. It may also have some problem with >>> symlinks and in-tree checkouts (when interacting with llvm-projects >>> and sub-modules). >>> >>> * Sub-modules may help with a lot of the current relationship we have >>> inside the SVN repo, but it also has some problems. Namely they: >>> - require a modern version of git (1.7/1.9), but that's 2013 onward. >>> - may need additional server side scripting, but we can keep that >>> in another repo to control it. >>> - won't replace SVN's monotonic IDs, but do we *really* need them? >>> Sub-modules have a bad fame, I gather, but people in the thread >>> reported success on using it to build validation and release >>> infrastructure as well as doing bisects, checking out code, etc. We >>> probably need some documentation on how to do these things, as well as >>> some scripts to help people work out the dependencies (or use them). >>> >>> * GitHub/Lab/BB are not perfect. They have some interface issues, but >>> nothing more serious than we already have on our current >>> infrastructure. We'll probably have to keep Bugzilla (as GitHub's own >>> is really poor), but we can replace all our repos (SVN, Git), >>> visualisation tools (ViewVC, Klaus) and Phabricator. >>> >>> Of all those issues, Windows tooling is a minor problem that shouldn't >>> impact decision that much and sub-modules need a lot of ironing out to >>> be considered good enough. My *personal* take away is that sub-modules >>> (or an alternative server side solution) is the only strong technical >>> issue we need to solve before we decide. >>> >>> >>> How does a move look like? >>> >>> If we decide to move, the proposed schedule is something like this: >>> >>> STEP #1 : Pre Move >>> >>> 0. Update docs to mention the move, so people are aware the it's going on. >>> 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 a la llvm-project-submodules setup in the >>> official account. (Optional or necessary for the buildbots?) >>> 4. Make sure bisecting with llvm-project-submodules is a good experience >>> 5. Make sure no one has any blocker >>> >>> STEP #2 : Git Move >>> >>> 6. Update the buildbots to pick up updates and commits from the >>> official git repository >>> 7. Update Phabricator to pick up commits from the official git repository >>> 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 repository for a few hours on purpose so that people can test >>> that their infrastructure has really become independent of the svn >>> repository. >>> >>> ... Until this point nothing has changed for developers, it will just >>> boil down to a lot of work for buildbot and other infrastructure >>> owners ... >>> >>> STEP #3: Write Access Move >>> >>> 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. >>> 12. Mirror Git to SVN. >>> >>> STEP #4 : Post Move >>> >>> 13. Archive the SVN repository, if GitHub's SVN is good enough. >>> 14. Review and update *all* LLVM documentation. >>> 15. Review website links pointing to viewvc/klaus/phab etc. to point >>> to GitHub instead. >>> >>> This is an adapted version of Matthias' and Mehdi's proposal, and it's >>> not a final version in any way, but these are the basic things we need >>> to worry about. >>> >>> >>> Steps from here... >>> >>> Aaron has started the Windows tooling thread, and if you have any >>> comments, please follow from there. I suggest sub-modules supporters >>> to start another thread to iron that out separately. >>> >>> Once those issues are resolved, we shall start another thread to >>> finally take a decision to move or not. >>> >>> Thanks everyone! >>> >>> cheers, >>> --renato >>> _______________________________________________ >>> 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 > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
