similar to: Comments on GitHub commits?

> On Oct 30, 2019, at 5:57 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/30/2019 03:09 AM, Stephan Bergmann via llvm-dev wrote: >> You can apparently leave comments on GitHub commits (instead of commenting at Phabricator, or directly sending a reply to the relevant commit mailing list and relevant CCs). I once accidentally did that myself

On Sat, Nov 2, 2019 at 4:26 AM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Wed, Oct 30, 2019 at 10:59 PM David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> On Oct 30, 2019, at 5:57 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 10/30/2019 03:09 AM, Stephan Bergmann

On Wed, 30 Oct 2019, Sameer Sahasrabuddhe via llvm-dev wrote: > October 30, 2019 5:58 AM, "Alex L via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > >> Oh, this explains it! Unfortunately one of our engineers made a mistake, and pushed the ref to >> wrong remote while resolving a merge conflict on https://github.com/apple/llvm-project (pushed to >>

Hello. I'm a distro maintainer and was wondering about the efficacy of entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the authors of haveged [0] pointed out if the hardware cycles counter is emulated and deterministic, and thus predictible. He therefore does not recommend using HAVEGE on those systems. Is this the case with KVM's counters? PS. I will be setting VM CPU

Hi all, Since 2724d9e12960cc1d93eeabbfc9aa1bffffa041cc, llvm-config -cxxflags no longer reports the C++ language standard version (e.g. "-std=c++14") used to compile LLVM. This may break builds of projects that build with the same flags as LLVM, e.g. the LDC compiler. Quoting from llvm/tools/llvm-config/CMakeLists.txt: ``` # The language standard potentially affects the ABI/API of

Hi, It looks like LLVM's Phabricator started picking up downstream commits in Apple's fork of llvm-project (github.com/apple/llvm-project), and is creating notification events about all the old downstream commits, e.g. https://reviews.llvm.org/rG8910c5c786886f17a75bd142fa967932ca3f54c1 https://reviews.llvm.org/rGb03469c2d72621e1cccfeeaef719692600c075f4 This seems like a bug. Can this be

I noticed today that there are some commits that get pushed upstream, but not to master or any other branch either. For example: https://github.com/llvm/llvm-project/commit/d272d3a1885a82d6ccf5b3d5b6841f79d81e24e5 https://github.com/llvm/llvm-project/commit/6762d53b66d9de18825f09f43c3d6c2b3ea95913 https://github.com/llvm/llvm-project/commit/80f81325b8e8f0bed81a28dffb8eba526002f2b3

That appears to have been pushed to refs/am/changes/bbc4c751f01bb6f649942d3cf3b504a87c9019c8_swift/master-next Does someone (perhaps someone from apple) know what that is? Was it pushed there, rather than the swift fork, by mistake? On Tue, Oct 29, 2019 at 6:12 PM Anton Korobeynikov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Someone pushed these changes to LLVM repo. See e.g.

On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Mehdi AMINI <joker.eph at gmail.com> writes: > > > What is the practical plan to enforce the lack of merges? When we > > looked into this GitHub would not support this unless also forcing > > every change to go through a pull request (i.e. no pre-receive hooks >

On Sat, Feb 2, 2019 at 7:32 AM David Chisnall via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On 1 Feb 2019, at 22:48, Peter Wu via cfe-dev <cfe-dev at lists.llvm.org> > wrote: > > > > On caveat is that the test coverage would be limited or else the build > > times would be very long. There are quite some builders for various > > projects (llvm, cfe,

On Wed, Jan 30, 2019 at 1:19 PM Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > > > Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > > > How about: > > > > > > Require a rebase, followed by git

Forgot to mention: > Also, how would arcanist pick up two callsigns here? Wouldn't it just pick the from the closest surrounding .arcconfig? The review request will belong to a single repository, as you noticed (from the closest .arcconfig to where the arc command was invoked). However, when commits land, they will be imported under either one (rL for LLVM diffs) or two (rL + rC for e.g.

On Fri, Feb 01, 2019 at 12:41:05PM -0500, Arthur O'Dwyer via cfe-dev wrote: > I know GitHub can be configured to reject force-pushes to {any, a > specific} branch. I strongly suspect that if *the maintainers of > LLVM* asked nicely, GitHub would also be able to reject > merges to {any, a specific} branch. Anyone with admin permissions in a repo can add "branch protection

+llvm-dev, so we get wider input :) Given how unfortunate reviews that are started without cc'ing the right list are (basically folks need to re-send the review from scratch), I support this idea. Ben, couldn't rL still be available for all projects? (and be the main project for LLVM). On Tue, Nov 21, 2017 at 5:18 PM Ben Hamilton via cfe-dev < cfe-dev at lists.llvm.org> wrote:

On Thu, Nov 23, 2017 at 12:58 AM Ben Hamilton <benhamilton at google.com> wrote: > Absolutely — I should have mentioned that we would keep the main rL > project and continue to use it. > Your original email said "Moving forward, only LLVM commits will be identified with the prefix rL (as in https://reviews.llvm.org/rL12345) — each project will get its own unique prefix, which

On Fri, Aug 10, 2018 at 08:33:00PM +0000, procmem wrote: >Hello. I'm a distro maintainer and was wondering about the efficacy of >entropy daemons like haveged and jitterentropyd in qemu-kvm. One of the >authors of haveged [0] pointed out if the hardware cycles counter is >emulated and deterministic, and thus predictible. He therefore does not >recommend using HAVEGE on those

Hi Ben, (+llvm-dev since the email I'm replying to wasn't sent there) 2017-11-21 17:18 GMT+01:00 Ben Hamilton via cfe-dev <cfe-dev at lists.llvm.org> : > OK. I confirmed that Stephan's process to send out cross-repo diffs from > the monorepo is not affected by my proposal. > > I'm a bit late to the party, and I might just not have comprehended this correctly.

A couple of new warnings and build errors appeared through the DRM tree in linux-next after the merge window opened. The first patch here is for scripts/headers_check.pl, but as the bug is only present in drm-next at the moment, it would be good to add all five patches to that tree before they make it into mainline. It's likely that some of these have already been fixed since this

CONFIG_DEVICE_PRIVATE cannot be selected in configurations without ZONE_DEVICE: WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ZONE_DEVICE [=n] Selected by [y]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && DRM_NOUVEAU [=y] && MMU [=y] && STAGING [=y] kernel/resource.c:1653:28: error: use of undeclared identifier

I think we definitely will want to support github PRs, at the very least as an _option_, even if we continue running/preferring phabricator. Github PRs are how everyone who is not already super-involved in the llvm project is going to want to contribute changes, and we ought to be as welcoming as possible to such users. On Tue, Mar 19, 2019 at 3:15 PM Roman Lebedev via cfe-dev < cfe-dev at