Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

Ah, awesome, thanks! On Fri, 24 Dec 2021, 03:11 Tom Stellard, wrote: > On 12/23/21 09:53, Renato Golin wrote: > > On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev < > llvm-...@lists.llvm.org > wrote: > > > > * On an existing issue or a newly created iss

Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > * On an existing issue or a newly created issue, a user who wants to > backport > one or more commits to the release branch adds a comment: > > /cherry-pick <..> > Hi Tom, Would this be *any* user or use

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

On Thu, 7 Oct 2021 at 23:16, David Blaikie wrote: > I don't think diversity necessarily relates to this aspect of managerial > structure. Unless we're talking about the less benevolent dictatorships > where the authority figures both provide structure, but also set some > fairly negative tones fo

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

On Thu, 7 Oct 2021 at 22:31, David Blaikie wrote: > This is how we've always done it so far and it has been working well. At >> least most people I know think that this is better than most other >> alternatives, including ad-hoc decision making plans. >> > > I'm not sure I'd say it's been working

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

On Thu, 7 Oct 2021 at 21:48, Reid Kleckner wrote: > I want to take the other side here, and say that I appreciate that the > board is trying to provide more structure for this decision making process. > I don't think the board is trying to step in and take ownership of the > decision, they are tr

Re: [lldb-dev] [llvm-dev] RFC: Code Review Process

On Tue, 5 Oct 2021 at 19:16, Tom Stellard wrote: > However, it's not a good position for the Board to be responsible > for something that it doesn't have control over. If Google decided to > stop hosting > Phabricator for some reason (unlikely, but not impossible), the Board > would be > respons

Re: [lldb-dev] [llvm-dev] RFC: Code Review Process

On Tue, 5 Oct 2021 at 18:09, Tom Stellard wrote: > In my opinion, this is not a technical issue. I find that surprising. But maybe it's just me. > The Board owns the infrastructure > for the project and is responsible for ensuring that it is well maintained > and > functional. From the blo

Re: [lldb-dev] [llvm-dev] RFC: Code Review Process

On Tue, 5 Oct 2021 at 17:06, Tom Stellard via llvm-dev < llvm-...@lists.llvm.org> wrote: > - Any other information that you think will help the Board of Directors > make the best decision. - Foundation Board will have 30 days to make a final decision about using > GitHub Pull Requests and then co

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update

On Wed, 23 Jun 2021 at 13:59, Tobias Hieta via llvm-dev < llvm-...@lists.llvm.org> wrote: > I am very active in the Discord and try my best to help people and > while I often refer people to post to the mailing list if they can't > find an answer, I have never and never seen anyone direct new peop

Re: [lldb-dev] [llvm-dev] [Openmp-dev] RFC: Upcoming release schedules and creating a formal schedule for future releases

On Wed, 6 Jan 2021 at 08:20, Hans Wennborg via llvm-dev < llvm-...@lists.llvm.org> wrote: > This sounds good to me (maybe spell out roughly what date 2.0.0-rc1 > would be to make it easier to get an overview). > How about we specify the week, rather than the day? If our aim is Tuesday, then it'l

Re: [lldb-dev] [llvm-dev] [Openmp-dev] RFC: Release process changes

On Mon, 25 May 2020 at 23:10, Hans Wennborg via llvm-dev wrote: > +1 > > Maybe even stronger than "is allowed to commit", I think we should > really think about it as the release manager owning the branch, and > has full authority over what goes into it or not. Consulting code > owners often makes

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

On Fri, 18 Oct 2019 at 16:30, David Greene wrote: > I have been viewing test-suite as a kind of second-level/backup testing > that catches things not flagged by "make check-all." Is that a > reasonable interpretation? I was hoping to get some end-to-end tests > under "make check-all" because tha

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

On Thu, 17 Oct 2019 at 18:10, David Greene wrote: > From other discussion, it sounds like at least some people are open to > asm tests under clang. I think that should be fine. But there are > probably other kinds of end-to-end tests that should not live under > clang. That is my position as we

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

On Thu, 17 Oct 2019 at 16:28, Robinson, Paul wrote: > This is no different than today. Many tests in Clang require a specific > target to exist. Grep clang/test for "registered-target" for example; > I get 577 hits. Integration tests (here called "end-to-end" tests) > clearly need to specify thei

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

On Wed, 16 Oct 2019 at 21:00, David Greene wrote: > Can you elaborate? I'm talking about very small tests targeted to > generate a specific instruction or small number of instructions. > Vectorization isn't the best example. Something like verifying FMA > generation is a better example. To chec

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

