[lldb-dev] LLVM at FOSDEM 2016 - Call for papers and participation
CALL FOR PAPERS / PARTICIPATION At FOSDEM 2016, LLVM will for the first time participate with a dedicated devroom. Complementing the upcoming Euro LLVM 2015, the devroom at FOSDEM provides a great opportunity for core LLVM developers and the wider open source community to get together, connect and discuss. As possibly the largest European Open Source Conference, FOSDEM takes place in Brussels and attracts with more than 400 lectures every year over 5000 hackers - many core contributors of the worlds leading open source projects. = Call for Speakers, Posters, Demos = We invite academic, industrial and hobbyist speakers to present their work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. We are looking for: 1. Keynote speakers. 2. Technical presentations (30 minutes plus questions and discussion) related to development of LLVM, Clang etc. 3. Presentations about the use of LLVM, Clang in commercial or academic projects as well as in the open source world. 4. Tutorials 5. Lightning talks (5 minutes) The deadline for receiving submissions is December 1st, 2015. Speakers will be notified of acceptance or rejection by the 15th of December. Proposals that are not sufficiently detailed (talks lacking a comprehensive abstract for example) are likely to be rejected. Please create an account on the FOSDEM interface ( https://penta.fosdem.org/user/new_account ) and submit your proposal ( https://penta.fosdem.org/submission/FOSDEM16/event/new ). Please make sure you select "LLVM devroom" as the "Track". = Registration = FOSDEM does not require any registration and is free of charge. However, just like last year, an important crowd must be expected. = Organization = The mailing list llvm-devr...@lists.fosdem.org can be used to discuss issues of general interest related to the conference organization. = Financial Support = There may be a possibility of limited funding to help students or contributors who could not otherwise attend the conference. This will depend on overall sponsorship and companies' interest in supporting the event. If you need funding to attend the meeting, or can help sponsor, please tell us on llvm-devr...@lists.fosdem.org. = About LLVM = LLVM is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyse and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run-time, or "idle-time" (between program runs). The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. Besides LLVM, several projects have been developed on top of it like Clang, LLDB, LLD or Polly. For more information, please visit http://llvm.org/ or the conference webpage at http://llvm.org/devmtg/2016-01/ Tobias Grosser, Sylvestre Ledru & Renato Golin ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM at FOSDEM 2016 - Call for papers and participation
Gentle reminder, the deadline is approaching. On 2 November 2015 at 13:32, Renato Golin wrote: > CALL FOR PAPERS / PARTICIPATION > > At FOSDEM 2016, LLVM will for the first time participate with a > dedicated devroom. Complementing the upcoming Euro LLVM 2015, the > devroom at FOSDEM provides a great opportunity for core LLVM developers > and the wider open source community to get together, connect and discuss. > > As possibly the largest European Open Source Conference, FOSDEM takes > place in Brussels and attracts with more than 400 lectures every year > over 5000 hackers - many core contributors of the worlds leading open > source projects. > > > = Call for Speakers, Posters, Demos = > > We invite academic, industrial and hobbyist speakers to present their > work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. > > We are looking for: > > 1. Keynote speakers. > 2. Technical presentations (30 minutes plus questions and discussion) > related to development of LLVM, Clang etc. > 3. Presentations about the use of LLVM, Clang in commercial or > academic projects as well as in the open source world. > 4. Tutorials > 5. Lightning talks (5 minutes) > > The deadline for receiving submissions is December 1st, 2015. Speakers > will be notified of acceptance or rejection by the 15th of December. > Proposals that are not sufficiently detailed (talks lacking a > comprehensive abstract for example) are likely to be rejected. > > Please create an account on the FOSDEM interface ( > https://penta.fosdem.org/user/new_account ) and submit your proposal > ( https://penta.fosdem.org/submission/FOSDEM16/event/new ). > Please make sure you select "LLVM devroom" as the "Track". > > > = Registration = > > FOSDEM does not require any registration and is free of charge. However, > just like last year, an important crowd must be expected. > > > = Organization = > > The mailing list llvm-devr...@lists.fosdem.org can be used to discuss > issues of general interest related to the conference organization. > > > = Financial Support = > > There may be a possibility of limited funding to help students or > contributors who could not otherwise attend the conference. This will > depend on overall sponsorship and companies' interest in supporting the > event. > > If you need funding to attend the meeting, or can help sponsor, please > tell us on llvm-devr...@lists.fosdem.org. > > > = About LLVM = > > LLVM is a collection of libraries and tools that make it easy to build > compilers, optimizers, Just-In-Time code generators, and many other > compiler-related programs. LLVM uses a single, language-independent > virtual instruction set both as an offline code representation (to > communicate code between compiler phases and to run-time systems) and as > the compiler internal representation (to analyse and transform > programs). This persistent code representation allows a common set of > sophisticated compiler techniques to be applied at compile-time, > link-time, install-time, run-time, or "idle-time" (between program runs). > > The strengths of the LLVM infrastructure are its extremely simple design > (which makes it easy to understand and use), source-language > independence, powerful mid-level optimizer, automated compiler debugging > support, extensibility, and its stability and reliability. LLVM is > currently being used to host a wide variety of academic research > projects and commercial projects. > > Besides LLVM, several projects have been developed on top of it like > Clang, LLDB, LLD or Polly. > > For more information, please visit http://llvm.org/ or the conference > webpage at http://llvm.org/devmtg/2016-01/ > > > Tobias Grosser, Sylvestre Ledru & Renato Golin ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM at FOSDEM 2016 - Call for papers and participation
Good news, folks! Following FOSDEM's own delay on their schedule, we'll extend the deadline until next Friday, 11th December. cheers, --renato On 2 November 2015 at 13:32, Renato Golin wrote: > CALL FOR PAPERS / PARTICIPATION > > At FOSDEM 2016, LLVM will for the first time participate with a > dedicated devroom. Complementing the upcoming Euro LLVM 2015, the > devroom at FOSDEM provides a great opportunity for core LLVM developers > and the wider open source community to get together, connect and discuss. > > As possibly the largest European Open Source Conference, FOSDEM takes > place in Brussels and attracts with more than 400 lectures every year > over 5000 hackers - many core contributors of the worlds leading open > source projects. > > > = Call for Speakers, Posters, Demos = > > We invite academic, industrial and hobbyist speakers to present their > work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. > > We are looking for: > > 1. Keynote speakers. > 2. Technical presentations (30 minutes plus questions and discussion) > related to development of LLVM, Clang etc. > 3. Presentations about the use of LLVM, Clang in commercial or > academic projects as well as in the open source world. > 4. Tutorials > 5. Lightning talks (5 minutes) > > The deadline for receiving submissions is December 1st, 2015. Speakers > will be notified of acceptance or rejection by the 15th of December. > Proposals that are not sufficiently detailed (talks lacking a > comprehensive abstract for example) are likely to be rejected. > > Please create an account on the FOSDEM interface ( > https://penta.fosdem.org/user/new_account ) and submit your proposal > ( https://penta.fosdem.org/submission/FOSDEM16/event/new ). > Please make sure you select "LLVM devroom" as the "Track". > > > = Registration = > > FOSDEM does not require any registration and is free of charge. However, > just like last year, an important crowd must be expected. > > > = Organization = > > The mailing list llvm-devr...@lists.fosdem.org can be used to discuss > issues of general interest related to the conference organization. > > > = Financial Support = > > There may be a possibility of limited funding to help students or > contributors who could not otherwise attend the conference. This will > depend on overall sponsorship and companies' interest in supporting the > event. > > If you need funding to attend the meeting, or can help sponsor, please > tell us on llvm-devr...@lists.fosdem.org. > > > = About LLVM = > > LLVM is a collection of libraries and tools that make it easy to build > compilers, optimizers, Just-In-Time code generators, and many other > compiler-related programs. LLVM uses a single, language-independent > virtual instruction set both as an offline code representation (to > communicate code between compiler phases and to run-time systems) and as > the compiler internal representation (to analyse and transform > programs). This persistent code representation allows a common set of > sophisticated compiler techniques to be applied at compile-time, > link-time, install-time, run-time, or "idle-time" (between program runs). > > The strengths of the LLVM infrastructure are its extremely simple design > (which makes it easy to understand and use), source-language > independence, powerful mid-level optimizer, automated compiler debugging > support, extensibility, and its stability and reliability. LLVM is > currently being used to host a wide variety of academic research > projects and commercial projects. > > Besides LLVM, several projects have been developed on top of it like > Clang, LLDB, LLD or Polly. > > For more information, please visit http://llvm.org/ or the conference > webpage at http://llvm.org/devmtg/2016-01/ > > > Tobias Grosser, Sylvestre Ledru & Renato Golin ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] Schedule and call for testers
Sounds good. On 11 December 2015 at 23:14, Hans Wennborg wrote: > Dear everyone, > > It's not quite time to start the 3.8 release process, but it's time to > start planning. > > Please let me know if you want to help with testing and building > release binaries for your favourite platform. (If you were a tester on > the previous release, you're cc'd on this email.) > > I propose the following schedule for the 3.8 release: > > - 13 January: Create 3.8 branch. Testing Phase 1: RC1 binaries built > and tested, bugs fixed. Any almost-complete features need to be > wrapped up or disabled on the branch ASAP, and definitely before this > phase ends. > > - 27 January: Testing Phase 2: RC2 binaries built and tested. Only > critical bug fixes from now on. Further RCs published as we approach.. > > - 18 February: Cut the final release, build binaries, ship when ready. > > Unless there are any objections, I'll post this on the web page. > > Cheers, > Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.8 Release] We have branched
Hans, Daniel, How are things going? It's been 5 days and no word. I'm running the tests now, just in case, but would be good to know that no one would be committing to the release candidate 1 tree in the mean time. cheers, --renato On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev wrote: >> -Original Message- >> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf >> Of Hans Wennborg >> Sent: 15 January 2016 15:52 >> To: Daniel Sanders >> Cc: llvm-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; cfe- >> d...@lists.llvm.org >> Subject: Re: [cfe-dev] [3.8 Release] We have branched >> >> Hi Daniel, >> >> Thanks for trying out the branch :-) >> >> On Fri, Jan 15, 2016 at 5:30 AM, Daniel Sanders >> wrote: >> > Hi Hans, >> > >> > I tried the release branch last night and I'm having problems building it. >> > The >> problem is that test-suite is now building as part of the Phase[123] builds >> (because this project contains CMakeLists.txt's now) but cmake 3.0.2 (from >> Debian Jessie) generates an invalid Makefile. >> > The error is: >> > CMakeFiles/test-suite.dir/build.make:112: *** target pattern >> > contains >> no '%'. Stop. >> > CMakeFiles/Makefile2:199: recipe for target 'CMakeFiles/test- >> suite.dir/all' failed >> > And the referenced line of the generated makefile is: >> > test-suite-stamps/test-suite-force-rebuild: /home/das-local/llvm- >> release-3.8/release/branches_release_38/llvm.src/$ >> > it looks like cmake isn't fully expanding its generator expressions. >> > >> > Looking at my logs, it looks like the test-suite used to configure in >> > 3.6.2 but >> didn't build as part of test-release.sh and then 3.7.0 stopped since we had >> switched to cmake and there was no CMakeLists.txt. >> > I've always run the test-suite as a separate step as described in >> http://llvm.org/docs/ReleaseProcess.html. Should we stop creating the >> projects/test-suite symlink to get back to the behaviour from 3.7.0 or should >> we do something else? >> >> Yes, I made the script stop making the symlink in r257791 and merged >> it to the branch. Did that not work for you, or were you at an earlier >> revision? >> >> Thanks, >> Hans > > I'm at r257773 so it looks like I didn't pick up that change. I'll give it > another try tonight. > > Thanks > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.8 Release] We have branched
On 20 January 2016 at 17:49, Hans Wennborg wrote: > Did you send this before I sent the rc1 email, or what things are you > referring to? :-) Damn it, my filter isn't working as well as I expected! :) Sorry about the noise. --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] RC1 has been tagged
ARM and AArch64 seem both good. Uploaded. On 19 January 2016 at 23:47, Hans Wennborg wrote: > Dear testers, > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at > r258223. (It took a little longer than I'd planned, sorry about that.) > > There are still a bunch of open merge requests and bug reports, but I > wanted to get the tag in so we can see what the build and test status > are on the various platforms. > > I verified that it currently builds and tests cleanly for me on x86_64 > Linux, Mac OS X* and Windows. > > Please build, test, and upload binaries to the sftp. Let me know if how it > goes. > > Thanks, > Hans > > > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`" > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work, > otherwise stage-2 Clang couldn't find the SDK. I don't remember if I > had to do this last time; maybe some upgrade changed something. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] RC1 has been tagged
On 20 January 2016 at 09:31, Sylvestre Ledru wrote: > What about creating a release management mailing list ? > The testers are usually the same (hello folks!) :) I second that! It'd also be much easier on mail filters... :) --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] RC2 has been tagged
On 2 February 2016 at 21:15, Hans Wennborg via lldb-dev wrote: > Dear testers, > > Release Candidate 2 has just been tagged [1]. Please build, test, and > upload to the sftp. ARM and AArch64 look good, uploaded. I'm not using any new distro, so all the ABI issues are not showing, but they do exist in ARM/AArch64. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] FOSDEM slides online
Hi folks, FOSDEM was a great success, with the room packed most of the time and some great talks. The slides were uploaded to the web page (http://llvm.org/devmtg/2016-01/) but the videos unfortunately couldn't be used (they had no audio). Due to the voluntary nature of FOSDEM, these things can and do happen, so if you want to know more about a particular presentation, I recommend you contact the original author, hopefully copying the list, so that further discussions can progress in the open. I'd like to thank Sylvestre, Arnaud, Kristof and Tobias for helping with the organization, and all the presenters for their high quality talks, and see you all again next year! cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.8 Release] Release Candidate 2 source and binaries available
On 6 February 2016 at 01:02, C Bergström wrote: > I worked on the port of llvm-OpenMP-formally-known-as-Intel to Aarch64 > - can it be included there as well? (I'm not sure what's precisely > involved - I'm willing to do my best fixing any bugs which pop up - Hi Chris, That'd entail me enabling them for AArch64. I have to say, I've done that a few months ago and it all went smoothly, but I didn't know anyone was interested (and there were some failures in the OMP tests). I can enable them on the next release candidate and keep them on for the next releases, but I can't support it myself, so if you're willing to handle that, I'm ok with releasing them. Also, it's not trivial to run the OMP tests, making it a bit harder to monitor regressions between releases. For now, I'll just build them and hope you or someone can spot regressions, but ultimately, it'd be good to have it as part of the release process, maybe inside the test-suite? cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.8 Release] Release Candidate 2 source and binaries available
On 8 February 2016 at 22:56, wrote: > Imho it's critical to get parallel programming working on ARMv8 ( even if > it's crappy OMP) to start. Please enable it and I'll run the tests against > our internal QA and we can informally handle testing / guarding against > regressions. Ok, I'll do it with rc3. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] Release status
On 19 February 2016 at 00:22, Hans Wennborg via lldb-dev wrote: > - PR26600: Loop vectorization creates an unsafe out-of-bounds load > There's a patch out: http://reviews.llvm.org/D17332 > But no comments yet.. Hal? This looks like a serious bug but Hal's idea is still unproven. I think we should land the patch as it is, since it disables the bad behaviour, and think about a fix later. Depending on how complex the fix is, we might not even merge it into 3.8.x later on, but we need the fix in 3.8.0. > - ARM: fix VFP asm constraints: http://reviews.llvm.org/D17349 > It's not a regression, but I'll take it if it lands real soon. No brainer. Accepted on trunk by compnerd, I'll merge into release_38 shortly. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] Release status
On 19 February 2016 at 15:33, Renato Golin wrote: > On 19 February 2016 at 00:22, Hans Wennborg via lldb-dev > wrote: >> - PR26600: Loop vectorization creates an unsafe out-of-bounds load >> There's a patch out: http://reviews.llvm.org/D17332 >> But no comments yet.. Hal? > > This looks like a serious bug but Hal's idea is still unproven. I > think we should land the patch as it is, since it disables the bad > behaviour, and think about a fix later. Depending on how complex the > fix is, we might not even merge it into 3.8.x later on, but we need > the fix in 3.8.0. r261341. >> - ARM: fix VFP asm constraints: http://reviews.llvm.org/D17349 >> It's not a regression, but I'll take it if it lands real soon. > > No brainer. Accepted on trunk by compnerd, I'll merge into release_38 shortly. r261343. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.8 Release] Release Candidate 2 source and binaries available
On 8 February 2016 at 23:14, Hans Wennborg wrote: > Sounds good to me, but if it doesn't build, or there are other > problems, I won't treat them as blocking 3.8. Absolutely! Experimental quality. :) --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.8 Release] Release Candidate 2 source and binaries available
On 8 February 2016 at 22:56, wrote: > Imho it's critical to get parallel programming working on ARMv8 ( even if > it's crappy OMP) to start. Please enable it and I'll run the tests against > our internal QA and we can informally handle testing / guarding against > regressions. So, I got some dependency errors while building OpenMP on my AArch64 box: cd /home/rengolin/devel/llvm/release/rc3/Phase3/openmp/src && /usr/bin/perl /home/rengolin/devel/llvm/release/rc3/openmp.src/runtime/tools/check-depends.pl --os=lin --arch=aarch64 --expected="libdl.so.2,libgcc_s.so.1,libpthread.so.0" /home/rengolin/devel/llvm/release/rc3/Phase3/openmp/src/libomp.so check-depends.pl: (i) Dependencies: check-depends.pl: (i) libc.so.6 check-depends.pl: (i) libdl.so.2 check-depends.pl: (i) libpthread.so.0 check-depends.pl: (x) Unexpected dependencies: check-depends.pl: (x) libc.so.6 I remember those problems when I tried last year, and they should be not too hard to work around. However, we're late in the release and I don't want to delay it even more for an experimental feature. It should be fine to compile it separately and upload later. But it would be better if you could work on the release and OMP scripts to make it work out of the box, so we can do the next releases without delay. I'll continue without OMP for now. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [3.8 Release] RC3 has been tagged
On 23 February 2016 at 21:51, Hans Wennborg via cfe-dev wrote: > Dear testers, > > Release Candidate 3 has just been tagged [1]. Please build, test, and > upload to the sftp. Uploaded and tested for ARM and AArch64, all good. Remember, this is *not* using a new Linux, so the GCC 5 issue doesn't apply. I'm hoping we fix the issue for 3.9, so that I can update our machine and test newer system behaviour. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.8 Release] 'final' has been tagged
Apologies for the delay, ARM and AArch64 tested and uploaded! --renato On 3 March 2016 at 07:33, Hans Wennborg via lldb-dev wrote: > Dear testers, > > My list of blockers is empty, and there were no new problems > discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1]. > > Please build the final binaries and upload to the sftp. > > For others following along: yes, this means 3.8.0 is complete, but it > takes a couple of days to get the source and binary tarballs built. I > will send the release announcement when everything's ready. > > Many thanks for all your work! > Hans > > [1]. > http://lists.llvm.org/pipermail/llvm-branch-commits/2016-March/009883.html > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] GitHub anyone?
Folks, There has been some discussion on IRC about SVN hosting and the perils of doing it ourselves. The consensus on the current discussion was that moving to a Git-only solution would have some disvantages, but many advantages. Furthermore, not hosting our own repos would save us a lot of headaches, admin costs and timed out connections. TL;DR: GitHub + git submodules [1] could replace all the functionality we have currently with SVN. (also GitLab, BitBucketc, etc). Here are some of the arguments made on IRC... 1. Due to SVN, we can't re-write history. If we use some GitHub properties [2], we could have the same effect. 2. Due to SVN, we have a mandatory time sequence, so commits go first in LLVM, then Clang (for example), and buildbots don't get lost. If we use submodules [1], we can have a similar relationship, but in a more explicit way, and the problem could be solved elegantly. 3. Some people still can only use SVN. For that, GitHub has an SVN interface [3] to the repositories. 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator, etc. Not only this incurs in additional admin cost, but it also gets outdated, locally modified, and it needs to be backed up, etc. GitHub gives all that for us for free. 5. We can still use Bugzilla (and lock GitHub's own bug system), but we can also use GitHub's system to manage releases (it's actually quite good for that). 6. GitHub has automated testing of merge requests, meaning we can have pre-commit tests enabled on a set of fast bots, triggered by GitHub's own validation hooks. Even though that wouldn't cover everything, having a few pre-commit bots would considerably reduce the need to revert patches [citation needed]. 7. With git submodules, we'd probably want to follow the same style we have today (llvm-projects/) instead of modelling how they look in tree (llvm/tools/clang still as a symlink). 8. Once we're solo Git, we can shop around *much* more easily. By using SVN, we're basically forced to host, or choose Source Forge. Using just Git, we can choose GitLab, BitBucket and many others, if GitHub is not appealing enough. Essentially, it doesn't matter where you are, the tools are good, there and largely replaceable [citation needed]. What do people think? Any issue not covered that we should? How would that disrupt downstream users? Would it be a temporary disruption, but with long lasting benefits? Or will it just break everything for you? cheers, --renato [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules [2] https://help.github.com/articles/defining-the-mergeability-of-pull-requests/ [3] https://help.github.com/articles/support-for-subversion-clients/ ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
On 31 May 2016 at 21:24, Aaron Ballman wrote: > Are we sure that github's svn integration works with common tools on > Windows, like TortoiseSVN? That's a good question. Can you try them out and report back? cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] GitHub anyone?
On 31 May 2016 at 21:28, Mehdi Amini wrote: > Ideally, I'd prefer the cross-repository to be handled with an extra layer, > in a way similar as described in: > https://gerrit-review.googlesource.com/Documentation/user-submodules.htm > (somehow conceptually similar to Android manifests XML files). > It would be easy to have tooling/scripts for llvm that would easily say > "checkout llvm+clang+compiler-rt+libcxx+clang-extra here", or "update all > llvm subproject under this root", or "checkout this specific revision for all > these" (with a monotonic number for the revision). At Linaro, we already have a set of scripts that do that. We're now moving to git worktree, and I think it's going to simplify our work considerably. But honestly, I'd rather not force anyone to use any set of scripts, and let people work directly with git, so I'd be more in favour of having a server-side solution, if at all possible. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?
On 1 June 2016 at 05:16, Douglas Gregor wrote: > Performance can also be an issue; it takes a bunch of fast bots to keep up > with developers testing their pull requests, especially when what you’re > testing is a very large C++ code base. That said, “test and merge on success” > workflows are *wonderful* for keeping the buildbots happy. Indeed. These pre-commit machines have to be dedicated, and we may have to have more than one, depending on the volume. But the good news is that they can scale independently, and they'll remove a huge strain from the current buildbots. Also, I think it's easier to justify (commercially) a few additional pre-commit bots than duplicating every single configuration I have today. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On 1 June 2016 at 18:12, Dan Liew wrote: >> So clone llvm ; cd tools / ; clone ... >> -- >> good luck with this.. I foresee near religious opinions on the horizon.. > > As do I. Isn't that solved by the llvm-projects repository format? --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] GitHub anyone?
On 1 June 2016 at 17:02, John Criswell 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On 1 June 2016 at 19:31, Mehdi Amini 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On 1 June 2016 at 19:36, Aaron Ballman 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On 1 June 2016 at 19:55, Mehdi Amini wrote: > 12.2: mirror git to svn :) either that or use GitHub's SVN interface, which is RW. --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
On 1 June 2016 at 20:31, Aaron Ballman wrote: > Our main repo is in SVN; I would say we don't know what most people > are using (aside from "svn for write access because it's the only > option"). If the LLVM Meetings are any indication, and they are at least related to the most active developers, everyone I've asked (and I did ask a lot over the last 2 years) was using Git for development. Most people were using Git-SVN for commits, with some few still using a separate SVN repository. I'm not really too worried about personal preferences. The infrastructure cost alone is more important than any of our preferences. That is why I have been using SVN all these years, even though I hate it more than I once hated CVS. The admin cost is high, and we're not sysadmins, so GitHub would provide an *immense* value for the price of $0. I can't argue we that. But there are also downstream infrastructure issues that need to be taken into account. As James said, knowing Git well is almost a required skill nowadays, and everything is done thinking about Git these days, so the likelihood that you'll find a replacement for your company's infrastructure to work with Git is higher than a new process will work well with SVN. In the long term, SVN will be just like CVS was 10 years ago or RCS 20. It'll be impossible to work with them, and companies depending on that infrastructure will be in *serious* trouble. > Fair points, but with the caveat that people using git today have a > workable solution (as I understand it, and I could be totally wrong) > using the git mirrors. That's not a reason to not transition from svn > to git, however. Indeed. It's all about the overall costs for the whole community. Personal preferences will be mostly diluted, with strong technical arguments being the driving forces. > This is implying that we will move, which I think should still be left > as a vague question mark until we have more answers. Based on that, I > think it's premature to encourage anyone to switch to git. I will (only slightly and personally) disagree, based on James' point of how important Git is today. Ever since I discovered Git I have always encouraged people to use it, regardless, and I'll keep encouraging. :) But that's irrelevant to the discussion. > but I am worried when emails make it > sound like switching to git-only is a foregone conclusion, which is a > bit of a strange way to start a discussion about whether the community > wants to switch. I think that's just the result of people enthusiastic with the opportunity to move to a better working environment. Not everyone is, but those that are, are showing. This is another indication that there are more Git users than SVN users, but not an argument to force the move. The only arguments we should accept are technical ones. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] GitHub anyone?
On 1 June 2016 at 21:21, Mehdi Amini wrote: > I'm not sure how to be robust against that other than putting all the > projects in the same repo and asking developers to build them all before push. I'm strongly against a single repo with all in, or asking to build LLDB when the commit is in Compiler-RT. As usual, appropriate tests are all we need. I share your view that we already have a window of possible breakage due to co-dependant commits and therefore can afford the same behaviour in Git. IIGIR, sub-modules are meant to coordinate the repositories, not to solve the problematic short window of doom. Even having a single repository with all in won't help this problem. Unless there is a way to link two commits to two different submodules and make the bots know that they can't be tested separately, we should just accept that some bots will break if they're extremely unlucky. Having said that, pre-commit bots will break with most co-dependant patches, and we must have a way to either ignore those failures and still merge, or to mark them as co-dependants and test again. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?
I think we should start two other threads: one about git tooling on Windows and one about infrastructure problems migrating to git. I'm confident we can solve both problems relatively easily. Cheers, Renato On 1 Jun 2016 10:09 p.m., "Aaron Ballman" wrote: > On Wed, Jun 1, 2016 at 3:25 PM, James Y Knight > wrote: > > 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. > > So anyone still using svn should not expect it to work? That sounds > like a great way to alienate (at least some) active contributors. > However, I do agree that clarity would be nice regarding whether the > decision to switch to git has been "finalized" or not. > > > It is truly NOT that big an imposition to require the use of git. > > One thing to keep in mind is how well supported the tools are for the > platforms we have contributors actively developing on. As a data > point, I'm on Windows. Last time I tried using TortoiseGit (which > admittedly was over a year ago), it was not ready for production use > due to crashes with simple operations. On the other hand, TortoiseSVN > works very well. While I can certainly make use of the command line, I > don't predominately live in one like others might on non-Windows > systems. So yes, it may be an imposition to require the use of git. > > I've not used the git integration in MSVC, so I can't speak to how > well that may work with a project as complex as ours (perhaps someone > else has experience and can speak to it), but that may also be a > viable alternative for those of us on Windows that are already using > MSVC. Other GUI alternatives may also exist that I'm simply unaware > of. > > > 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. > > I'm uncomfortable with the idea of jettisoning SVN entirely right out > of the gate. > > ~Aaron > > > 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 > > wrote: > >> > >> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev > >> wrote: > >> > On 1 June 2016 at 17:02, John Criswell 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-...@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-d
Re: [lldb-dev] Switching to git (Windows experience) (was re:[cfe-dev] GitHub anyone?)
On 2 June 2016 at 13:43, Aaron Ballman via lldb-dev wrote: > Are there suitable GUI tools for git on Windows for projects as > complex as LLVM? I believe MSVC has some integration, but I've not > used it before. Perhaps other tools exist that match the integration > and stability that TortoiseSVN has with Explorer? Have you tried any of these? https://git-scm.com/downloads/guis I've tried git-cola and gitg on Linux, and neither I nor my son liked it enough to move from command line to a GUI. But we're not GUI folks, so it could be that. We also tried some Android clients, and they are crude. Though, that GitHub app looks really nice! cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] GitHub anyone?
A little summary... After a lot of discussion, I think we converged to a few issues that we need to solved before we finally decide to move. Firstly, the responses were overwhelmingly positive (I counted 20 of the ~25 people strongly supporting and another 2~3 weakly supporting). This is a good indication that the move could be very beneficial to the community as a whole, including downstream infrastructure, not just the reduction in upstream infrastructure admin costs. But that doesn't mean we have cleared up all the issues... The benefits I gathered from the thread: * Infrastructure admin (not just server costs) is too expensive. We're not sysadmins and maintaining all the tools is a full time job. Volunteering works for odd problems, not for production services. Furthermore, most of the infrastructure we need is covered by GitHub/Lab/BB for free, on a scale that we would not have, even with a full time sysadmin. Gratis. * Having one official repository instead of two is beneficial to most developers. A lot of people (most people replying on this thread), use Git in addition to SVN. Git also seems to be used more on validation infrastructure than SVN (no example was put forward on this thread, at least), due to the simplicity of controlling the repository and the tools available. Reports of how teams decided to script Git to have linear behaviour instead of falling back to SVN are enlightening. * Git developer tooling is a growing trend, while SVN tooling is dying. This is not just about GUIs, but repository management (GitHub, GitLab, BitBucket, etc versus SourceForge), bisects, branches, remotes, hooks, workdir, submodules and all the new development seem to be done on Git nowadays, not SVN. Windows may be an odd one related to GUIs, but Visual Studio has Git integration and I hear it's similar to the other MSVC VCSs. GitHub's desktop interface seems pretty cool, too. * Web repositories make it *a lot* easier to create add-hoc pull requests by non-developers, which could boost the number of contributions and future contributors, as well as external projects using LLVM components. * GitHub's SVN RW interface has been reported to work well for simpler projects, but we need a more thorough examination before declare it good enough for our purposes. * All reports on the thread pointed that downstream infrastructure is already using Git, so that's one less problem to worry about if we do move. The issues that were raised: * Co-dependent patches already break buildbots, but the sequential ID helps us identify and ignore. They will continue to break, even if we use git sub-modules, so that doesn't change much, but it will be harder to spot the issue. Server side hooks may help, as well as sub-modules. * Windows tooling may be an issue. There's a separate thread handling that part, so I won't cover it here. But I have to say it wasn't by a long shot a resonant problem. It may also have some problem with symlinks and in-tree checkouts (when interacting with llvm-projects and sub-modules). * Sub-modules may help with a lot of the current relationship we have inside the SVN repo, but it also has some problems. Namely they: - require a modern version of git (1.7/1.9), but that's 2013 onward. - may need additional server side scripting, but we can keep that in another repo to control it. - won't replace SVN's monotonic IDs, but do we *really* need them? Sub-modules have a bad fame, I gather, but people in the thread reported success on using it to build validation and release infrastructure as well as doing bisects, checking out code, etc. We probably need some documentation on how to do these things, as well as some scripts to help people work out the dependencies (or use them). * GitHub/Lab/BB are not perfect. They have some interface issues, but nothing more serious than we already have on our current infrastructure. We'll probably have to keep Bugzilla (as GitHub's own is really poor), but we can replace all our repos (SVN, Git), visualisation tools (ViewVC, Klaus) and Phabricator. Of all those issues, Windows tooling is a minor problem that shouldn't impact decision that much and sub-modules need a lot of ironing out to be considered good enough. My *personal* take away is that sub-modules (or an alternative server side solution) is the only strong technical issue we need to solve before we decide. How does a move look like? If we decide to move, the proposed schedule is something like this: STEP #1 : Pre Move 0. Update docs to mention the move, so people are aware the it's going on. 1. Register an official GitHub project with the LLVM foundation. 2. Setup another (read-only) mirror of llvm.org/git at this GitHub project 3. Make sure we have a la llvm-project-submodules setup in the official account. (Optional or necessary for the buildbots?) 4. Make sure bisecting with llvm-project-submodules is a good experience 5. Make sure no one has any blocker STEP #2
Re: [lldb-dev] [llvm-dev] GitHub anyone?
On 3 June 2016 at 06:39, Jeremy Lakeman wrote: > For example; > write a new feature as a series of patches against both llvm & clang > open a pull request > somebody pushes some "approval" button (in Phabricator?) > both patch series are rebased onto llvm & clang's TOT > a single commit is created in the master repo, capturing how the llvm & > clang submodules jumped from the commit before my patches, to the last > commit in each series. Can't you generate a unique ID for each submodule commit? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.9 Release] Release plan and call for testers
On 12 June 2016 at 13:27, Dimitry Andric via llvm-dev wrote: >> 1) Right after the branch, the version number of the trunk will be >> incremented. I assume this means bumping the major version number, >> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9. > > 4.0. Since gcc is already at 7.0, we need to catch up! ;-) Or, we can do like ARM and go from 3 straight to 7! :) >> 2) Following up on the May thread about the release process [1], I'd >> like to make the schedule we've followed for the last few years more >> official by posting somewhere on the web page that we're committed to >> shipping two major releases per year: one in early March (branching >> mid-January), and one early September (branching mid-July), usually >> with one (or sometimes two) "dot" releases in between. > > Having predictable release schedules is nice. If everybody knows the > tree should be in fairly good shape at the point of branching, any heavy > refactoring can be postponed until after such branching (or preferably, > until after the actual release). Yup, +1 for a webpage with all this, in addition to the existing snippet on the homepage. >> 3) Another follow-up from that thread: it's usually the same people >> who test the releases for their platform. Rather than asking everyone >> each time, I'd like to make a list of who's responsible for each >> platform and put that on the web page. Testers can still sign-up or >> resign as they like, of course. Would you testers be OK with this? > > You can put me up for the FreeBSD platform, obviously. And me for ARM and AArch64. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers
On 13 June 2016 at 14:23, David Chisnall via lldb-dev wrote: > I don’t think that this makes it simple for anyone. Existing packaging tools > understand dot notation and know that 3.10 > 3.9, even if interpreting the > dot as a decimal point would mean that it didn’t. Without this kind of > special handling, they’d be very confused by 3.4.1, which isn’t even a valid > number. Hi David, This is indeed at odds with the rest of the open source community, but it's what we've been doing for a long time... I don't particularly like it myself, but I don't think it's evil. > LLVM minor revisions break ABI and API compatibility and bugfix revisions > don’t. There is an expectation that major revisions will break the bitcode > format, so releasing a 4.0 version but saying ‘this one doesn’t actually > break it’ will be confusing. Particularly if we then release a 5.0 that > does, after a 4.5 that doesn’t. Well, the idea here is that in "3.9.0", "3.9" is the major "number" and ".0" is the minor. I'm not saying it's a good scheme (because tools already understand the other one), but in essence, we *do* break all stuff between "majors", which means as much from 3.7 to 3.8 as it does from 3.9 to 4.0. > That said, in general I’d prefer if we used semantic versioning and stopped > releasing major versions with a bump of the minor version number. I weekly support this, as it is my preferred scheme, and all OSS tools already understand those *very* well indeed. But I wouldn't want to enforce it for this July. :) Maybe we can think of 4.0 as the last of the "weird major release", and plan well in advance to move to 5.0 when we're ready, not when the clock ticked. But that could bring a whole lot of other things like holding off features during code freeze, have multiple branches in Git for experimental features, etc. which I'd *also* welcome, but all in good time. Let's move to Git-only first. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers
On 13 June 2016 at 17:24, Robinson, Paul via cfe-dev wrote: > I don't know that the actual policy has ever been formally documented, > although it has been discussed from time to time, so it's not too > surprising that people have different ideas of what the policy is. There isn't one. Never was. The *big* changes from 1.x to 2.x and 2.x to 3.x were coincidental at best. There was no effort to hold features until "the next big release comes out", like GCC. However, I do want us to change to follow what almost all other OSS projects do, so writing it as a policy now may discourage that change and give folks some comfort that their idea has merits. I fundamentally agree with David that we have a poor way of naming releases, and that messes up a lot of infrastructure out there. But we do have one policy, which is to warn of any potentially damaging change with *at least* one release in advance. Until now, we always moved from x.9 to (x+1).0. Not because it was a rule or was written somewhere, but because we did. So, doing it again will yield no surprise. If, OTOH, we create a 3.10, it will be our first two-digit release, and that may, actually, break stuff downstream. So, my proposal on IRC was the following: 1. Get over it, call it 4.0 and release 3.9 as scheduled. 2. *Just after* the release, start the discussion for 5.0 This way we'll have at least 5 years to get it right, and people will know (we can document that) that changes are coming. But we can also change from (ex) 4.3 to 5.0 as soon as we agree that we'll do that. My point for the delay is two-fold: 1. Changing the number is not just about naming, it's about behaviour. We'll be telling the world that Clang/LLVM 3.x should work with *any* 3.x components, which is *not* true today. 2. We'll give time for people to agree or disagree, before we name the release on SVN. People release Git-versions of LLVM and call them "llvm-3.9-git". Imagine if we create "llvm-3.10-git" but we decide to change later on to 4.0? So, let's discuss about code freeze, feature branches, stable releases, etc, *first*. But for that, it'd be good to get the SVN vs. Git out of the way even sooner, so, we're talking years, here... cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers
On 13 June 2016 at 18:02, Rafael Espíndola wrote: > It is documented at > > http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility This is weird... "The bitcode format produced by a X.Y release will be readable by all following X.Z releases and the (X+1).0 release." Why (x+1).0 ? --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers
On 13 June 2016 at 18:30, Michael Kuperstein wrote: > It would probably better for whoever wrote this text to pipe in, but I think > the idea is that (X+1).0 is supposed to be a kind of a "bridge" release. That rings a bell... but I have to be honest, it's weird... Now, well, as Rafael said originally, our policy doesn't state how long we can go (3.10, 3.11 or 3.9 -> 4.0), nor it does *require* that we change the ABI on (X+1). FWIW, the Linux kernel seems to be going that way, too. Whatever works, but it would be good to choose something based on consensus and document. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Git Move: GitHub+modules proposal
So, It's been a while and the GitHub thread is officially dead, so I'll propose a development methodology based on the feedback from that thread. This is not *my* view, but all that was discussed in the threads. My objective is to form an official proposal to use Git as our main repository, overcoming all the problems we currently have without creating many others. In the end, I think Tanya wanted to make a vote, and see how string the community feels about it. The vote should be "Should we move to GitHub as the proposed workflow, or should we try to find another solution away from our own hosting?". The important part is that we *must* move from the current schema. It does not scale and the administrative costs are not worth the trouble. So, if we don't go with GitHub, we have to find another way out. The proposal == Move to GitHub with N+1 projects: all current LLVM projects + the "llvm-projs" umbrella. The latter will have all other projects as "submodules" with the intent to: 1. Control the history via server hooks updating a unique and auto-increment identifier, which will apply to every commit on its submodules (ie, every other LLVM project). 2. Serve as a reference for releases, buildbots, etc., checking out only the necessary submodules for each. 3. Have additional logic to handle the additional complexity for mailing lists, tools, buildbots to deal with the umbrella project *only*. The existing LLVM projects (llvm, clang, compiler-rt, etc) will continue on their own repositories and be built locally just like they are today. You can check them out individually inside the final directory (llvm/tools/clang) or use symbolic links, just like we do today. You can also checkout "llvm-projs" and update only the required submodules, and use symbolic links. The llvm-projs umbrella will have its own versioning, and tools can report that ID as their "version", if they're not in a release branch. Release branches should be off of master and have a linear history, just like master, in the exact same way we do now with SVN. This will guarantee the umbrella project will be able to correctly auto-increment the ID and make sure current tools work as usual. We don't want private branches to end up in upstream LLVM (only upstream release branches), but that's perfectly natural in GitHub, where anyone can fork and implement their features and own releases off of the upstream official repositories. This can work as well for upstream development of "feature branches", where upstream developers contribute to both repositories, but keeping a specific feature in test separate. Merges will still have to be like it is today, one patch at a time, or risk reverting the whole merge window if the buildbots start breaking, which can be impossible if the window is large or two or more windows get committed at the same time. For "feature branches" we could use git-imerge, but that's for the future and not considered in the first stage of the move. Git Submodules - There were concerns is submodules would work with our flow, but the concerns were addressed by demonstrating that: 1. Submodules can work in an umbrella project, which controls the auto-increment ID 2. You can check-out individual modules or all, so work well for releases and buildbots 3. The history is shared with the root project, so git-bisect works out of the box The Alternatives - A few alternatives were proposed, but git submodules ended up being considered more thoroughly. Here are some of the reasons: * Google repo: It's an independent tool, which may suite us today, but not necessarily tomorrow. It may work well with the infrastructure that is already set for it on other projects (mostly Google projects like Android), but it does require some tooling (like git submodules). The point is, that it's much more likely to exist tooling for official git features than third-party projects, especially on Windows. * All-in-one: Proposals to have all projects inside one big repo were quickly dismissed due to the problems it creates to *users* of LLVM as a library, and to build systems (specific buildbots) that don't need to monitor all changes all the time. It simply won't scale. * Multiple clones: Allowing the projects to *exist* in different conditions (clang inside LLVM, or as a stand-alone library) will not scale. CMake will have to cope with all the different styles, it doesn't solve the unique auto-increment ID nor it helps downstream projects migrate to a common infrastructure. Questions In order to make this proposal final, I still need a few questions to be answered. 1. How will the umbrella project's auto-increment hook work? Will it be one ID for every commit in every other repo? How will it know which one came first? Does it matter? If we have two commit "at the same time", do we create a priority list? Ex. LLVM commits get a lower ID than Clang ones, because it's more
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 26 June 2016 at 23:02, Anton Korobeynikov wrote: > Does github allow this? IIRC their support for server-side hooks was > very limited due to obvious reasons. And executing hooks e.g. on > llvm.org seems very error-prone. Someone suggested it was possible. I have sent them an email with a draft proposal and they said everything was fine, though they didn't confirm specific support. I can't see shy changing a local auto-increment ID on the repository itself would be a breach of security, so even if there are limitations, I think we can get this done. I'll send them another email to confirm this specific point. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 27 June 2016 at 01:20, Matthias Braun wrote: > I really liked the the solution proposed earlier in this thread: Do nothing > server side, but instead use > `git rev-list --count master` on the client side (which takes 0.9s on my > machine) to get the number of the commit. So nothing to do on the ID part IMO. Mehdi replied to this proposal: "it does not help to solve the cross-repository problem, we need a "meta integration repository"." > As for updating the meta repository: We could disable write access for the > normal llvm developer and delegate the submodule bumping to an external > server. I believe this would be an easy enough job for buildbot or jenkins. The plan is to disable all write access to this repository (otherwise we'll create a nightmare). Having an external counter could be problematic due to synchronisation issues. If the hook doesn't work, we'll have serious problems. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 27 June 2016 at 15:39, Rafael Espíndola wrote: > So, I probably missed something, but what was the main objection to > just using submodules? This would put llvm inside clang instead of the > other way around. When changing an API one currently has to I don't think the consensus was to change the order of inclusion (llvm into clang), but to *not* change anything else at this stage. That's one of the reasons the umbrella project with sub-modules was the most accepted solution, because we can later change the inclusion order (if we all agree, etc), without changing the underlying storage. > * Change llvm. > * Change clang and in the same atomic commit change what revision the > submodule points to. Having one repository inside another was rejected due to the problems it brings for development, validation and release. James has just pointed a few of those problems for development. An umbrella project with a commit hook and an auto-update would make sure all commits are synchronised correctly. Though, indeed, this will mean we'll still have the trouble of buildbots picking up one commit and not the other, I don't think this is a big enough problem that we should mess up everyone's workflow. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 27 June 2016 at 17:03, Rafael Espíndola wrote: > I think that trying to create a ordering/rev number between independent git > repositories is fundamentally unreliable. > > If we want to keep llvm and clang in lock step we should probably probably > just have them in the same repository like > https://github.com/llvm-project/llvm-project. That is similar to the proposal we have, except that llvm-projects will have sub-modules. Having all of them in the same physical repository is a big problems for those that only use a small subset of the components, which is the vast majority of users, most of the time (all buildbots, Jenkins, local development, downstream users, even releases don't clone all repos). cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 28 June 2016 at 06:55, NAKAMURA Takumi wrote: > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > Both llvm-project(-tree) and (-submodule) have refs/notes/commits. Nice! Can you try a server hook that will add an auto-increment number from submodules commits? cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 28 June 2016 at 17:33, Tim Northover wrote: > I really like this too, and think Takumi has basically solved 90% of > the problem for us already. We may want to add an "rN" line to avoid > scaring people with hex commits, but that seems to be all that's > lacking and not really essential anyway. Not so much scaring, but to avoid rushed migrations. Current SVN-aware handling (downstream infra, bisects) deal better with sequential numbers, and they may take some time to migrate to fill Git solution. We should move all upstream infrastructure, but we can't dictate on the downstream pace (or it would never happen). cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 28 June 2016 at 16:46, Mehdi Amini wrote: > Why? Assuming we don’t have branches, there was many mention that the id can > be computed from the number of commits in the history. We have branches (release_nm) and we may want them to be in the same sequential numbering. So, I'm assuming this hook gets executed every time a new commit arrives, but they're sub-modules, would they also notify the parents? If this works in a trigger mode (every commit), not a timed basis (every 5 minutes), then it could work well. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Git Move: GitHub+modules proposal
Hi all, A short summary: Takumi has done 90% of the work here: https://github.com/llvm-project/llvm-project-submodule and I've been talking to GitHub, and here are the answers to my questions: > 1. How will the umbrella project's auto-increment hook work? Since the umbrella project cannot see the sub-modules' commits without some form of update, there are two ways to do this: P. Per push: Every push (not commit) on all other repositories will trigger a hook that will hit a URL on our server, telling it to generate an incremental ID, update some umbrella's SeqID property (or even a commit SHA) and update the sub-modules. T. Time based: A cron job in our server would frequently pull from all repos and update ID/modules. Option P is less confusion and more fine grained, but if it misfire, we'll lose that push, and its commits will be bundled with the next push on that repo. Option T will invariably bundle things together, even from different repositories. The change that this will "correctly" merge an LLVM+Clang double-patch is not worth the trouble for the noise. For both of them, we need an external server, as there's no way to update a repository's property from another. Multiple commits eventually getting into a single umbrella revision can be innocuous for development, but they can make controlling the version for releases a bit more complicated. Though, it would also have no effect on back-ports, since they'll be done on Git and get their own SeqID. All in all, I'm not too worried about this... > 2. How do we update the commits mailing lists? This is, apparently, trivial in GitHub: https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/#enabling-email-service-notifications-for-pushes-to-your-repository Any more comments before we put this proposal to vote? Is anyone going to propose an alternative Git solution? Or maybe an external, reliable and trustworthy SVN repository (ie. *not* SourceForge)? In the interests of brevity and peacefulness, we should aim to only have one vote, even if it has multiple choices, so if we have more proposals, please bring them up. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 15:11, David Chisnall wrote: > Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub > continue to work by simply switching the remote in the config? I hope so. There isn't anything (modulo mistakes) stopping us from having a clean migration. We'll have to re-organise the GitHub mirrors, though, as Takumi has mostly driven out of his own account, and it'll have to be owned by "The LLVM Project" somehow. Mehdi suggested us to flip the mirror (from GitHub to LLVM Git to SVN), as soon as we mark them read-only, and then open RW only in GitHub. We don't want to use GitHub's "pull requests" for every patch, so we'll have to add push rights to all committers today. Meaning, you can just change the remote to the official GitHub repo and get rid of Git-SVN. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 16:50, Tom Honermann wrote: > How would you coordinate dependent updates to the sub-modules? We won't. Not now. Maybe later. Right now, doing that means changing how we work and we're trying to make the least number of changes at a time. But this is the most requested feature and I'm sure we'll find something that will work as soon as everything is stable. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 19:51, Sean Silva wrote: > Roughly speaking, I would prefer a repo division (if any) to be along the > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff > not strictly required". The problem comes when different people consider "core" different projects. :) We're always reviewing the projects and we do split them when people agree it's needed. Examples are the libunwind coming out of Compiler-RT, and the recent discussion to do the same with the sanitizers and others. This is not just about preference, but it's about cross dependency, and the only sane way we can cross-build to multiple targets. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 29 June 2016 at 20:14, Sean Silva wrote: > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > important special case we may be able to agree on. (and I say this as > somebody that largely builds cross-compilers (targeting PS4)) In that case, RT wouldn't "have" to be core. We use GCC rt-libs on GNU systems, even for self-hosting. Even if we move to full RT builtins (which I really want), we'd have to get rid of everything else in that repo to move it to core. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 30 June 2016 at 05:14, Tim Northover wrote: >> That makes it fragile, and that’s why I disagree with your “90% done” >> assessment. >> What if the service behing the hook is down for a few days? > > In the long-term view, a pretty trivial catch-up script ought to be > able to synthesize a sane history after any amount of down-time. > People could even run it locally for their bisecting needs if it was > that important to them. Yup. If the script is stable (as in sort stable), anyone running it locally will get the same results as upstream and each other. > In the short term, I don't think it's a critical enough service to > worry about, frankly. What we already have is hopelessly fragile: > right now when LLVM's server plays up it takes out absolutely > everything, in the proposed world it would take out this bisecting > convenience feature. Seems like a strict improvement to me. I think it's even less important than that. Bisecting will work *better* when using submodules than it does using SVN (because git bisect is more powerful, allows me to track all modules' history, and will rid me of a complicated downstream set of SVN-bisect scripts). The only thing we *have* to have a sequential number for, are releases. Even that can be ran manually. We agreed to have sequential numbering from the start to allow infrastructure to migrate slowly to a Git model. That can also have an extra step to run the script if IDs are not populated yet. >> Who will maintain it? Whoever maintains the current infrastructure, which is currently the Foundation. All scripts will be upstream. So far, they (Tanya, Anton, Galina) have been very responsible to every downtime and problems I found. I have no doubt that this will continue to be a trend. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Sequential ID Git hook
Now that we seem to be converging to an acceptable Git model, there
was only one remaining doubt, and that's how the trigger to update a
sequential ID will work. I've been in contact with GitHub folks, and
this is in line with their suggestions...
Given the nature of our project's repository structure, triggers in
each repository can't just update their own sequential ID (like
Gerrit) because we want a sequence in order for the whole project, not
just each component. But it's clear to me that we have to do something
similar to Gerrit, as this has been proven to work on a larger
infrastructure.
Adding an incremental "Change-ID" to the commit message should
suffice, in the same way we have for SVN revisions now, if we can
guarantee that:
1. The ID will be unique across *all* projects
2. Earlier pushes will get lower IDs than later ones
Other things are not important:
3. We don't need the ID space to be complete (ie, we can jump from
123 to 125 if some error happens)
4. We don't need an ID for every "commit", but for every push. A
multi-commit push is a single feature, and doing so will help
buildbots build the whole set as one change. Reverts should also be
done in one go.
What's left for the near future:
5. We don't yet handle multi-repository patch-sets. A way to
implement this is via manual Change-ID manipulation (explained below).
Not hard, but not a priority.
Design decisions
This could be a pre/post-commit trigger on each repository that
receives an ID from somewhere (TBD) and updates the commit message.
When the umbrella project synchronises, it'll already have the
sequential number in. In this case, the umbrella project is not
necessary for anything other than bisect, buildbots and releases.
I personally believe that having the trigger in the umbrella project
will be harder to implement and more error prone.
The server has to have some kind of locking mechanism. Web services
normally spawn dozens of "listeners", meaning multiple pushes won't
fail to get a response, since the lock will be further down, after the
web server.
Therefore, the lock for the unique increment ID has to be elsewhere.
The easiest thing I can think of is a SQL database with auto-increment
ID. Example:
Initially:
sql> create table LLVM_ID ( id int not null primary key
auto_increment, repository varchar not null, hash varchar nut null );
sql> alter table LLVM_ID auto_increment = 30;
On every request:
sql> insert into LLVM_ID values ("$repo_name", "$hash");
sql> select_last_inset_id(); -> return
and then print the "last insert id" back to the user in the body of
the page, so the hook can update the Change-id on the commit message.
The repo/hash info is more for logging, debugging and conflict
resolution purposes.
We also must limit the web server to only accept connections from
GitHub's servers, to avoid abuse. Other repos in GitHub could still
abuse, and we can go further if it becomes a problem, but given point
(3) above, we may fix that only if it does happen.
This solution doesn't scale to multiple servers, nor helps BPC
planning. Given the size of our needs, it not relevant.
Problems
If the server goes down, given point (3), we may not be able to
reproduce locally the same sequence as the server would. Meaning
SVN-based bisects and releases would not be possible during down
times. But Git bisect and everything else would.
Furthermore, even if a local script can't reproduce exactly what the
server would do, it still can make it linear for bisect purposes,
fixing the local problem. I can't see a situation in which we need the
sequence for any other purpose.
Upstream and downstream releases can easily wait a day or two in the
unlucky situation that the server goes down in the exact time the
release will be branched.
Migrations and backups also work well, and if we use some cloud
server, we can easily take snapshots every week or so, migrate images
across the world, etc. We don't need duplication, read-only scaling,
multi-master, etc., since only the web service will be writing/reading
from it.
All in all, a "robust enough" solution for our needs.
Bundle commits
Just FYI, here's a proposal that appeared in the "commit message
format" round of emails a few months ago, and that can work well for
bundling commits together, but will need more complicated SQL
handling.
The current proposal is to have one ID per push. This is easy by using
auto_increment. But if we want to have one ID per multiple pushes, on
different repositories, we'll need to have the same ID on two or more
"repo/hash" pairs.
On the commit level, the developer adds a temporary hash, possibly
generated by a local script in 'utils'. Example:
Commit-ID: 68bd83f69b0609942a0c7dc409fd3428
This ID will have to be the same on both (say) LLVM and Clang commits.
The script will then take that hash, generate an ID, and then if it
receives two or more pushes with such hashes, it'll return the *same*
ID, say 123456, in which case
Re: [lldb-dev] [llvm-dev] Sequential ID Git hook
On 30 June 2016 at 17:33, Reid Kleckner wrote: > Agreed, the llvm-project repository can completely take on the role of the > SQL database in Renato's proposal. Hum, doing it in a separate server was suggested by the GitHub folks, so I just assumed they can't do that in the umbrella project for some reason. I'm all for using the umbrella if we can, I just though we couldn't... :( Can someone try the suggested tag style? Are we sure we can guarantee atomicity in there? I know SQL can. :) I know that changing the commit message works because of Gerrit and our current SVN integration, I don't know how much adding one tag for each push will work in Git over time. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] Git Move: GitHub+modules proposal
On 30 June 2016 at 16:23, Frédéric Riss wrote: >> The only thing we *have* to have a sequential number for, are >> releases. Even that can be ran manually. > > LNT and ‘llvmlab bisect’ also currently rely heavily on having sequential > numbers as commit identifiers. One of the steps of the migration is to re-write the infrastructure to use Git's history instead of sequential numbers. LLVM Lab bisect is probably easier than LNT, but as I said, this is *only* a problem when the service goes down, which shouldn't be common at all. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
I guess the point is that, for some, not having that clause, causes discomfort and reduce their contribution. For others, having that clause causes discomfort and reduce their contribution. I don't think one is more important than the other, nor I think we should see this as which side makes more contributions. Daniel's version, although similar, is clearer, and may discourage abuse even more that Chandler's original fix. I'm OK with that, too. I guess I prefer to be reactive. If people start abusing, I'll make some comments, then some noise, than official complaints to the board, etc. If none of that works, getting out of here is the obvious choice. But that will take an impressive amount of abuse and carelessness, and the community will be already fragmented by then. My tuppence. Renato On 30 Jun 2016 11:11 p.m., "Daniel Berlin via cfe-dev" < cfe-...@lists.llvm.org> wrote: > That's just a residual clause. > It's not sanely possible to enumerate all the possibilities here (IE if > you stalk and murder someone in the llvm community, you are going to get > kicked out of the community, regardless of if you did it in a controlled > space) > I mean, i'm subject to legal ethics rules that are very similar, and those > could get me kicked out of an entire profession :) > > I guess one could write "In addition, violations of this code outside > these spaces may, in rare > cases, affect a person's ability to participate within them, when the > conduct amounts to an egregious violation of the communitie's social > standard." > > But it's not, in practice, any different. > > Basically, if you are looking for complete and total bright line > proscribed standards, they pretty much don't exist anywhere except in > criminal statutes :) > > > > On Thu, Jun 30, 2016, 2:45 PM Robinson, Paul > wrote: > >> I expect Rafael's concern is because the code also says: >> >> >> >> In addition, violations of this code outside these spaces may, in rare >> cases, affect a person's ability to participate within them. >> >> >> >> So it can apply outside spaces explicitly sponsored by LLVM, in undefined >> circumstances. >> >> --paulr >> >> >> >> *From:* cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] *On Behalf Of *Daniel >> Berlin via cfe-dev >> *Sent:* Thursday, June 30, 2016 1:37 PM >> *To:* Rafael Espíndola >> *Cc:* llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB >> *Subject:* Re: [cfe-dev] [llvm-dev] FYI: Landing the initial draft for >> an LLVM Code of Conduct >> >> >> >> >> >> >> >> On Thu, Jun 30, 2016 at 1:23 PM, Rafael Espíndola < >> llvm-...@lists.llvm.org> wrote: >> >> I am strongly opposed to it as it stands. >> >> Who decided this and with what authority? As written the code of >> conduct tries restrict the acceptable opinions one may voice even in >> channels not related to llvm at all. >> >> errr, it says: >> >> "This code of conduct applies to all spaces managed by the LLVM project >> or The >> >> LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, >> LLVM >> >> vents such as the developer meetings and socials, and any other forums >> created >> >> by the project that the community uses for communication. " >> >> >> >> >> >> How does this cover channels not related to llvm? >> >> >> >> With this in place I will not consider myself a member of the llvm >> community anymore and would be terrified to interact with another llvm >> developer in a social setting. >> >> >> >> That would be sad, but i guess i'm not sure what is causing that. Is it >> that there is discretion in there that you are afraid may apply to you if >> taken to some extreme? >> >> >> >> Rafael >> >> On 30 June 2016 at 14:55, Chandler Carruth via cfe-dev >> >> wrote: >> > Hello folks, >> > >> > As mentioned some time ago[1], we’ve had a long (looong) series of >> > discussions about establishing a code-of-conduct for the LLVM project >> as a >> > whole over on the llvm-dev thread and the >> http://reviews.llvm.org/D13741 >> > code review. >> > >> > The discussion has largely died down for some time, and towards the end >> > there has been pretty wide support for the draft wording we have now. It >> > isn’t perfect, and there are still some important questions around >> forming >> > the advisory committee to handle reporting, but I think the wording is >> at a >> > good point of compromise in a challenging area. >> > >> > Based on the support, I’m going to land the patch that adds the draft. >> I’m >> > hoping this will immediately provide good advice and guidance, and I’m >> > hoping to see motion on setting up a reasonable advisory committee and >> > resolving any issues around reporting so we can make this an official >> part >> > of the community. >> > >> > I sending this as a heads up so folks are aware, not to start a new >> > discussion thread. There are existing discussion threads[2] on llvm-dev >> if >> > folks want to join in active discussion or we can start fresh ones, but >> I >> > would encoura
Re: [lldb-dev] [cfe-dev] [llvm-dev] Sequential ID Git hook
On 30 Jun 2016 10:20 p.m., "Robinson, Paul" wrote: > We've since stopped creating the tags, and gotten used to not having > them. We do the 'rev-list --count' trick which mainly gets recorded as > one component of the version number, and it has been working for us. Does that work for sub modules inside the umbrella project? How can you trigger a hook in the umbrella project for commits inside the sub modules? Enough people complained about the sequential number, and I'm trying to solve that problem. I particularly have no use for that at all. We can still do the bundling pushes with the same id by adding metadata to the commit message and training our CI, which is orthogonal to this issue. Cheers, Renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 1 July 2016 at 18:32, Daniel Berlin via lldb-dev wrote: >> The single word "rare" in the current code doesn't feel like enough. > > I don't actually disagree with your criticism, IMHO, i just don't know of a > way to generate more clarity. Paul, Rafael, Daniel, With the intention of being pragmatic and getting the draft out (remember, it's *still* a draft), would having Daniel's new proposal more comfortable? "In addition, violations of this code outside these spaces may, in rare cases, affect a person's ability to participate within them, when the conduct amounts to an egregious violation of the community's social standard." If so, than I'd hope we could get this through and start discussing the second part, the reporting and committee formation, which I think it's much more important than the code itself. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] Sequential ID Git hook
On 1 July 2016 at 17:32, Tim Northover wrote:
> My issue with using tags like this is that they pollute the tag
> namespace and will quickly swamp what I consider to be the important
> ones ("release-X"). OK, so we've got "git tag -l 'release*'" but
> that's pretty ugly.
What if we had a mixed mode?
Say we create a tag for each release, and we know what was the last
release's tag number (245234), then we just need to count how many
commits "since the last tag", which will always be the last release.
This will have all the tags we want, and scale forever.
Is rev-list able to do that?
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook
On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev wrote: > "git-describe -t" works also for lw tags. But it doesn't work if there are no tags, I just tested on LLVM and I get: $ git describe fatal: No names found, cannot describe anything. Should be easy enough to create the tags on each branching point, though. "describe" also seems to be available at least since Git 1.9, so it should be pretty safe. And since tagging *every* commit doesn't scale for long ranges, and anything else will need scripting on the client side, I think we can get rid *completely* of any server side hook, and let the client side scripts deal with the output of "git describe". Or am I just too optimistic? cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct
On 4 July 2016 at 00:42, Robinson, Paul wrote: > Daniel claimed it was not different, even though he proposed the text. > I think it is better, as "egregious" (even though it is qualitative) > helps identify what "rare" circumstances would come under the policy. > As a non-lawyer I do think it's different. I personally agree with you, both on helping identify "rare" (as what, not when), and for easing non-lawyers minds. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook
On 4 July 2016 at 15:21, Bruce Hoult wrote: > What doesn't scale about tagging every commit? Both Jim and Takumi have reported problems with thousands of tags. Even though neither of them responded to your enquiries for additional data, we can't assume there isn't any. Furthermore, "git describe" seems to be the "mixed mode" I asked about, and it's already in git since an old version, so I'm not sure why we'd even need to create one tag per commit anyway. People should be using Git for bisects, in which case it works out of the box. The incremental version was mostly to tag the build with something meaningful, which "git describe" is. Even if you want to use the result of describe to bisect like SVN, it works because our history is linear (and you can count the number of commits between A and B, and even store a local list of the hashes in between. I really can't see why would we need to tag every commit. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Sequential ID Git hook
Quick re-cap. After a few rounds, not only the "external server" proposal got obliterated as totally unnecessary, but the idea that we may even need a hook at all is now challenged. Jared's idea to use "git describe" is in line with previous proposals to use rev-list --count and to do so only up to the previous tag, but all in one nice and standard little feature. There were concerns by applying one tag per commit, but most of them offered weak evidence. However, if "describe" can cover all our needs, there is no point in even discussing tags. Just for reference, GitHub *does* have an SVN interface [1], and you can already checkout a specific revision with "svn checkout -r NNN repo", which *is already* using "git rev-list --count". This means that, for SVN based bisects, using GitHub will make it *completely transparent* for SVN users. You can also base your releases off an SVN view of the Git repo. So, to clear up this discussion and finish my proposal to move to GitHub, my final questions, only to those that *want* SVN compatibility: 1. Is there anything in the SVN view of GitHub that *doesn't* work for you? (ie. same as using "rev-list --count") 2. If so, can "git describe" solve the problem? 3. If not, please describe, in details, why <> would be the *only* way forward. I'll let this sit for a few days, and if no one has any serious issue, I'll write up the final proposal and start the voting process with the Foundation. cheers, --renato [1] https://github.com/blog/626-announcing-svn-support ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-foundation] Sequential ID Git hook
On 5 July 2016 at 12:13, David Chisnall wrote: > Note that GitHub (currently, at least) doesn’t export submodules sensibly > with their svn version. SVN users can continue using the projects directly, they *just* need to change the SVN repository location of every project to GitHub. It can't get simpler than that. > I think it would help to have a description of how to bisect for a clang or > lldb (or some other subproject) regression. There are plenty of good documentation (https://git-scm.com/book/en/v2) that teaches everything one needs to know about git (but was afraid to ask). Using the umbrella project, the sub-modules will make it trivial to bisect. Using SVN view for individual projects will make it *identical* to bisect as it was. > For downstream users, it would also be nice if tools like git-imerge let you > merge clang and llvm together, though that’s a nice-to-have feature that we > currently lack so shouldn’t in any way block the migration. Git imerge is an amazing tool, but it's not production quality yet, I think. Though, this is really an orthogonal issue, since SVN-bound people can still use the SVN view and merge their own patches downstream. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Sequential ID Git hook
On 5 Jul 2016 10:45 p.m., "Mehdi Amini" wrote: > > > > On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > > Quick re-cap. > > > > After a few rounds, not only the "external server" proposal got > > obliterated as totally unnecessary, but the idea that we may even need > > a hook at all is now challenged. > > This is not clear to me. > How is the umbrella repository updated? Sorry, I meant no hooks for updating sequential ids. We still need a hook to update the umbrella project. Cheers, Renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-foundation] [llvm-dev] Sequential ID Git hook
On 8 July 2016 at 01:56, Chris Matthews wrote: > With both llvmlab and LNT, once you get to a range of IDs, it is needs to be > easy to find out what commits or commit range those IDs map to. When given > regression between 123 and 225, I need the list of commits, and I don’t want > to log grep for those numbers. Ideally it should also easy for those tools > to link to a revision on a webUI like viewvc. That's as easy as: git rev-list --count hash, relying on the fact that our history is linear, you just have to do basic arithmetic (on the umbrella project) to get the final sequence. All of it can be done on the client, not the server. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook
On 8 July 2016 at 03:14, Robinson, Paul wrote: > I could see wanting to compare data from master and a release branch. If > that means sequential IDs need to work across branches, then we're back to > needing a fancier solution than 'rev-list –count'. How would you do this in SVN anyway? Branch commits are inter-twined with trunk commits, and comparing them numerically doesn't yield the results you expect. At least in Git, the history is tied up via "parent" and not via sequential IDs, so you can actually walk the path. Sequential numbers are only meaningful for linear histories. Branches, whether on Git or Svn break that promise. If we make LNT work with Git "as Git", then all problems are solved. And meanwhile, we get to work with LNT "as SVN" via rev-list --count. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook
On 8 July 2016 at 17:45, Mehdi Amini wrote: > You missed the point that in a single instance of LNT a revision number has > to be unique. > The rev-list thing won't provide this across branches. > A rev-list count number won't identify a revision, you need the tuple > (branch, count), which is less easy or less compatible with existing systems. What about git describe? --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook
On 8 July 2016 at 21:04, Mehdi Amini wrote: >> What about git describe? > > Not a number. It contains a number... "tag-number-hash" Removing the tag and hash seems trivial. --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook
On 8 July 2016 at 21:07, Mehdi Amini wrote: > The problem is not that is it is not possible to work with a tuple (branch, > number), the problem is that a tuple (or a string) is not a number and breaks > existing infrastructure. It does not mean it cannot be made to work, but it > won’t out-of-the-box. > (Imagine that the LNT database needs an integer id for instance, and this id > is usually the SVN rev, unique across branches). Ah, got it! Ok, sorry, I was trying to understand why it wouldn't work, not why it wouldn't be out-of-the-box. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook
On 8 July 2016 at 20:12, Chris Matthews wrote: > If LNT is the only holdout I suggest we update the LNT model to natively > handle git. I could say the reverse... If improving LNT is a reason to move to Git, than we should do it. :) > This sort of change to the > guts of how LNT works is weeks of work, but I think it matches LNT’s goal of > tracking performance changes as software evolves. I think this is a worthy goal, GitHub or not. The Git mirror is already official, and we could very well use that today. Also, the GitHub migration, if it happens, will be months away anyway, and we'll have to complete all pending tasks before we move, so this could be one of them. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 29 July 2016 at 23:57, Hans Wennborg via Release-testers wrote: > There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at. First wave of testing pass on ARM. Uploaded to the FTP server. Is it time to do the back-ports planned? I only have a very minor bug fix. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 1 August 2016 at 17:37, Hans Wennborg wrote: >> Is it time to do the back-ports planned? I only have a very minor bug fix. > > Sure! Backported the v6T2/DSP patch. Now just needs to get Diana's AArch64 fix and we're fine. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 2 August 2016 at 16:17, Hans Wennborg wrote: > Looks like Diana's fix was merged in r277462, so it sounds like we're all > good. Yup, we're good. Thanks! --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.9 Release] Please write release notes!
On 3 August 2016 at 00:46, Hans Wennborg wrote: > - Dmitry, Renato: the Clang notes mention abi_tag. Do we want to > expand the text here a little? Link to the PR? We certainly do. This is a big deal. I'll write up something and let Dmitry correct my mistakes. :) We'll also add the ARM/AArch64 changelogs. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.9 Release] Please write release notes!
On 3 August 2016 at 10:46, Renato Golin wrote: > We certainly do. This is a big deal. I'll write up something and let > Dmitry correct my mistakes. :) Done. > We'll also add the ARM/AArch64 changelogs. Done. :) cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged
On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev wrote: > Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and > higher, due to a conflict of initialization order with our jemalloc. So I am > not extremely keen on fixing this before the release. This sounds really serious. Do we have a bug for that? --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 1 source and binaries available
On 4 August 2016 at 19:17, Hans Wennborg via Release-testers wrote: > Source and binaries for LLVM-3.9.0-rc1 are now available at > http://llvm.org/pre-releases/3.9.0/#rc1 Ouch! I forgot to upload the AArch64 image! Sorry, it's there now. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 2 has been tagged
On 19 August 2016 at 02:51, Hans Wennborg via Release-testers wrote: > This is a release candidate in the very real sense that if nothing new > comes up, this is be what the final release looks like. There are > currently no open release blockers, and no patches in my merge-queue. ARM binaries good, uploaded. $ sha1sum 2de75ce9a302df58bbfc0e96583c2ba4f12fc0ce clang+llvm-3.9.0-rc2-armv7a-linux-gnueabihf.tar.xz cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 2 source and binaries available
Hi Hans, I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the wrong one? Cheers, Renato On 22 Aug 2016 7:55 p.m., "Hans Wennborg via Release-testers" < release-test...@lists.llvm.org> wrote: > We're getting close to the final release. I know the schedule on the > web page says 'final' should be tagged today, but I still think it > should be possible to get there this week. > > Source and binaries for LLVM-3.9.0-rc2 are now available at > http://llvm.org/pre-releases/3.9.0/#rc2 > > Please try it out and let me know if you find any issues. > > As we're running out of time, RC2 will be a short test cycle, so if > you're planning on testing it, please don't procrastinate it :-) > > Thanks, > Hans > ___ > Release-testers mailing list > release-test...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 3 has been tagged
On 25 August 2016 at 04:42, Hans Wennborg via Release-testers wrote: > Dear testers, > > 3.9.0-rc3 was just tagged from the branch at r279704. ARM and AArch64 seem fine, binaries uploaded: ARM sha1sum: d1bc90d475f8d764f1ff7524ba2f3e26acb8a463 AArch64 sha1sum: 5e4e3bdf747aa2ac50c588cea5d67f89637691c6 cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [Release-testers] [3.9 Release] 'final' has been tagged
ARM and AArch64 green, uploaded. Thanks! $ sha1sum clang+llvm-3.9.0-aarch64-linux-gnu.tar.xz e9bfdf32c869e8fb344ef1b386c5d2b44ccac056 $ sha1sum clang+llvm-3.9.0-armv7a-linux-gnueabihf.tar.xz 2ad7a7b226b78d5c13ef06abb96da7a0fb8d535e --renato On 2 September 2016 at 01:38, Ben Pope via cfe-dev wrote: > On Thursday, September 01, 2016 01:21 PM, Ben Pope via cfe-dev wrote: >> >> Ubuntu x86_64 16.04 >> 03687b22791b8c21813fc015dd507fc0 >> clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz >> >> If anybody would like a build for Ubuntu x86_64 14.04, let me know. > > > 0eabc565733a62d77da1214a70c6c344 > clang+llvm-3.9.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz > > Ben > > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] YouTrack e-mails
On 26 September 2016 at 19:12, Anton Korobeynikov via llvm-dev wrote: > Note that nothing was decided yet, it might be very probable that > we'll continue use Bugzilla, we're just evaluating other options and > collecting the relevant information. We will try to make sure that > there will be no more e-mail notifications without reason. Hi Anton, Thanks for the effort of testing new systems! I'm a hard fan of bugzilla (I know, I'm weird), but I'm happy with any other, too, as long as they don't block us more than help. In the end, any future decision will have to be backed by hard data, and testing these other systems as you're doing is the only meaningful way of getting it. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [CFP] LLVM devroom @ FOSDEM 2017
CALL FOR PAPERS / PARTICIPATION At FOSDEM 2017, LLVM will again participate with a dedicated devroom. Complementing the upcoming Euro LLVM 2017, the devroom at FOSDEM provides a great opportunity for LLVM developers and the wider open source community to get together, connect and discuss. As possibly the largest European Open Source Conference, FOSDEM takes place in Brussels and attracts with more than 400 lectures every year over 5000 hackers - many core contributors of the worlds leading open source projects. = Call for Speakers, Posters, Demos = We invite academic, industrial and hobbyist speakers to present their work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc. We are looking for: 1. Keynote speakers. 2. Technical presentations (30 minutes plus questions and discussion) related to development of LLVM, Clang etc. 3. Presentations about the use of LLVM, Clang in commercial, academic, hobbyist and other projects. 4. Tutorials. 5. Lightning talks (5 minutes). The deadline for receiving submissions is December 1st, 2016. Speakers will be notified of acceptance or rejection by the 15th of December. Proposals that are not sufficiently detailed (talks lacking a comprehensive abstract for example) are likely to be rejected. Please create an account on the FOSDEM interface ( https://penta.fosdem.org/user/new_account ) and submit your proposal ( https://penta.fosdem.org/submission/FOSDEM17 ). Please make sure you select "LLVM devroom" as the "Track". = Registration = FOSDEM does not require any registration and is free of charge. However, just like last year, a large crowd must be expected. We have had to refuse entry to the room every year due to health and safety reasons (a hard requirement from the organisers), with the room already packed with people standing. = Organization = The mailing list llvm-devroom at lists.fosdem.org can be used to discuss issues of general interest related to the conference organization. Please, do not reply to this email, as it is cross posted to many lists. = Financial Support = There may be a possibility of limited funding to help students or contributors who could not otherwise attend the conference. This will depend on overall sponsorship and companies' interest in supporting the event. If you need funding to attend the meeting, or can help sponsor, please tell us on llvm-devroom at lists.fosdem.org. = About LLVM = LLVM is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyse and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run-time, or "idle-time" (between program runs). The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. Besides LLVM, several projects have been developed on top of it like Clang, LLDB, LLD or Polly. For more information, please visit http://llvm.org/ or the conference webpage at http://llvm.org/devmtg/2017-02/ Best regards, LLVM @ FOSDEM organisers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] GitHub Survey Online
Folks, After a number of months in preparation and just two weeks away from the US Dev. Meeting, where we'll hold a BoF to discuss the Git migration, here's how you'll voice your concerns: https://goo.gl/forms/ZYs0Wv9g0w0ikCRQ2 The survey is meant to be a channel for people and companies/projects/universities to voice their concerns as well as describe their workflow if anything proposed will seriously disrupt the work of LLVM developers. The multiple-choice questions will also be used to gauge the general feeling of the community, but it will not be considered a vote. No decision will be taken on those numbers alone, so please, make sure to describe your issues on the text boxes provided. The last thing we want is to make less people contribute to the project. And that's one of the reasons we're proposing to move to Git, because the majority of people already use it, here or elsewhere. It has been pointed out that all fresh developers nowadays use Git natively, partly because of the success of projects like GitHub. But that means the move has to be in a way that the majority of developers today, and future developers too, can easily work with. Please, share the word, and let's make sure that two weeks is enough to cover everyone in our community, so that we can have a meaningful and trouble-free discussion at the Dev. Meeting. Best regards, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] GitHub Survey - Results
Folks, Please note that the survey is still open! But it's almost time for the US LLVM meeting and I'd like to give everybody the ability to inspect the results before entering the BoF session tomorrow. Here is a zip file with the raw results (minus emails) of the data up until this morning, and a short presentation with a summary and my personal pick of the comments. http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip I tried to focus on less on the positive comments and more on the negative ones for all topics, because they're the ones that will make the difference. I've also tried hard to be completely impartial, just presenting the results. If you haven't yet submitted, please do. We'll be looking at the data and sharing it on the Bof. Mehdi will collate the BoF results and once the survey is finally closed, I'll share the raw results again. Enjoy! --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] GitHub Survey - Results
On 2 November 2016 at 13:43, Zachary Turner wrote: > It would be nice if the slides containing the pie-graphs showed the original > question that people were responding to. It's a little hard to make sense > of the answers if we can't see (and don't remember) the question. Corrected. Please check the new file. Thanks! --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Final Result - GitHub Survey
Folks, It's been one week after the initial results were shared and three days after the last answer, so I think it's time to close down and publish the final results. The ODF, XLS and CSV files are at: http://people.linaro.org/~renato.golin/LLVM%20Move%20to%20GitHub.zip The overall result is the same, and it's still in sync with what was discussed on the BoF session and I reported back last week: GitHub, not only Git, still has a massive support and the split between mono/multi repo still exists and need to be sorted out. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [CFP] LLVM devroom @ FOSDEM 2017
Gentle reminder, the deadline is tomorrow, but we may extend to the end of the week. Keep your proposals coming. Thanks! cheers, -renato On 11 October 2016 at 14:25, Renato Golin wrote: > CALL FOR PAPERS / PARTICIPATION > > At FOSDEM 2017, LLVM will again participate with a dedicated devroom. > Complementing the upcoming Euro LLVM 2017, the devroom at FOSDEM > provides a great opportunity for LLVM developers and the wider open > source community to get together, connect and discuss. > > As possibly the largest European Open Source Conference, FOSDEM takes > place in Brussels and attracts with more than 400 lectures every year > over 5000 hackers - many core contributors of the worlds leading open > source projects. > > > = Call for Speakers, Posters, Demos = > > We invite academic, industrial and hobbyist speakers to present their > work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, > etc. > > We are looking for: > > 1. Keynote speakers. > 2. Technical presentations (30 minutes plus questions and > discussion) related to development of LLVM, Clang etc. > 3. Presentations about the use of LLVM, Clang in commercial, > academic, hobbyist and other projects. > 4. Tutorials. > 5. Lightning talks (5 minutes). > > The deadline for receiving submissions is December 1st, 2016. > Speakers will be notified of acceptance or rejection by the 15th of > December. Proposals that are not sufficiently detailed (talks lacking > a comprehensive abstract for example) are likely to be rejected. > > Please create an account on the FOSDEM interface ( > https://penta.fosdem.org/user/new_account ) and submit your proposal ( > https://penta.fosdem.org/submission/FOSDEM17 ). Please make sure you > select "LLVM devroom" as the "Track". > > > = Registration = > > FOSDEM does not require any registration and is free of charge. > However, just like last year, a large crowd must be expected. We have > had to refuse entry to the room every year due to health and safety > reasons (a hard requirement from the organisers), with the room > already packed with people standing. > > > = Organization = > > The mailing list llvm-devroom at lists.fosdem.org can be used to > discuss issues of general interest related to the conference > organization. Please, do not reply to this email, as it is cross > posted to many lists. > > > = Financial Support = > > There may be a possibility of limited funding to help students or > contributors who could not otherwise attend the conference. This will > depend on overall sponsorship and companies' interest in supporting > the event. > > If you need funding to attend the meeting, or can help sponsor, please > tell us on llvm-devroom at lists.fosdem.org. > > > = About LLVM = > > LLVM is a collection of libraries and tools that make it easy to build > compilers, optimizers, Just-In-Time code generators, and many other > compiler-related programs. LLVM uses a single, language-independent > virtual instruction set both as an offline code representation (to > communicate code between compiler phases and to run-time systems) and > as the compiler internal representation (to analyse and transform > programs). This persistent code representation allows a common set of > sophisticated compiler techniques to be applied at compile-time, > link-time, install-time, run-time, or "idle-time" (between program > runs). > > The strengths of the LLVM infrastructure are its extremely simple > design (which makes it easy to understand and use), source-language > independence, powerful mid-level optimizer, automated compiler > debugging support, extensibility, and its stability and reliability. > LLVM is > currently being used to host a wide variety of academic research > projects and commercial projects. > > Besides LLVM, several projects have been developed on top of it like > Clang, LLDB, LLD or Polly. > > For more information, please visit http://llvm.org/ or the conference > webpage at > > http://llvm.org/devmtg/2017-02/ > > Best regards, > > LLVM @ FOSDEM organisers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [4.0 Release] Schedule and call for testers
On 5 December 2016 at 18:26, Hans Wennborg via Release-testers wrote: > I propose the following schedule for the 4.0 release: > > - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter. > > - 1 February: Tag RC2. All lose ends should have been tied up by now. > > - 21 February: Final tag. Binaries and release announcement a few days later. LGTM. --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers
On 5 December 2016 at 18:42, Dimitry Andric via Release-testers wrote: > Maybe I didn't pay enough attention, but where is the general outline > for this versioning scheme documented? And are we still going to do > 4.1, 4.2, etc? This is the thread: http://lists.llvm.org/pipermail/llvm-dev/2016-June/101044.html > Note that this is a pretty close follow-up to the 3.9.1 release. There > is a minor risk of "release burn-out" here... :) They're completely different trees, so should only be a problem if we haven't finished by then. 3.9.1 convergence took a lot longer than expected because of the number of back-ports. With interest in the point-releases growing, I think we should try a "half-way" schedule for the point releases, to make sure that doesn't happen again. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers
On 5 December 2016 at 18:56, Hans Wennborg via Release-testers wrote: > The idea is that Tom's stable releases will keep incrementing the > "patch" part of the version numbers, just as today, so they would be > 4.0.1, 4.0.2, etc. Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2 instead. Otherwise, it'll be: * 3.9.0 * 3.9.1 * 4.0.0 * 4.0.1 * 5.0.0 * 5.0.1 With a totally redundant zero in the middle. Unless we're planning to extend the maintenance of the 5.x branch and release 5.1.0 *after* 6.0.0 is out, which would be a major change in how we release LLVM. I don't think that's the plan. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0 Release] Schedule and call for testers
On 5 December 2016 at 19:08, Michał Górny via cfe-dev wrote: > Will this new version scheme mean that 4.1 (if ever released) will be > ABI-compatible with 4.0? If it will be so, we should update SONAMEs > accordingly. Yes. All 4.x will be ABI compatible with 4.0, just like any stable release we do today. Doesn't matter if it's called 4.0.1 or 4.1. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers
On 5 December 2016 at 19:56, Hans Wennborg wrote: > I'd like to avoid 4.1 because of the potential for confusion about > whether it's a major release (as it would have been under the old > scheme) or a patch release. But if the versioning scheme is different, users will have to understand what it means anyway. Until now we had a weird and very unique logic, and we're moving to a more sensible logic, because it's similar to what some other projects are doing. I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1 that used to be weird before. After a few releases everything will be clear anyway... I really don't want to make the foreseeable future weird again to avoid a potential misunderstanding for one or two releases. Let's just be brutally clear in all release communications and hopefully people will understand. > The alternative would be: > > 3.9.0 > 3.9.1 > 4.0.0 > 4.1.0 <-- Can't tell from the version number what kind of release this is. No, that has a redundant zero, too. The alternative is: 3.9.0 3.9.1 4.0 4.1 5.0 5.1 etc. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers
On 5 December 2016 at 20:07, Hans Wennborg wrote: > I'm worried that users will, with some reason, think that the 4.1 and > 5.1 releases are the same kind as 2.1 and 3.1 :-/ IMO, this is too small of a worry to encumber us for the rest of our release days with silly zeroes. I'd rather be redundantly explicit for the next year, than carry that burden for the next 5 (or more). cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged
On 19 January 2017 at 17:43, Diana Picus via Release-testers wrote: > Looks good on AArch64: > c6cc242dc3551c8465ba054e87e4d51df824aa17 > clang+llvm-4.0.0-rc1-aarch64-linux-gnu.tar.xz All good on ARM's side, too: 38e34694bb2ddd5178f48c2bef0aef65cc17b378 clang+llvm-4.0.0-rc1-armv7a-linux-gnueabihf.tar.xz cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] FOSDEM LLVM Devroom Videos online
Hi folks, All FOSDEM 2017 LLVM Devroom's videos are online: https://fosdem.org/2017/schedule/track/llvm_toolchain/ Some slides are still missing, but we hope to get them soon enough. The videos have the slides on split screen. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged
On 9 February 2017 at 17:55, Diana Picus via llvm-dev wrote: > Hi, > > AArch64 good to go. > > f27db27da7f75a435d89ba63c8a762885fd86a1a > clang+llvm-4.0.0-rc2-aarch64-linux-gnu.tar.xz No regressions from the ARM side. f827daf4b0066f74932090cb6309fcf6be594617 clang+llvm-4.0.0-rc2-armv7a-linux-gnueabihf.tar.xz --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged
On 10 February 2017 at 11:38, Pavel Labath via llvm-dev wrote: > All I can say is these tests did not exist in 3.9, so I wouldn't call > this a regression. (Well... technically, a similar test existed, but > it was run by a different test runner which I believe is not hooked up > to the command you are running). We're on a similar state for libc++ / openmp / lld on ARM and AArch64. libc++ works well on ARM and AArch64, but some of the tests fail (always have), and I think Eric said it has to do with how we run them or which ones should be disabled. LLD works well on AArch64 but not yet on ARM (though there were no test failures this time). OpenMP kind of works, but there are many failures, which we won't look into this cycle. Regardless of that state, we though it was a good idea to ship it as an experimental status, so that people can try out and report bugs. All the components above are included in both ARM and AArch64 releases. Hans, Do you think we should have a table of production vs. experimental quality per target on the release notes, so that users know what to expect? Or should we just let users know that when they report bugs? cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged
On 10 February 2017 at 22:23, Hans Wennborg wrote: > A reasonable thing to do would be to put a note on the relaese > downloads page. But I'm not even sure what to put there. "OpenMP kind > of works on AArch64", what does that mean to a user? The idea was to just separate in two classes: supported/not supported. > It also comes back to what the nature of the release is. For me, it's > a periodic best-effort-stability snapshot of what we've got, which > packagers and other downstream folks build on. That's why I haven't bothered doing it, so far. What we can do is to continue not doing it until someone really complains, than we try to find a good solution. cheers, --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
