similar to: [PITCH] Improvements to LLVM Decision Making

Hi Christian, I’m sorry, but this is still on my todo list. I’ve been a bit DoS’d lately, but I do hope to come back to this soon. -Chris > On Feb 21, 2020, at 4:24 AM, Christian Kühnel <kuhnel at google.com> wrote: > > Hi Chris, > > Did you reach any decision on how to move forward? > I would be happy if we get this (or something similar) started... > >

Thank you very much for the references, we've missed this discussion from last week. Seeing that the RFC hasn’t got any new responses since Wed 12th, is now the time to declare that the community has accepted the proposal, and to update the docs? Or is there any formal deadline for objections to be raised? -----Original Message----- From: meinersbur at googlemail.com [mailto:meinersbur at

On 15/01/2020 10:04, Doerfert, Johannes via llvm-dev wrote: >> "It isn't clear how to propose some changes in the first place, and it >> is often unclear who the decision makers are." > I feel that patches and RFCs are well established*and documented* [1,2] > ways to propose changes. In addition, the *-dev lists, IRC, etc. do > provide ways to clear

Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > If we want to go for meritocracy, which I think most people would > agree, then it would have to be people that already represent the > community, internally or externally. Given your close attention to representation I know that you have all the best intentions here, so please take this in the spirit of productive

On Jun 2, 2020, at 9:54 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > This was a mistake, fixed. > > I missed that this was changed, I was excited about a Discourse category for this! In particular the second point of the doc points at llvm-dev@ being a problem as the current forum for such discussions. > If Discourse is a no-go (?), then having a separate mailing-list would

Hi all, Following up on the extensive discussions since January, many of us would like to put in place a process to improve LLVM’s decision making process for contentious issues. I’ve put together a proposal for how this works, and am recursively using it to get feedback on the process itself. Thank you to the many people who contributed great ideas and improvements during the pitch phases and

On 01/15, James Henderson via llvm-dev wrote: > One other thought: any formal review period needs to be long enough for > people to contribute to if they have any annual leave from work or > whatever. For example, if the review period were to be set to two weeks, > I'd have missed proposals made at the start of roughly 2-3 different 2 week > periods last year. It would have been

On 9 May 2016 at 03:07, C Bergström <llvm-dev at lists.llvm.org> wrote: > As activity on the thread dies down and I guess it has been socialized > to the point of annoyance (myself and probably others based on private > emails).. I'll assume the current draft is mostly stable, but to > confirm, Chandler are you done playing with your CoC? I personally think the code is fine

Weighing in as a mostly-lurker: A CoC is a great idea. I'm ok with Chandler's current draft. I'm ok with his first draft. I'm ok with just adopting a standard one like Swift did. I think it's important to enumerate several of the most common kinds of harassment, and it's understood that it's not a comprehensive list. I think the pedantry of this thread is unwarranted;

Hello everyone, We are in the process of formalizing the governance model of the GlusterFS project. Historically, the governance of the project has been loosely structured. This is an invitation to all of you to participate in this discussion and provide your feedback and suggestions on how we should evolve a formal model. Feedback from this thread will be considered to the extent possible in

Folks, It's 1st of September, and we don't have the document nor the survey ready. With the US meeting on 3-4 November, that leaves us only 2 months to do everything, and I'm not sure we'll be able to if we delay much more. Being the devil's advocate and hoping this doesn't spiral down (again), there were a few pertinent questions left unanswered from the previous

On Jun 2, 2020, at 1:57 PM, Kit Barton <kit.barton at gmail.com> wrote: > A few comments on the document: > 1. It seems the current document has settled on using threads on > llvm-dev, however there are still two reference to the LLVM Proposal > Reviews category on Discourse: last paragraph of Proposed Solution > section, first paragraph of the Review Discussion Template

On Wed, Jul 1, 2020 at 11:12 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm not sure I agree with the no-code standard. I agree with minimal code, but I think an incubator should be established enough to be discussed concretely (e.g. "what is" vs "ideals"). > > I hear what you’re saying, but I think we can handle this as part of

Dear llvm devs, Based on an earlier discussion about existing pointer analyses in LLVM, I quickly hacked up a GSoC proposal on enabling cfl-aa by default. The decision to write it was made two days before the application deadline, hence the writing quality may not be very satisfactory: the background section could be less verbose, and the implementation section could be more formal. Also it

On 8 September 2016 at 19:10, Chris Bieneman <cbieneman at apple.com> wrote: > My personal preference would be for the decision makers to be either a > committee of developers or the LLVM Foundation board, and I would prefer if > the survey were crafted to provide them with information to inform a > decision, rather than a dictation of a decision. Hi Chris, Those are very good

Per the recent (seeming) consensus regarding incubating new projects under the LLVM organization, I would like to trial the process by requesting to incubate mlir-npcomp <https://github.com/google/mlir-npcomp>. The project is still quite young and has been primarily developed part time by myself and Sean Silva over the last ~2 months. We set it up following discussion of a Numpy/Scipy op set

On 6 Jul 2016, at 05:32, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Jul 5, 2016, at 3:05 PM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> For ISO C++ we long ago created an 'all' list for topics that were organisational and not technically specific to an aspect of the Standard such as

+cc Simon who's also interested in reductions for the any_true, all_true predicate vectors. On 31 January 2017 at 20:19, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Amara, > > We also had some discussions on the SVE side of reductions on the main > SVE thread, but this description is much more detailed than we had > before. > > I don't

On 29 July 2016 at 15:26, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I believe David Chisnall up-thread cited a difference in checkout times > on the order of a handful of seconds versus a couple of minutes. While > naively it might seem not a big deal, over time and depending on what you > are trying to do yes it can be a big burden. TL;DR: This thread

On 5 May 2016 at 22:19, Tanya Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Having a code of conduct like this is just as bad as having no code of conduct at all. It trivializes the importance of a code of conduct and its pretty much impossible to enforce. The same way you feel about this code, we feel about the alternative. It's only a matter of perspective. >