Hi Paul, I'm not to strongly opposing to anything, and I don't want to be the noisy one in the corner. :) The only point I have is that it's easier to control the environment in the TS and e2e tests are supposed to catch higher level problems that cannot be handled in Clang. We already have test

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub Migration Schedule and Plans

On Fri, 11 Oct 2019 at 00:22, Tom Stellard via llvm-dev wrote: > With my latest changes in https://reviews.llvm.org/D67772 it is actually > possible > to create a new branch with git-llvm, so we could print a disclaimer or block > this, > however we still can't stop people from creating a new br

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

On Fri, 11 Oct 2019 at 18:02, David Greene via llvm-dev wrote: > >> We have to support many different systems and those systems are always > >> changing (new processors, new BIOS, new OS, etc.). Performance can vary > >> widely day to day from factors completely outside the compiler's > >> contro

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

Hi David, You answer some of your own questions down below, so I'll try to collate the responses and shorten my reply. On Fri, 11 Oct 2019 at 15:20, David Greene wrote: > How are regressions reported? On llvm-dev? They're buildbots, exactly like any other. Direct email, llvm-commits, irc, bugz

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

On Thu, 10 Oct 2019 at 22:26, David Greene wrote: > That would be a shame. Where is test-suite run right now? Are there > bots? How are regressions reported? There is no shame in making the test-suite better. We do have bots running them in full CI for multiple targets, yes. Regressions are r

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

On Thu, 10 Oct 2019 at 10:56, Florian Hahn wrote: > Have you considered alternatives to checking the assembly for ensuring > vectorization or other transformations? For example, instead of checking the > assembly, we could check LLVM’s statistics or optimization remarks. If you > want to ensure

Re: [lldb-dev] [llvm-dev] [6.0.0 Release] Scheduling the release

On 6 December 2017 at 21:06, Robinson, Paul via llvm-dev wrote: > I'm very sympathetic to syncing upstream stabilization with internal > processes; that said, branching so soon after New Year's Day (which > I'd guess is celebrated essentially everywhere) seems like not such a > great idea. This i

Re: [lldb-dev] [llvm-dev] [6.0.0 Release] Scheduling the release

On 6 December 2017 at 17:28, Hans Wennborg via llvm-dev wrote: > However, one large consumer of the branch has asked if we could start > earlier this time, branching on 3 January instead (not moving the ship > date), to get a longer period for stabilization that syncs with their > internal process

Re: [lldb-dev] [cfe-dev] [4.0.0 Release] 'final' has been tagged

ARM and AArch64 looking good, uploaded. 4e62f3d5dcc95189eaec2d950950876a423f8a8c clang+llvm-4.0.0-aarch64-linux-gnu.tar.xz 1b031f16683e3bcd779f50e6d47d0d1f3f265e9f clang+llvm-4.0.0-armv7a-linux-gnueabihf.tar.xz On 10 March 2017 at 12:14, Ben Pope via cfe-dev wrote: > On 09/03/17 00:52, Hans Wenn

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 4 has been tagged

On 7 March 2017 at 22:15, Hans Wennborg via Release-testers wrote: > Dear testers, > > 4.0.0-rc4 was just tagged from the branch at r297204. > > This is very similar to rc3, with additional fixes for PR32142 and PR32153. Both ARM and AArch64 look good. The weird fluke on AArch64 is gone. I'm run

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 3 has been tagged

On 2 March 2017 at 19:47, Hans Wennborg via Release-testers wrote: > Hello testers, > > 4.0.0-rc3 was just tagged from the branch at r296762. ARM looks good, bd3c31f080a016409179fa8cb69da4e2fa14c951 clang+llvm-4.0.0-rc3-armv7a-linux-gnueabihf.tar.xz AArch64 has a libc++ error we did not see on R

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: support

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 yo

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-gnu

[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 ___ lld

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-gnueabih

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 redunda

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

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 d

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,

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

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

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. >

[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 t

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 chec

[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

[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/project

[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 poss

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 m

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 wr

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: 5e4e3bdf747aa2ac50c588cea5d67f896376

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 s

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 go

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

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 s

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

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 c

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/mailm

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-d

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

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

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-

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.o

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 l

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

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 f

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

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 ge

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

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

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 d

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 br

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 mo

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 pra

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

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

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 migra

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 s

[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 struc

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

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 cor

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

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

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

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

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 h

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.

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

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 >

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

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

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 draf

[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, overc

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 orig

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 ?

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.

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 > s

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

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

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 i

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

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

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 Compi

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,

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

  1   2   >