Re: [Lldb-commits] [PATCH] D13578: Allow generic arm ArchSpec to merge with specific arm ArchSpec; allow Cortex M0-7's to always force thumb mode
rengolin added a comment. Hi Jason, This has nothing to do with your patch per se, but we have accurate target descriptions in LLVM, and the parser for all the triples and extra options is now publicly available, so I was wondering if (probably after this go in), you could have a look at using these libraries. I'm of course assuming you already use other LLVM libraries in LLDB, as it would make sense to use the same target description classes to understand about the target without re-writing everything. Just a thought. cheers, --renato Repository: rL LLVM http://reviews.llvm.org/D13578 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D13578: Allow generic arm ArchSpec to merge with specific arm ArchSpec; allow Cortex M0-7's to always force thumb mode
rengolin added a comment. In http://reviews.llvm.org/D13578#264072, @jasonmolenda wrote: > I'm trying to rewrite IsAlwaysThumbInstructions() to use the information that > llvm already has, as per Renato's suggestion. The MCSubtargetInfo has a > getFeatureBits() method which can indicate ARM::FeatureNoARM. I'm still > having a little bit of trouble getting it to build, the ARMFeatures.h is in > an unusual location and it indirectly pulls in ARMGenRegisterInfo.inc, > ARMGenInstrInfo.inc, and ARMGenSubtargetInfo.inc from the build dir - I'll > need to update xcode and cmake to add the $(llvm-build-dir)/lib/Target/ARM/ > to the include path for these to be found. I might not have time to finish > this tonight, we'll see. The target information classes depend on table-generated files, so if you were not building them before, you'll need to do that now. I though LLDB was doing this already, that's why I suggested lightly. But ultimately, I believe you *don't* want to have your own target description anyway, so it's a move that you'd have to do anyway. > I'm not sure how expensive it is to make an llvm::Target and get the > MCSubtargetInfo out of that every call; I may need to save something in an > ArchSpec ivar. Maybe just the results of the FeatureBits check. I'm not sure you should be doing that. Those calls normally involve traversing tables and correlating information. Even though that gets optimised pretty well, it's not something that you want to be delaying delicate hardware handling of breakpoints, run states etc. I'd guess you could have a local cache with only the information you need, and you initialise it from the target description classes once. You may end up with some duplication, but hopefully, it won't be too much and it'll be a lot faster. --renato Repository: rL LLVM http://reviews.llvm.org/D13578 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Buildbot e-mail notification has been changed
On 28 October 2015 at 16:33, Galina Kistanova via llvm-commits wrote: > E-mail notification has been changed in the buildmaster. Now it should not > count interrupted builds to figure out if notification should be send. Thanks Galina, that'll reduce the noise considerably! cheers, --renato ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19604: Allow ObjectFilePECOFF to initialize with ARM binaries.
rengolin added reviewers: omjavaid, compnerd. rengolin added a comment. Nice! LLDB on ARM Windows! :) Adding Omair and Saleem to approve, as hard-coding the triple may bring unwanted consequences. http://reviews.llvm.org/D19604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19604: Allow ObjectFilePECOFF to initialize with ARM binaries.
rengolin added a comment. In http://reviews.llvm.org/D19604#419284, @sas wrote: > - We don't use thumb-* triples in lldb as far as I can see. Thumb is handled > just fine regardless of the triple. This is a good strategy. Thumb is an instruction set, the "arm-" in the triple means the Architecture. > - `pc` vs `unknown` doesn't seem to matter either, and other code in this > file uses `pc` (see a few lines above). AFAIK, "pc" is accepted but ignored, just like "unknown" and "gobbedygook". > - I could just use `arm` instead of `armv7` but as far as I know, Windows > Phone is a pure thumb environment, so the CPUs used will be armv7 and up. Er, this doesn't make sense. ARM cores support Thumb ever since ARMv4T (ARM7, circa '97). Thumb2, which is the version supported by ARMv7 cores, exists since ARMv6 (ARM11, circa '03). It's best if you keep the triple free of sub-architecture choices and use -march to pick the right one. But some platforms have chosen to specify it on the triple, and we may have to follow suit to be compatible. > - I could add support for aarch64 in this file, but I've got no way of > testing it at the moment, and it seems likes a bad idea to advertise support > for something we can't even test. Agree. > Given all of these, it seems like sticking with `armv7-pc-windows` or using > `arm-pc-windows` might be the better solutions. Let me know what you guys > think. "arm-pc-windows" seems good to me. I'm also ok with "armv7-pc-windows" if that's the "accepted" triple on Windows world. cheers, --renato http://reviews.llvm.org/D19604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19604: Allow ObjectFilePECOFF to initialize with ARM binaries.
rengolin added a comment. In http://reviews.llvm.org/D19604#420681, @jasonmolenda wrote: > fwiw, there are ARM cores that only support thumb - the Cortex M series. And they're still "armv7". :) Remember, "armv7" is *not* the same as ARMv7A+NEON. If the only thing you have is "armv7" or even "armv7-a", you *cannot* assume NEON is present. > The importance of the triple used will come in to play when you try to > evaluate an expression on the device -- lldb will call into llvm to parse/jit > the expression into machine code for the device. For instance, if > "arm-windows" translates to a minimum arm target, llvm may not think it has > any fp/NEON instructions. This is worrying. LLDB should *not* rely only on the triple, but all architectural options (mcpu/mtune/march/mfpu/mfloat-abi). Without it, it can infer very little, and obscure bugs will crop up if the meaning of the triple changes slightly in the future. > As for lldb disassembling as arm/thumb (or instruction emulation for > unwinding), today it doesn't use the CPSR/XPSR T bit to tell if the current > instruction is thumb or not, it depends on annotations in the symbol file to > do this correctly. I don't think it uses the 0th bit of saved pc values up > the stack to tell this either -- it is a pretty fixed model of depending on > the symbols to indicate whether they're arm or thumb. These are the easy cases. You still need both disassemblers to areas where you have no idea what it is (system binaries, etc.), where you have to try both and see which one has the least number of errors. :) cheers, --renato http://reviews.llvm.org/D19604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19604: Allow ObjectFilePECOFF to initialize with ARM binaries.
rengolin added a comment. In http://reviews.llvm.org/D19604#421086, @omjavaid wrote: > Right now we can distingusih between hard and soft float based on ABI > information in elf. But cant really tell if hard float is legacy VFP or neon. If the object has build attributes, it could help. But you also can't rely on it being there. http://reviews.llvm.org/D19604 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r269562 - [LLDB] Adding lldb_private namespace to DiagnosticSeverity. NFC.
Author: rengolin
Date: Sat May 14 08:14:39 2016
New Revision: 269562
URL: http://llvm.org/viewvc/llvm-project?rev=269562&view=rev
Log:
[LLDB] Adding lldb_private namespace to DiagnosticSeverity. NFC.
This is a fix due to the addition of the new DiagnosticSeverity in
LLVMContext.h. This may warrant a change in name to be LLDB specific
but I leave that to the LLDB experts to refactor.
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Modified:
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?rev=269562&r1=269561&r2=269562&view=diff
==
--- lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
(original)
+++ lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Sat May 14 08:14:39 2016
@@ -180,7 +180,7 @@ public:
diag_str.push_back('\0');
const char *data = diag_str.data();
-DiagnosticSeverity severity;
+lldb_private::DiagnosticSeverity severity;
bool make_new_diagnostic = true;
switch (DiagLevel)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:129 @@ +128,3 @@ +* The linear history can still be accessed in the (RO) submodule meta project, + Which will continue to have SVN access. + compnerd wrote: > "Which will continue to have SVN access" is redundant given the previous > statement. good point. I'll try and re-write those points to be more clear. Comment at: docs/Proposals/GitHub.rst:155 @@ +154,3 @@ +But some people/companies might not be allowed to use GitHub or might have +firewalls blocking certain websites. + compnerd wrote: > GitHub does have HTTPS based connections. It seems highly unlikely that this > is a real concern. Companies would have to go out of their way to block > access specifically to github over SSH and HTTPS. I have had this problem in China... Though no one has raised this issue, so I'll just remove and let people complain about this in the survey. Comment at: docs/Proposals/GitHub.rst:167 @@ +166,3 @@ +with the limited number of developers whose job will be to mainly merge +thousands of patches a day. + compnerd wrote: > I don't fully understand how this is any different from today. We have a > core set of developers with commit access. Others are encouraged to provide > patches via email (or may use phabricator depending on the reviewer). Once > reviewed and accepted, one of the core developers still commits the change. > I just see this as a process change. > > The person forks the repository on github, and creates a branch, and then a > PR. The PR is reviewed and once accepted, merged by one of the core > developers. It even implicitly handles authorship tracking which has > currently been done in an adhoc fashion via the commit message. Today we all commit to SVN, which is linear. In GitHub, we'll be committing to git. If we can have hooks forbidding merges, it'll remain linear, but then pull requests will be blocked. Additional hooks will need to be in place (please suggest all of them here and I'll update the doc). Comment at: docs/Proposals/GitHub.rst:222 @@ +221,3 @@ +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. compnerd wrote: > Giving permissions to only the LLVM "project" is sufficient. People can be > added to the LLVM "project" as collaborators and get access that way. This > is similar to how Apple is managing swift for comparison. That's what I meant but I will change the wording. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin removed rL LLVM as the repository for this revision. rengolin updated this revision to Diff 64334. rengolin added a comment. First round of changes reflecting reviews. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,230 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from Subversion +to GitHub. Below are the financial and technical arguments as to why we need +such a move and how will people (and validation infrastructure) continue to work +with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people stuck with SVN infrastructure and tooling can slowly migrate or +even stay working as if it was an SVN repository (including read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +How wil
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments.
Comment at: docs/Proposals/GitHub.rst:8-9
@@ +7,4 @@
+
+This is a proposal to move our current revision control system from Subversion
+to GitHub. Below are the financial and technical arguments as to why we need
+such a move and how will people (and validation infrastructure) continue to
work
emaste wrote:
> It seems pedantic, but I think we should try hard to avoid conflating Git and
> GitHub. What about: "move our revision control system from //self-hosted//
> Subversion to Git hosted by GitHub."
This is a summary of the whole proposal, which specifically dictates GitHub.
We're not proposing to move to some Git hosting anymore, but exactly GitHub,
due to the constraints that we outline below. If we do not move to GitHub
specifically, a lot of the assumptions below will be wrong, and this proposal
can't be accepted.
There is a paragraph on why git, and another on why GitHub, and both are key
points of this proposal.
I'll change "from Subversion" to "from our own hosted Subversion" to make that
even more clear.
Comment at: docs/Proposals/GitHub.rst:93
@@ +92,3 @@
+Furthermore, GitHub has an *SVN view*
(https://github.com/blog/626-announcing-svn-support)
+where people stuck with SVN infrastructure and tooling can slowly migrate or
+even stay working as if it was an SVN repository (including read-write access).
emaste wrote:
> Replace "stuck" with something neutral. "stuck" implies that everyone will
> want to move but some may not be able to for technical or other reasons, but
> some people actually prefer SVN.
good point.
Comment at: docs/Proposals/GitHub.rst:122
@@ +121,3 @@
+of understanding the *sequence* in which commits were added by using the
+``git rev-list --count hash`` or ``git describe hash`` commands.
+
filcab wrote:
> How easy will it be to clone the "aggregated" repo, and then get some (but
> not all) of the submodules?
Checking out this project:
https://github.com/chapuni/llvm-project-submodule
Will return the references, not the sub modules. You have to "init" each
sub-module independently, which achieves the same task as only checking out the
SVN repos you need, with the correct numbering.
Comment at: docs/Proposals/GitHub.rst:130
@@ +129,3 @@
+* Individual projects' history will be broken (linear, but local), and we need
+ the umbrella project (using submodules) to have the same view as we had in
SVN.
+
filcab wrote:
> I wouldn't call it broken.
> Won't it have the same end result as having a checkout per project and simply
> updating them close to each other?
>
> Basically, it won't be "any more broken" than using this method for updating:
>
> ```
> #!/bin/bash
> for dir in llvm/{,tools/{clang,lld},projects/{libcxx,libcxxabi,compiler-rt}};
> do
> # (cd $dir && svn up) # for SVN
> (cd $dir && git checkout master && git pull) # for git
> done
> ```
No, it won't.
Checking out LLVM only skips all commits from all other repos. So, for example:
LNT 123
Clang 124
RT 125
LLVM 126
Then, "svn checkout 126" will be:
In LNT, 123 as 126
In Clang, 124 as 126
In RT, 125 as 126
In LLVM, 126 as 126
With the new SVN interface, each one of those commits will be referred to,
locally, as 123, and 126 will not exist, because the "git rev-list --count"
won't get as high as 126.
However, on the umbrella submodule project, because the sequence of the commits
is guaranteed, the rev-list count will bring the correct numbering, the same as
via the SVN interface, and thus be "just like SVN was".
Comment at: docs/Proposals/GitHub.rst:132
@@ +131,3 @@
+
+There is no need to additional tags, flags and properties, nor of external
+services controlling the history, since both SVN and *git rev-list* can already
winksaville wrote:
> This could be worded a little better, may I suggest something like:
>
> "There is no need for additional tags, flags, properties, or external ..."
>
Yup, changing on next round. Thanks!
Comment at: docs/Proposals/GitHub.rst:141
@@ +140,3 @@
+has commit access to our current repository. In the future, you only need to
+provide the GitHub user to be granted access.
+
probinson wrote:
> This reads a little bit like "we will create a GitHub account for you if you
> don't have one" but I suspect people actually need to create their own GitHub
> accounts first. (We're not all on GitHub already!)
well, "you need to provide the GitHub user" should take care of that, but I'll
try to re-write this to make it more clear.
> (We're not all on GitHub already!)
Are we not? Egregious! :D
Comment at: docs/Proposals/GitHub.rst:180
@@ +179,3 @@
+
+As soon as we decide to move, we'll have to set a date for the process to
begin.
+
emaste wrote:
> This presents it
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64371. rengolin added a comment. Second round of suggestions applied. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,239 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +How will the new workflow look like +=
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:198 @@ +197,3 @@ +3. Make sure we have an llvm-project (with submodules) setup in the official + account. +4. Make sure bisecting with llvm-project works. mehdi_amini wrote: > Uh, this point is not clear: there will a need for us to maintain a > "non-trivial" hook on our server to handle this. This is not fleshed out in > this document. Good point. I added just a description to this topic, since this is covered elsewhere. Comment at: docs/Proposals/GitHub.rst:174 @@ +173,3 @@ +us what's wrong and how to help them fix it. + +We also recommend people and companies to migrate to Git, for its many other So, LNT migration plan could be: 1. Use GitHub's SVN view on llvm-proj-submods 2. Move to understand submods 3. Migrate all instances Looks fairly orthogonal to me... https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64373. rengolin added a comment. Removing "broken" to describe the history, just explaining it'll be local. Expanding to mention that hooks will need to be implemented in step 3. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,240 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the m
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:200 @@ +199,3 @@ + +Here's a proposed plan: + You can click on the "<<" button and it will show where it was first inserted. That's how I found out. :) The hooks, AFAICS, will be added to the project initially, and won't need to be updated. Takumi's current repository is automatically updated, and IIRC, it's just a hook. Assuming it's atomic and quick enough, would this process make much of a difference to the users? https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:208 @@ +207,3 @@ +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). +4. Make sure bisecting with llvm-project works. mehdi_amini wrote: > I'd like to see clearly mentioned somewhere else than in the plan that on top > of "hooks" hosted by github, we will need to maintain our own webservice on > our own server to answer updates from theses hooks and update the umbrella. > That's a non-negligible drawback in face of the motivation exposed in the > "Why move at all?" section. There are two types of hooks: 1. Pre-commit hooks that will stop anyone trying to merge/force push commits to the projects, in order to keep the history clean. These are install once, use forever. Zero maintenance after the initial period. 2. Post-commit hooks on the other projects / OR / external webservice/buildbot that will update the umbrella project like any existing Git mirror. Maintenance of this is either free (hooks) or very cheap (buildbot/cron jobs). On both cases, the history is preserved at least within the update cycle, which shouldn't be more than 5 minutes, and will be the update cycle that buildbots will pick the commits anyway. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64383. rengolin added a comment. Expand step 2 to make sure we don't forget about the safety hooks on each project as well as the webhook to update the umbrella project. This could turn out to be a buildbot, but makes no difference at this stage. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,242 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:209 @@ +208,3 @@ + well as a webhook to update the umbrella project (see below). +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). mehdi_amini wrote: > > Pre-commit hooks > > Won't handle the update of the umbrella. > > > Post-commit hooks > > Can't handle the update of the umbrella *because of GitHub*, this could be > possible with our own hosting of git for instance. > Pre-commit hooks are not designed to update the umbrella. Webhooks will be able to update the umbrella with a small external service, as proposed in the IRC. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin created this revision. rengolin added reviewers: lattner, chandlerc, jyknight, mehdi_amini, MatzeB, probinson, t.p.northover, chapuni, delcypher, dberlin, rsmith, beanz, cmatthews, asl, aaron.ballman, bcraig, Bigcheese, jroelofs, theraven, greened, hong.gyu.kim, rafael, AlexDenisov, silvas, friss, rovka, rnk. rengolin added subscribers: llvm-commits, cfe-commits, lldb-commits. rengolin set the repository for this revision to rL LLVM. This is a draft on the proposal to moving to GitHub. Once we agree if this is a good proposal, we'll create the survey to get the final and complete intent of the community and act on it. *THIS IS NOT TO AGREE ON THE DECISION*, but only to agree on the proposal, which will then fuel the decision survey. Please, avoid arguments against Git or GitHub in this review. You'll have the opportunity to do so in the survey. Dates and times can be agreed later, but we're probably looking to a 6 month period anyway. I tried to include everyone I found in Phab that was on one of the discussions, but I may have missed a few. Feel free to add more people to it, but let's try to get a reasonable agreement to the proposal (not the move) under two weeks. Repository: rL LLVM https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,231 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from Subversion +to GitHub. Below are the financial and technical arguments as to why we need +such a move and how will people (and validation infrastructure) continue to work +with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *FREE*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space, multiple concurrent builds + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirr
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. Comment at: docs/Proposals/GitHub.rst:127 @@ +126,3 @@ +* The projects' repositories will remain identical, with a new address (GitHub). +* They'll continue to have SVN RW access, but will also gain Git RW access. +* The linear history can still be accessed in the (RO) submodule meta project, jroelofs wrote: > Do you mean `s/SVN RW access/SVN RO access/` here? No, I actually mean SVN RW access. GitHub's SVN view does allow write access to the Git repos via "svn commit". Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ +Essentially, we're adding Git RW access in addition to the already existing +structure, with all the additional benefits of it being in GitHub. + jroelofs wrote: > Need to clarify here whether *write* access through SVN will be going away. > If I understand the proposal correctly, it will go away, but this section > makes it sound like it's staying. Our SVN server will die, SVN access will continue via GitHub. Repository: rL LLVM https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64467. rengolin added a comment. More updates, following recent comments. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,253 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + + * Outline of the reasons to move to Git and GitHub + * Description on how the work flow will look like (compared to SVN) + * Remaining issues and potential problems + * The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *free*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + * Commit, squash, merge, fork locally without any penalty to the server + * Add as many branches as necessary to allow for multiple threads of development + * Collaborate with peers directly, even without access to the Internet + * Have multiple trees without multiplying disk space. + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide free code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and equality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +What will the new workflow look like +==
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added inline comments. 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 + vsk wrote: > What do you mean by multiple concurrent builds? With git worktree you can work on source code and build different things at the same time, but I guess this is a specific use case which is only made "easier" in git. I'll remove this extra comment. Comment at: docs/Proposals/GitHub.rst:78 @@ +77,3 @@ + +GitHub, like GitLab and BitBucket, provide FREE code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that dberris wrote: > nit: I see you use FREE in caps but this instance isn't *FREE* (as opposed to > the first mention above) -- consider making it consistent? Either remove the > emphasis (just "free") or emphasise consistently? good point. Comment at: docs/Proposals/GitHub.rst:86 @@ +85,3 @@ +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and quality in our community. + dberris wrote: > Did you mean "diversity and equality" instead of "diversity and quality" here? indeed, fixed. Comment at: docs/Proposals/GitHub.rst:102 @@ +101,3 @@ + +How will the new workflow look like +=== delcypher wrote: > s/How will/What will/ ok Comment at: docs/Proposals/GitHub.rst:110-112 @@ +109,5 @@ + +As with the current SVN and Git repositories, each project will be separate, +on its own, and people will also be able to check them out in the same way +they're already doing today. + dberris wrote: > Consider rewording this sentence -- it's a little too long and is trying to > say too many things. > > Perhaps something like: > > "Each LLVM project will continue to be hosted as separate GitHub repositories > under a single GitHub organisation. Users can continue to choose to use > either SVN or Git to access the repositories to suit their current workflow." Much better, thanks! Comment at: docs/Proposals/GitHub.rst:136 @@ +135,3 @@ + +We will need additional server hooks to avoid non-fast-forwards commits (ex. +merges, forced pushes, etc) in order to keep the linearity of the history. delcypher wrote: > @rengolin : I know GitHub enterprise has a "protected branch" feature to > prevent forced pushed ( > https://github.com/blog/2051-protected-branches-and-required-status-checks ). > You might want to speak to them to see if they can offer us that feature. I > think there's a limited support to do a merge as a squash and rebase too ( > https://github.com/blog/2141-squash-your-commits ) I'm asking about protected branches (it was proposed earlier, but I can't find any info on it). But we don't want to squash people's commits. They can do that on their own before commit. Comment at: docs/Proposals/GitHub.rst:185 @@ +184,3 @@ + +Are there any other upstream systems that could be affected? + dberris wrote: > vsk wrote: > > 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? > Probably worth mentioning how Phabricator will need to be updated to > integrate with the GitHub repository once the canonical repo is changed. Adding llvmlab bisect and Phab to the list. Both should be trivial. Comment at: docs/Proposals/GitHub.rst:209 @@ +208,3 @@ + well as a webhook to update the umbrella project (see below). +3. Make sure we have an llvm-project (with submodules) setup in the official + account, with all necessary hooks (history, update, merges). jyknight wrote: > mehdi_amini wrote: > > rengolin wrote: > > > mehdi_amini wrote: > > > > > Pre-commit hooks > > > > > > > > Won't handle the update of the umbrella. > > > > > > > > > Post-commit hooks > > > > > > > > Can't handle the update of the umbrella *because of GitHub*, this could > > > > be possible with our own hosting of git for instance. > > > > > > > Pre-commit hooks are not designed to update the umbrella. Webhooks will > > > be able to update the umbrella with a small external service, as proposed > > > in the IRC. > > That's why I asked it to be clearly mentioned somewhere else that on top of > > "hooks" hosted by github, we will need to maintain our own webservice on > > our own server to answer updates from theses hooks and update the umbrella, > > because that's a non-negligible drawback in face of the motivation exposed > > in the "Why move at all?" section. > > Right now the document doe
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64468. rengolin added a comment. Formatting issues (bullet points) https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,253 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + +* Outline of the reasons to move to Git and GitHub +* Description on what the work flow will look like (compared to SVN) +* Remaining issues and potential problems +* The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *free*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: +* Commit, squash, merge, fork locally without any penalty to the server +* Add as many branches as necessary to allow for multiple threads of development +* Collaborate with peers directly, even without access to the Internet +* Have multiple trees without multiplying disk space. + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide free code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and equality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +What will the new workflow look like + + +
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin updated this revision to Diff 64469. https://reviews.llvm.org/D22463 Files: docs/Proposals/GitHub.rst Index: docs/Proposals/GitHub.rst === --- /dev/null +++ docs/Proposals/GitHub.rst @@ -0,0 +1,254 @@ +== +Moving LLVM Projects to GitHub +== + +Introduction + + +This is a proposal to move our current revision control system from our own +hosted Subversion to GitHub. Below are the financial and technical arguments as +to why we need such a move and how will people (and validation infrastructure) +continue to work with a Git-based LLVM. + +There will be a survey pointing at this document when we'll know the community's +reaction and, if we collectively decide to move, the time-frames. Be sure to make +your views count. + +Essentially, the proposal is divided in the following parts: + +* Outline of the reasons to move to Git and GitHub +* Description on what the work flow will look like (compared to SVN) +* Remaining issues and potential problems +* The proposed migration plan + +Why Git, and Why GitHub? + + +Why move at all? + + +The strongest reason for the move, and why this discussion started in the first +place, is that we currently host our own Subversion server and Git mirror in a +voluntary basis. The LLVM Foundation sponsors the server and provides limited +support, but there is only so much it can do. + +The volunteers are not Sysadmins themselves, but compiler engineers that happen +to know a thing or two about hosting servers. We also don't have 24/7 support, +and we sometimes wake up to see that continuous integration is broken because +the SVN server is either down or unresponsive. + +With time and money, the foundation and volunteers could improve our services, +implement more functionality and provide around the clock support, so that we +can have a first class infrastructure with which to work. But the cost is not +small, both in money and time invested. + +On the other hand, there are multiple services out there (GitHub, GitLab, +BitBucket among others) that offer that same service (24/7 stability, disk space, +Git server, code browsing, forking facilities, etc) for the very affordable price +of *free*. + +Why Git? + + +Most new coders nowadays start with Git. A lot of them have never used SVN, CVS +or anything else. Websites like GitHub have changed the landscape of open source +contributions, reducing the cost of first contribution and fostering +collaboration. + +Git is also the version control most LLVM developers use. Despite the sources +being stored in an SVN server, most people develop using the Git-SVN integration, +and that shows that Git is not only more powerful than SVN, but people have +resorted to using a bridge because its features are now indispensable to their +internal and external workflows. + +In essence, Git allows you to: + +* Commit, squash, merge, fork locally without any penalty to the server +* Add as many branches as necessary to allow for multiple threads of development +* Collaborate with peers directly, even without access to the Internet +* Have multiple trees without multiplying disk space. + +In addition, because Git seems to be replacing every project's version control +system, there are many more tools that can use Git's enhanced feature set, so +new tooling is much more likely to support Git first (if not only), than any +other version control system. + +Why GitHub? +--- + +GitHub, like GitLab and BitBucket, provide free code hosting for open source +projects. Essentially, they will completely replace *all* the infrastructure that +we have today that serves code repository, mirroring, user control, etc. + +They also have a dedicated team to monitor, migrate, improve and distribute the +contents of the repositories depending on region and load. A level of quality +that we'd never have without spending money that would be better spent elsewhere, +for example development meetings, sponsoring disadvantaged people to work on +compilers and foster diversity and equality in our community. + +GitHub has the added benefit that we already have a presence there. Many +developers use it already, and the mirror from our current repository is already +set up. + +Furthermore, GitHub has an *SVN view* (https://github.com/blog/626-announcing-svn-support) +where people that still have/want to use SVN infrastructure and tooling can +slowly migrate or even stay working as if it was an SVN repository (including +read-write access). + +So, any of the three solutions solve the cost and maintenance problem, but GitHub +has two additional features that would be beneficial to the migration plan as +well as the community already settled there. + + +What will the new workflow look like + + +In order to move version control, we need to make sure that
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added a comment. You will not be required to use submodules at all, as we'll all use the individual projects, like we have always been. I don't understand why people keep going back to it. Having a single repository was part of the original proposal for years, and every time it was shot down as impractical. Indeed, this is not the place for such discussion, but unless you can finish the discussion thus week, I suggest you make you point clear in the survey instead of delaying the process. I'm not pushing for *my* solution. Thus *has* been discussed already to exhaustion. The current agreement was that we'd do a survey on the proposal, and that's what we need to do. Anything else will just send us back to square one and I seriously don't have the stamina to keep going round in circles. Ie. Please, try to be considerate. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin added a comment. In https://reviews.llvm.org/D22463#489483, @jlebar wrote: > Again, we can make this work with submodules, but it's a giant pain, see my > earlier comment. (...) > I've read as many of these as I can find in the past few hours, and every > argument I have found is, in my evaluation, very likely overblown or > incorrect. We've heard both sides making equal claims. People work differently. > The critical point is that it's trivial to use sparse checkouts to make the > monolithic repository behave identically to separate repos. But it is > impossible, as far as I'm aware, to make separate repos behave like a > monolithic repository. So the monolithic repository is strictly more > powerful. LLVM is *not* a single project, but a large selection of smaller ones that *are* used independently by the *majority* of users. It may tax you more than others, but it will tax the majority less than today's solution. This is not about finding the best possible way for everyone, since that's clearly impossible. This is about finding the least horrible solution for the majority. > The e-mail you sent out two days ago said two weeks. Can you give me a bit > more than three days? Moving to Git has been in discussion for at least 2 years. This time round, my first email with a concrete proposal to migrate was 2nd June. We had so far 320+ emails about the subject since, and the overwhelming majority is in favour to move to Git and a large part is *content* with sub-modules. Counter proposals were presented (including a monolithic repository) and were all shot down by the community (not me). This is not the time to be second guessing ourselves. I'll be finishing this proposal this week and asking the foundation to put up a survey as soon as possible. > But. I would ask you to please give me a few days to work with the community > to dig in to this specific question. If I am right, it will be a boon for > all of us every time we type a command that starts with "git". And if I'm > wrong, I'll buy you a well-deserved beer or three, and we'll forget it and > move on. A monolithic repository was proposed and discredited by the community. I can't vouch for it myself (in the interest of progress), but we *will* allow people to add comments on the survey. If there is a sound opposition to sub-modules in the survey, and a solid proposal to use a monolithic repo instead, we'll go to the next cycle, in which case, I'll politely step down and let other people in charge (whomever wants it). All in all, we (for any definition of "we") are not going to force anyone to do anything they don't want. But as a community, we really should be thinking about the whole process, not just a single use case. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22463: [RFC] Moving to GitHub Proposal: NOT DECISION!
rengolin accepted this revision. rengolin added a reviewer: rengolin. rengolin added a comment. This revision is now accepted and ready to land. I'm auto accepting this proposal, as it seems to have ran its course. The commit is r276097. If anyone has any additional comment/suggestion, please submit a new review. https://reviews.llvm.org/D22463 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added inline comments. Comment at: source/Core/ArchSpec.cpp:1017 @@ +1016,3 @@ +// considered to be compatible. This is required as a workaround for shared libraries compiled +// for Android without the NOTE section indicating that they are using the Android ABI. +if (lhs == llvm::Triple::Android && (rhs == llvm::Triple::EABI || rhs == llvm::Triple::EABIHF)) Are you sure AndroidEabi and EabiHF are compatible? Android is always soft-float, is it not? http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added a comment. Don't Android libraries output build attributes for ARM? If they do, that's an easy way to know. http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added a comment. In http://reviews.llvm.org/D19480#410620, @tberghammer wrote: > Both executables and shared libraries are containing ARM Attributes what > contains the information about soft-float vs hard-float. I am not sure how > accurate it is as in theory you can link together an object file compiled > with soft float with a one compiled with hard float but most likely we can > trust it to be good enough. That's only true if one doesn't depend on the other, and only if you can guarantee that hard-float library functions will only be called using AAPCS_VFP and soft-float library functions will only be called with AAPCS. This is not the kind of guarantee one can do easily. Nor it is recommended that one does so. If Android applications can guarantee that by having two different ABIs for Android specific and user specific, this could work in theory. > The problem is that currently this information is not stored in the > llvm::Triple so if the Environment part of the Triple is set to Android then > the information is lost. I can try to recover the data from the architecture > flags but I am not convinced that it is always possible and considering that > the same executable can contain soft-float and hard-float code on Android we > have to treat them as compatible architectures at some point. The information is not lost, because "Android EABI" is always soft-float, and by definition, you should not be linking hard-float objects with soft-float ones. Can you elaborate which case you can reach that improbably scenario? cheers, --renato http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291
rengolin added a comment. In http://reviews.llvm.org/D19480#410762, @tberghammer wrote: > I committed in this change based on the approval from @labath with the > Android - EABI support (no hard float) to get the LLDB Android ARM buildbots > green again. If you have any more question comment then please let me know > and I am happy to address them with a separate commit. Sounds good, thanks! Repository: rL LLVM http://reviews.llvm.org/D19480 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [MLIR] Enabling Intel GPU Integration. (PR #65539)
rengolin wrote: > At some point it would be nice to have some design document or documentation > somewhere explaining how all these MLIR runners works, including this one. The idea is to eventually consolidate all runners into one. This PR is just another piece of the puzzle. Once we're all happy with how the runners work, we should common them up using command line options to select the "type" and CMake options to enable particular runner types (depending on the runtimes and hardware available). > Globally this PR add a SYCL runner, but it is very specific for Intel Level > 0. It would be nice to have in the future some generalization, like SYCL > using OpenCL interoperability interface to run the SPIR-V kernels or even > native kernels. Agreed! The SYCL runtime here is just being used to abstract the LevelZero calls, but this work will be helpful when adding a full SYCL runner (actual language extensions and libraries) to other CPUs/GPUs later. https://github.com/llvm/llvm-project/pull/65539 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [MLIR] Enabling Intel GPU Integration. (PR #65539)
rengolin wrote: CI failure looks like Buildkite issue? ``` $ /etc/buildkite-agent/hooks/pre-checkout -- | BUILDKITE_REPO: https://github.com/llvm/llvm-project.git | fatal: not a git repository (or any parent up to mount point /var/lib) | Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). | 🚨 Error: The global pre-checkout hook exited with status 128 ``` https://github.com/llvm/llvm-project/pull/65539 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)
rengolin wrote: > Is this suggestion correct? Doesn't look right to me. I seems it's suggesting 4 spaces tabs, which isn't what we normally use. Something wrong with the clang-format job, maybe? @tru @tstellar https://github.com/llvm/llvm-project/pull/65744 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)
rengolin wrote: > @tru I'd ask @AaronBallman. My vote would be to reformat. Not as a requirement for this patch, I imagine? https://github.com/llvm/llvm-project/pull/65744 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
