similar to: [LLVMdev] Developer Policy

Hi OG, I think it first of all would be nice, if we could supplement this group with a discussion list on this topic. The reason for this isn't to ad more bureacracy, but to present public ideas and visions to a broader forum and I belive in that the more elaboration within a broader forum the better the ideas will get and the more people will get committed to start and finish the task.

On Sat, 8 Jan 2005, Henrik Bach wrote: > I think it first of all would be nice, if we could supplement this group with > a discussion list on this topic. The reason for this isn't to ad more > bureacracy, but to present public ideas and visions to a broader forum and I > belive in that the more elaboration within a broader forum the better the > ideas will get and the more

Hello everyone, The LLVM project has evolved significantly since our first public release in Oct. 2003. Most importantly, we've gained many new users and several active contributors, and we want to encourage and support them and attract more. At the same time, the software itself has undergone some significant changes and improvements, and been ported to new platforms. We expect that

Something that would be good to get clarity on: The RISC-V backend recently had a bugfix patch that got backported to the 10.0.1 branch. The original patch introduced a new virtual method in TargetLowering.h, and the backported patch [1] was rewritten to avoid changing the ABI of libLLVM.so. This feels like some kind of policy decision about the C++ ABI beyond "it's entirely

On Aug 18, 2015, at 10:41 PM, deadal nix <deadalnix at gmail.com> wrote: > Let's not get this die. The C API is too valuable to let this die. > > I propose the following plan: > - Add tests for the current API. This will allow to make sure that everything works and would ensure that changes are made intentionally, nto accidentally. > - For area that do not exist in the

All, This message contains important information about the June 2007 LLVM Developer's Meeting. If you plan to go (or even if you don't), please read it carefully. Nothing is set in stone yet so if you have a suggestion, please make it! Your feedback is wanted. Thank you to all who participated in the Conference Poll we held at the end of last year. It let us know your preferences and

Hi All, I updated the copyright section of the developer policy: http://llvm.org/docs/DeveloperPolicy.html#copyright This change doesn't affect any llvm policies, it just makes the developer policy reflect reality. The previous version (archived here: http://llvm.org/releases/2.7/docs/DeveloperPolicy.html#copyright) used to claim that all copyright was assigned to the university of

Hi all, Now that we’ve settled on the license legalese to get to, we need to start the process of relicensing. We’re still sorting through all of the details of what this will take, but the first step is clear: new contributions to LLVM will need to be under both the old license structure and the new one (until the old structure is completely phased out). From a mechanical perspective, this is

> On Jul 26, 2016, at 12:16 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: >> I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept,

Hi Rafael, We’ve discussed why a license change is preferable over the span of several years now. I’m happy to explain over the phone, contact me off list and we can talk. -Chris > On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Hi, > > I still don't see any justification in the text why a license change is >

This has already been discussed extensively in the public. The threads are available in the archives. -Chris > On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Sorry, but I really don't think a private conversation is appropriate > for such discussions. > > If the motive cannot be explained in public I have no choice

Recently there's been some friction over reversions (I can remember two cases in recent memory). In both issues the general feel I got is that as a community we should honor "revert for more design review" requests unconditionally. What do you guys think of adding something like this to DeveloperPolicy.rst as an item at the end of the numbered list in

> On Jul 26, 2016, at 4:36 PM, Renato Golin <renato.golin at linaro.org> wrote: > > I'm most certainly not. Just because I didn't write something, that I means I have written the opposite.= > I’m failing to reconcile what you’re claiming above with the following that is in your proposal: "The target's code must have been adapted to the developers policy as

Hi, I’ve noted some change in wording on the current (4.0) developer policy[1], compared to the 3.9 developer policy[2]. Specifically the part about IR Backwards Compatibility. The change from 3.9 to 4.0 is the following: - The textual format is not backwards compatible. We don’t change it too often, but there are no specific promises. - Additions and changes to the IR should be reflected

The Developer Policy document (https://llvm.org/docs/DeveloperPolicy.html) contains a Section "C API Changes". There is no corresponding section for C++ API Changes. LLVM is somewhat different from most libraries in that the main language is C++ but the C++ API is not guaranteed to be stable in any shape or form from what I understand. I think it would be useful to have a "C++ API

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > I can find old threads about it, but nothing saying why it was decided > that contributor agreement wouldn't work. Care to send the URL? Here are some quick points that come to mind: 1. It raises the bar to contribution, because something must be “signed” before a

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Cc: "Chris Lattner" <clattner at apple.com>, "Rafael Ávila de Espíndola" <rafael.espindola at gmail.com>, "Michael Spencer" > <bigcheesegs at gmail.com>, "Chandler Carruth"

On 30/01/2014 22:57, Daniel Berlin wrote: > On Thu, Jan 30, 2014 at 2:34 PM, Alp Toker <alp at nuanti.com> wrote: >> On 30/01/2014 22:06, Daniel Berlin wrote: >>> Actually, the policy actually says the right thing, you removed a >>> sentence, which says: >>> "Please contact the oversight group for more details." >> >> To be clear, I

I've had good luck using the llvm-gcc & llvm-g++ on small projects, but I just discovered that it's apparently missing some of the GCC intrinsic functions -- specifically, when I try and compile VXL (http://vxl.sourceforge.net) it dies when it encounters __builtin_bswap32 . This is on OS X with the llvm-gcc-4.2 & llvm_g++-42 that are part of the XCode 3.2.3 I don't know if

On Fri, 2005-04-22 at 11:39 -0500, Misha Brukman wrote: > On Fri, Apr 22, 2005 at 08:54:07AM -0700, Reid Spencer wrote: > > There has been some debate about the default value. I tend to agree > > with Chris on this. The default should be "all" so that everything > > gets tested by default. More sophisticated users can limit the targets > > that are built by