similar to: Mailing list changes this week

On 10/15/2019 09:24 PM, Mehdi AMINI wrote: > Hi Tom. > > One issue with this is that we don't have a clear "ordering" from linear revision numbers from these emails. Have we looked into continuing to generate our own emails per commits instead so that we control the format? > This actually what we are doing, we are listening for github commit events and then generating

On 10/15/2019 09:44 PM, Mehdi AMINI wrote: > > > On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard <tstellar at redhat.com <mailto:tstellar at redhat.com>> wrote: > > On 10/15/2019 09:24 PM, Mehdi AMINI wrote: > > Hi Tom. > > > > One issue with this is that we don't have a clear "ordering" from linear revision numbers from

On 10/16/2019 07:31 AM, Roman Lebedev wrote: > +1, please. > > Also, putting a tag on the *first* commit in the repo, > and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! > Do we need to add a tag or is `git rev-list --count HEAD` good enough? -Tom > Roman. > > On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev > <llvm-dev at

+1. And put it in the email (subject?). While it’s possible to derive a count from a hash manually, better to have it in the email in the first place. You can’t rely on order-of-email-delivery to reflect order-of-commit. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Shoaib Meenai via llvm-dev Sent: Wednesday, October 16, 2019 1:42 AM To: tstellar at redhat.com;

On 10/16/2019 12:02 PM, Roman Lebedev wrote: > On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard <tstellar at redhat.com> wrote: >> >> On 10/16/2019 07:31 AM, Roman Lebedev wrote: >>> +1, please. >>> >>> Also, putting a tag on the *first* commit in the repo, >>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! >>>

Hi, We're less than 2 weeks away from the developer meeting, so I wanted to give an update on the GitHub migration and what's (hopefully) going to happen during the developer meeting. Everyone who has added their information to the github-usernames.txt file in SVN before today should have received an invite to become a collaborator on the llvm-project repository. If you did not receive

On 10/10/2019 11:40 AM, Mehdi AMINI wrote: > > > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard <tstellar at redhat.com <mailto:tstellar at redhat.com>> wrote: > > On 10/09/2019 11:05 PM, Mehdi AMINI wrote: > > > > > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at

On 10/09/2019 11:05 PM, Mehdi AMINI wrote: > > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > Hi, > > We're less than 2 weeks away from the developer meeting, so I wanted to > give an update on the GitHub migration and what's (hopefully) going to >

On Thu, Oct 10, 2019 at 1:14 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > > On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On 10/10/2019 11:40 AM, Mehdi AMINI wrote: >> > >> > >> > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard <tstellar at redhat.com >>

On Tue, 2019-10-22 at 09:57 -0700, Tom Stellard via cfe-dev wrote: > On 10/22/2019 09:08 AM, Tom Stellard via Openmp-dev wrote: > > Hi, > > > > We're getting ready to start migrating to GitHub. SVN will be > > moved to read-only now and we'll > > begin the process of turning on GitHub commit access. I'll send an > > email when we're done.

Hi, We're getting ready to start migrating to GitHub. SVN will be moved to read-only now and we'll begin the process of turning on GitHub commit access. I'll send an email when we're done. -Tom

Hi, There was one problem in -rc1, so we had to do another release candidate. -rc2 has now been tagged and is ready for testing. -Tom

Hi, I have just tagged the 10.0.1-rc1 release. Testers can begin testing and uploading binaries. If you still want to get a fix into the 10.0.1 release, you still have about a month to get your fix in. To request a patch be backported to the release/10.x branch, file a bug and mark it as a blocker of the release-10.0.1 meta bug. -Tom

> 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 obligation. Given that I think it is an independent issue and would suggest we just

On 07/27/2017 05:17 PM, Tom Stellard via cfe-dev wrote: > On 07/26/2017 06:41 PM, Hans Wennborg via Release-testers wrote: >> Dear testers, >> >> 5.0.0-rc1 has just been tagged. >> > > Hi Hans, > > I see 1 regression one ppc64le: > > libomp :: tasking/omp_taskloop_grainsize.c > This isn't actually a regression, it's just a new test.

One is expected to use `git llvm push`. For more information, please see: https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git > On Sep 3, 2019, at 7:06 PM, David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > What is the expected way to do commits? Do we push directly to master > after a rebase? I know there has been talk of using

On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I say retire it instantly. > +1. It has never been a real requirement to use the script. Using native svn is still viable until the point of the migration. > > > On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > >

Hi, I've created a text file[1] in the SVN repository that developers can update in order to request commit access to the GitHub repository. All you need to do is add a line in the form of $SVN_USERNAME:$GITHUB_USERNAME Please add your information to this file before SVN becomes readonly on October 21 to avoid a gap in commit access. More details can be found in the phabriactor review[2]

On 13 June 2016 at 10:11, Tom Stellard <tom at stellard.net> 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 features that we really want to drop. There should

Hi, I would like to follow up on the previous thread[1], where there was a consensus to disallow merge commits in the llvm github repository, and start a discussion about how we should enforce this policy. Unfortunately, GitHub does not provide a convenient way to fully enforce this policy. We can enforce it for pull requests, but not for direct pushes to the master branch, so we will have to