On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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. So, first we move to git-only, possibly with sub-modules, then we move to GitHub/Lab/BB, then we move Phab to GitHub merge requests, etc. 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. :) cheers, --renato
> On Jun 1, 2016, at 11:18 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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-modulesIf 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
On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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. So, first we move to git-only, possibly with > sub-modules,Despite people's reservations of a git-only repository? I mean, we still don't know that this will even work for people who wish to stay with SVN. I am really not comfortable with this decision based on "it should be mostly ok" from above, but maybe I am misunderstanding something. ~Aaron
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-dev at lists.llvm.org> wrote: > > >> On Jun 1, 2016, at 11:18 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 1 June 2016 at 19:31, Mehdi Amini <mehdi.amini at apple.com> wrote:> 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.That's what I meant... :)> 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.We already host our own git, so people already use it. Moving the git repo location will also disrupt infrastructure, and is not critical, so we can do it later.> Phab to GitHub merge requests is a totally separate discussion IMO, and this discussion can happen after a successful move.Indeed, what I meant as well. :)> I'll be happy to throw manpower into tooling/infrastructure to make it happen.Thanks! Most appreciated! --renato
On 1 June 2016 at 19:36, Aaron Ballman <aaron at aaronballman.com> wrote:> Despite people's reservations of a git-only repository?Hi Aaron, not at all! I was especially vague on my first email to make sure SVN folks would be shoved on the side, but John had asked for a full plan *in the case we move*, and I was just completing the picture. Having said that, I can't take that decision alone, and my own opinion is irrelevant on the grand scheme. Right now, our main repo is in SVN with most people using Git. If the vast majority vote for the move, it wouldn't be fair to continue to force SVN on them, and it would be overall less effort for the few people that prefer SVN to have a bit more work than they have today, to save the majority of Git users the extra work. I have no idea how much people is enough to move to Git, but unless we fix the sub-module problem, there's no point in even trying. So, my personal points are: 1. We can only move IFF the Git solution is technically equivalent or superior than what we have today. 2. We should only move IFF the vast majority will see benefits from it, even if a small minority will see some increased effort. Of course, the balance of efforts has to be overall positive. 3. We should not move if there is no replacement for SVN users at the moment. We should try to encourage SVN users to move to Git, to speed up the move, though. I'm assuming the SVN vs. Git argument is not just a personal thing, but a tooling / infrastructure issue. The bigger picture here is not which VCS is better, but getting rid of a huge infrastructure cost from our part, which nowadays means moving to Git or using SourceForge. cheers, --renato
> On Jun 1, 2016, at 11:36 AM, Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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. So, first we move to git-only, possibly with >> sub-modules, > > Despite people's reservations of a git-only repository? I mean, we > still don't know that this will even work for people who wish to stay > with SVN.The thread is open on llvm-dev, there won't be any migration next week (or even next month), that leaves time for any contributor to raise any real blockers. I haven't seen any of these till now, but the thread is getting long and I may have missed an email.. -- Mehdi> I am really not comfortable with this decision based on "it > should be mostly ok" from above, but maybe I am misunderstanding > something. > > ~Aaron > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
IMO, if we're switching to git, we should just be clear up front that all committers will be expected to switch to git as well -- or at least, if they want to use something else (e.g. mercurial's git bridge/etc), that it's their own problem. It is truly NOT that big an imposition to require the use of git. And knowing how to use git at at least a basic level is an important skill for a lot of software development now -- no matter what LLVM does, so I don't feel bad for making anyone spend time learning how to use it. I really don't think that promising and requiring that svn-client using people (especially committers: read-only access seems a lot less potentially problematic) will keep getting a good development experience after the migration is a good idea. I mean, if SVN also happens to work with the chosen hosting/workflow in the end, that's fine, I guess. But, I feel that should be considered a "if it works, that's okay, but it's not recommended, and is not guaranteed" kind of thing. Making that a requirement locks us into the use of github as the primary repository: no other git hosting has svn support, afaik. It means we can't introduce any workflows that wouldn't work well for svn users -- or if we do, that such users will probably complain anew when that happens. And if github's svn bridge turns out to have fatal problems, do we then abandon the migration? On Wed, Jun 1, 2016 at 2:36 PM, Aaron Ballman via cfe-dev < cfe-dev at lists.llvm.org> wrote:> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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. So, first we move to git-only, possibly with > > sub-modules, > > Despite people's reservations of a git-only repository? I mean, we > still don't know that this will even work for people who wish to stay > with SVN. I am really not comfortable with this decision based on "it > should be mostly ok" from above, but maybe I am misunderstanding > something. > > ~Aaron > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/fbf1a9d0/attachment.html>
On Wed, Jun 1, 2016 at 11:18 AM, Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 1 June 2016 at 17:02, John Criswell <jtcriswel at 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. >Is it possible to set up a post-commit hook for each child repository that commits the new child repo's head into the corresponding branch of the parent repository? Does anyone have experience with doing that on github? That would seem to give the workflow that we want. About the migration plan, most people seem to agree a step-by-step> process is necessary. So, first we move to git-only, possibly with > sub-modules, then we move to GitHub/Lab/BB, then we move Phab to > GitHub merge requests, etc. > > 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. :) > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/1446a894/attachment.html>