Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.9 Release] Release plan and call for testers

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

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

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

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 >

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

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

Re: [lldb-dev] [llvm-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)

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

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge commits

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,