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

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. With this in place I will not consider myself a member of the llvm community

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

>> The promise just says that 4.0 *will* read 3.X and 4.1 might. > > > Yes, but while you have read it and interpreted it precisely, I suspect that > many people have misinterpreted it and assume that 4.0 will be the last > release to read 3.X. They may be incorrect, but I think it would still be

Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

> I don't think this is as obvious as you might think it is. We can happily > drop the "major version equals bitcode compatibility" implicit promise if we > want, but it's been there for a while and will need some messaging as to the > actual promises here and what we'll do to fulfill and what we

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

> I think the main issue (besides users asking what's the big change in > 4.0, which I agree is not a big problem) is that the bitcode > compatibility policy is tied to the major version number. It is tied in saying we *can* drop compatibility, not that we will. If we still support loading 3.0

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

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. Cheers, Rafael

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

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

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

On 13 June 2016 at 13: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 is, if you have legacy IR files that contain dropped features,

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

> 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. > > Maybe documenting the release-numbering-semantics policy alongside > the

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

On 13 June 2016 at 10:11, Tom Stellard wrote: > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola 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

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

> 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 separate discussion thread about this. It give the opportunity, not the