On 20 Mar 2019, at 18:23, Arthur O'Dwyer via cfe-dev
wrote:
>
> Server-side hooks are the answer to this problem. There is no problem. You
> just use a server-side hook.
It is quite unlikely that GitHub will allow LLVM (or any other project) to run
arbitrary post-receive hooks. It is far mor
On 1 Feb 2019, at 22:48, Peter Wu via cfe-dev 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, compiler-rt, etc.) on a lot of different platforms
> and targets (Linux, mac
On 18 Feb 2017, at 02:10, Anna Zaks via llvm-dev
wrote:
>
> While students with previous LLVM dev experience will be more productive,
> GSoC is a great way of attracting newcomers to the project! So if a proposal
> is scoped to be completed in time even by someone not familiar with LLVM, we
>
On 6 Jul 2016, at 16:16, Robinson, Paul wrote:
>
> As Daniel pointed out, an enumeration like that knows no bounds, and
> starting a list invites endless what-if questions. That's why I settled
> for a more qualitative statement; we have to acknowledge that ultimately
> there's a judgement call
On 4 Jul 2016, at 12:27, Renato Golin via Openmp-dev
wrote:
>
> 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" circumst
On 5 Jul 2016, at 11:44, Renato Golin via llvm-foundation
wrote:
>
> 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 b
On 4 Jul 2016, at 12:13, Renato Golin via llvm-foundation
wrote:
>
> 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 w
On 29 Jun 2016, at 15:03, Renato Golin via llvm-dev
wrote:
>
> Any more comments before we put this proposal to vote?
Thank you very much for driving all of this. I just have one quick question:
Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub
continue to work by
On 13 Jun 2016, at 15:24, Robinson, Paul via llvm-dev
wrote:
>
> +1. My understanding is that 2.9->3.0 came with some huge internal changes
> (overhaul of the type system, maybe? this slightly predates my involvement
> with LLVM so I'm not entirely sure) and warranted a major-version change
> r
On 13 Jun 2016, at 14:14, Rafael Espíndola via cfe-dev
wrote:
>
>> The 4.1 release gives us the opportunity to drop support for 3.x
>> bitcode formats, so I don't think we should move to 4.x until we have
>> older bitcode features that we really want to drop. There should
>> probably be a sepa
On 1 Jun 2016, at 17:02, John Criswell via llvm-dev
wrote:
>
> Regarding the issue of git sub-modules and keeping Clang/LLVM in sync,
> perhaps we should just put Clang and LLVM into a single git repository and
> add a CMake option to disable compilation of Clang (the same could be done
> for
11 matches
Mail list logo
