[llvm-dev] [cfe-dev] GitHub anyone?

Jim Rowan via llvm-dev
Wed, 01 Jun 2016 20:22:38 -0000

+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-dev at
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-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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Jim Rowan
jmr at codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation