similar to: Inclusive language in LLVM: can we rename `master` branch?

I agree with this. As much as I dislike the name that I believe github will choose, we should just do whatever everyone else is doing. Note that in addition to the github discussion, there is some extensive discussion on the .git mailing list (IIRC) about choosing a new name as well. I hope github waits until that choses a name as well. From: llvm-dev <llvm-dev-bounces at lists.llvm.org>

While I appreciate this sentiment we should not block our changes on a project over which we have no control. Changing the name and the documentation is easy and we should do this today. Thanks. -eric On Fri, Jun 19, 2020 at 10:49 AM Petr Penzin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 > > Git uses `master` branch in quite a few places in its docs and `git init`

There's really no guarantee that things will shake out the same in near term between the projects. -eric On Fri, Jun 19, 2020 at 11:31 AM Keane, Erich <erich.keane at intel.com> wrote: > I’m a bit mixed on this. While yes, we should change this as soon as is > practical, it would be a shame to pick something sufficiently different > from the rest of the world, as that would

I mean, we could change it twice? There are about a hundred scripts out there for doing it. -eric On Fri, Jun 19, 2020 at 11:40 AM Keane, Erich <erich.keane at intel.com> wrote: > Do we have any ability to reach out to github (at least?) to see what they > are going to do? I’d very much like to avoid being the odd-project-out > here. > > > > > > > >

To be clear: I’m concerned about the amount of our infrastructure (as well as downstream infrastructure, this would be actually pretty painful for both of my downstreams) that the community would have break/need fixing as a part of that. So I want this to happen ONCE. I think it is well motivated now, but switching from ‘default’ to ‘main’ when that becomes the ‘standard’ one seems way less

I disagree with your timing concerns. Changing is still straightforward and I'd like to see this done within 1-2 weeks. Thanks. -eric On Fri, Jun 19, 2020 at 12:22 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > +1 to waiting until git and/or github decide on a new name for the default > branch. I think there is a compelling reason to change the name of the > default

As I mentioned on another thread, we also use the term "slave" for the BuildBot builders. In the past, I was told this was due to being stuck on an old version of BuildBot. Fortunately, there is already work in progress to update BuildBot to a newer version. Since that's also going affect all the build machines, perhaps changing the name of the main branch should happen

That's a good point, we should definitely be respectful of the build bot owners time, that said I think it's the coordination that takes the time rather than the change :) On Fri, Jun 19, 2020 at 11:48 AM Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My understanding is the biggest concern about the name change is the > ‘cost’ associated with needing to

On Sat, Jun 20, 2020 at 3:31 PM James Courtier-Dutton < james.dutton at gmail.com> wrote: > Hi, > > I am more confused than anything else. > There are whole areas of data design and management called "Master > Data Management". > In financial statements there is the expression "In the black" meaning > a good positive figure in the balance sheet,

> On Sep 3, 2016, at 6:05 PM, Patrice Kouame <pkouame at mac.com> wrote: > > Someone mentioned llvm in a mono repository below… Right, we actually have a proposal to take what is in the current SVN repo here: http://llvm.org/svn/llvm-project/ and migrate this to a single repository. I was not sure if you were referring to this proposal (monorepo) or to the recent emails about

> On Jul 28, 2016, at 6:23 PM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Aaaand I'm (mostly) caught up. Phew. > > FWIW Chris B is right: I had been put off commenting on this thread by the length, and the number of git discussions that have come before this. He convinced me to make the effort to put my 2 cents in though - thanks Chris. > > So

Attached is the log. I'm building with: clang version 10.0.0 (https://github.com/llvm/llvm-project/ 3a6da1122b990386edeba0987d0d1fdc9c8dc53d) Target: x86_64-unknown-linux-gnu Thread model: posix On some Ubuntu-like distribution. I also ran with ASAN once and it found a bunch of leaks in bin/tco. Best, -- Mehdi On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at

> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi, > > Thanks a lot Duncan, I really like this! I totally support adopting this scheme now. See inline a few quite minor comments. > > Renato: are you still interested and available now to set-up the survey? We should close on this *this week*. > > >> On Oct 12, 2016, at 7:07

Hi Mehdi, I can't replicate those failures at my end, could you let me know what OS, compiler and CMake flags you're using so I can try and reproduce? Thanks! David Truby ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> Sent: 07 April 2020 06:44 To: Richard Barton

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

Hi, (bcc: mlir at tensorflow.org FYI) I am following-up on the integration of MLIR in LLVM as a subproject (Re: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135687.html ). We're aiming to integrate into the monorepo next month. Right now our intent is for MLIR to live in a top-level directory in parallel to clang, lldb, lld, etc. Our top option for the integration is to perform a

<div> </div><div>Yes, broad. But what guys say: "You LLVM developers are all racists, because you use 'master' word"</div><div>Or broader: "You  all developers are all racists, because you use 'master' word". We are not racists, but other guys think so.</div><div>So let's begin consistent and take into account all

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >

> On Jul 26, 2016, at 9:46 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 26 July 2016 at 09:36, Mehdi Amini via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It is possible to continue adding the equivalent of git-svn-id in the commit message if it is what you’re referring to. > > Wouldn't that rely on people installing the correct

> On Jul 21, 2016, at 2:29 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Jul 21, 2016, at 11:03 AM, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> FWIW, like David Chisnall, we (Azul) have a problem with rewriting >> history. >> Our LLVM fork has O(100) changes diverging from upstream >> (though our