similar to: RFC: Release qualification criteria

The usual procedure is to make time-based releases. So - "release trunk and make sure it's stable enough" plus - fix any outstanding regressions. There is some text wrt this: http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: > On 12/13/13 01:58 PM, Bill

Hi, I would like to propose a few changes to the LLVM release process. The current process is documented here: https://llvm.org/docs/HowToReleaseLLVM.html There are two parts to this proposal. The first is a list of clarifications, which are things we are currently doing that aren't documented. The second is a list of changes which would actually modify how releases are currently managed.

According to the schedule (e.g. on the right on llvm.org), we should have tagged the release by now, but we haven't, so we're officially behind schedule. I'm still optimistic that we can wrap this up pretty soon, though. This is what's blocking us: - PR26509: Crash in InnerLoopVectorizer::vectorizeLoop() I'm waiting to hear what Cong comes up with, otherwise we can revert

On Tue, Apr 02, 2013 at 05:47:33PM -0700, Bill Wendling wrote: > On Apr 2, 2013, at 2:10 PM, Tom Stellard <tom at stellard.net> wrote: > > > On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote: > >> On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > >> > >> As Chris said, the only thing preventing this is manpower.

----- Original Message ----- > From: "Anton Korobeynikov" <anton at korobeynikov.info> > To: "C. Bergström" <cbergstrom at pathscale.com> > Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, "Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, December 13, 2013 3:24:38 AM > Subject: Re: [LLVMdev]

i Don't know if others have raised this issue, but I'm seeing *a lot* of llvm-dev emails and cfe emails landing in my spam folder in gmail. Are other people having this problem? On Mon, May 12, 2014 at 11:57 AM, Tom Stellard <tom at stellard.net> wrote: > Hi, > > I would like to begin the 3.4.2 release process for LLVM. There have > been two issues identified in

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, I would like to begin the 3.4.2 release process for LLVM. There have been two issues identified in 3.4.1, which there is interest in having fixed in a 3.4.x release: 1. Build failure with gcc 4.9 (This is not a regression, 3.4 also fails to build with gcc 4.9). 2. Accidental change of libLLVM's DT_SONAME from libLLVM-3.4 libLLVM-3.4.1.so I will also accept any other bug-fixes that

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

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, I've tagged 10.0.1-final. Testers, please begin uploading your binaries. Thanks, Tom

On 06/05/2018 10:47 AM, Dimitry Andric wrote: > On 4 Jun 2018, at 18:01, Tom Stellard via Release-testers <release-testers at lists.llvm.org> wrote: >> >> The 6.0.1-rc2 release has been tagged. Testers may begin testing and >> reporting results. > > Built for FreeBSD 10, tested and uploaded: > > SHA256 (clang+llvm-6.0.1-rc2-amd64-unknown-freebsd10.tar.xz)

On Apr 3, 2013, at 11:30 AM, Tom Stellard <tom at stellard.net> wrote: > On Tue, Apr 02, 2013 at 05:47:33PM -0700, Bill Wendling wrote: >> On Apr 2, 2013, at 2:10 PM, Tom Stellard <tom at stellard.net> wrote: >> >>> On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote: >>>> On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at

Hi, A few months ago, I mentioned I was interested in helping to make dot releases for LLVM 3.3. Now that 3.3 has been released, I would like to kick off the process of collecting bug fixes and merging them into the 3.3 branch. I reviewed the previous discussion about dot releases: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/060821.html and I've come up with the following dot

Hi, I've tagged the 10.0.1-rc2 release, please test the release and report any issues. Thanks, Tom

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

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

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.

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