similar to: [LLVMdev] !!! 3.2 Release - Release Notes, Documentation, External Projects and the RC3

Approved. Sorry for the delay. On Mon, Dec 3, 2012 at 8:27 PM, 32bitmicro <root at 32bitmicro.com> wrote: > > > 32bitmicro <root at 32bitmicro.com> writes: > >> - Release Candidate 3 (RC3) > >> > >> RC3 will be created on Wednesday Dec 5th 10 p.m. PST. Please let me > >> know if there are any patches for release stopping issues that

> 32bitmicro <root at 32bitmicro.com> writes: >> - Release Candidate 3 (RC3) >> >> RC3 will be created on Wednesday Dec 5th 10 p.m. PST. Please let me >> know if there are any patches for release stopping issues that should >> be included in the RC3. > > Is the fix for 14465 important enough for the 3.2 release? It's an ICE > that I hit in RC1

32bitmicro <root at 32bitmicro.com> writes: > - Release Candidate 3 (RC3) > > RC3 will be created on Wednesday Dec 5th 10 p.m. PST. Please let me > know if there are any patches for release stopping issues that should > be included in the RC3. Is the fix for 14465 important enough for the 3.2 release? It's an ICE that I hit in RC1 that's still there in RC2. Benjamin

Hi, > Are we going to have a mingw release this time? As far as I know there is no change from 3.1 and Mignw is considered experimental. Incidentally RC2 mingw32 binaries have been uploaded and are available for download and testing. http://llvm.org/pre-releases/3.2/rc2/clang+llvm-3.2rc2-i386-mingw32-EXPERIMENTAL.tar.gz Pawel > > > On Mon, Dec 3, 2012 at 2:54 PM, 32bitmicro

On 12/4/2012 10:14 AM, Justin Holewinski wrote: > What is the procedure for updating the release notes? I've been committing > changes to the trunk version, should I be editing them elsewhere? Or will > the trunk version be merged in? The exact procedure is not spelled out but I think the easiest would be to merge relevant "ReleaseNotes.html" changes from the trunk,

Are we going to have a mingw release this time? On Mon, Dec 3, 2012 at 2:54 PM, 32bitmicro <root at 32bitmicro.com> wrote: > Hello, > > - State of the 3.2 release > > Release is progressing as scheduled, RC2 has > been created and is being tested. RC2 sources > and binaries can be downloaded from: > > http://llvm.org/pre-releases/3.2/rc2/ > > > -

What is the procedure for updating the release notes? I've been committing changes to the trunk version, should I be editing them elsewhere? Or will the trunk version be merged in? On Mon, Dec 3, 2012 at 4:12 PM, 32bitmicro <root at 32bitmicro.com> wrote: > Hi, > > > Are we going to have a mingw release this time? > > As far as I know there is no change from 3.1

Alright, can you please pull in r169280? On Tue, Dec 4, 2012 at 12:56 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > On 12/4/2012 10:14 AM, Justin Holewinski wrote: > > What is the procedure for updating the release notes? I've been > committing > > changes to the trunk version, should I be editing them elsewhere? Or > will > > the trunk version be

Pawel, We all understand that you're pretty new to release process, etc., but I think you should understand the implications of your actions. You just created a lot of harm for really huge pile of users - the ones who downloads the tarball via some automated build system and rely on the known good checksum. This includes, but not limited to to the users of FreeBSD, Gentoo, etc. Even worse,

On Fri, Jan 11, 2013 at 3:47 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > On 1/11/2013 2:40 PM, Brooks Davis wrote: > > On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer wrote: > >> > >> On 11.01.2013, at 21:31, Justin Holewinski > >> <justin.holewinski at gmail.com> wrote: > >> > >>> On Fri, Jan 11, 2013 at 3:26

On 1/11/2013 2:51 PM, Justin Holewinski wrote: > On Fri, Jan 11, 2013 at 3:47 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > >> On 1/11/2013 2:40 PM, Brooks Davis wrote: >>> On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer wrote: >>>> >>>> On 11.01.2013, at 21:31, Justin Holewinski >>>> <justin.holewinski at

Anton, > Pawel, > > We all understand that you're pretty new to release process, etc., but > I think you should understand the implications of your actions. > > You just created a lot of harm for really huge pile of users - the > ones who downloads the tarball via some automated build system and > rely on the known good checksum. This includes, but not limited to to

Akira, > Pawel, > > Is it still not too late to merge these patches? > > r168471 > r168460 > r168458 > r168456 > r168455 > r168453 > r168450 > r168448 > > These patches fix a bug in mips backend's GOT implementation and add > support for big-GOT relocations. That's quite a list of patches! To get them into the 3.2 release you would first

Hello, Release Candidate 3 has been branched. RC3 source code can be downloaded as tarballs from: http://llvm.org/pre-releases/3.2/rc3/ or directly from svn. Binaries will be posted shortly. Testing RC3 has a number of fixes related to MIPS support that need to be well exercised. Otherwise, I think we are at the point of the release where I can *challenge* testers to try to break it!

Hello, Just a quick reminder that the November 29th (10p.m. PST) is the end of Phase 1 testing and Release Candidate 2 (RC2) deadline. After RC2 deadline, LLVM-Clang 3.2 release will be considered feature complete and no new functionality can be added. With 2 days left please use following guidelines when initiating request for patches before RC2 deadline. I will be happy to merge *approved*

Pawel, Is it still not too late to merge these patches? r168471 r168460 r168458 r168456 r168455 r168453 r168450 r168448 These patches fix a bug in mips backend's GOT implementation and add support for big-GOT relocations. Thank you. On Tue, Nov 27, 2012 at 7:35 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > Hello, > > Just a quick reminder that the November 29th

Hi, I've just tagged LLVM 8.0.1-rc3. Testers, please begin testing and report results. -Tom

Hi, I've just tagged 7.0.1-rc3. This will hopefully be the last release candidate. Please test and report results. Thanks, Tom

>> This approach is fine for casual reader but >> does not work for scripting or any automated >> way of dealing with the build. > Will you please clarify how the automation / scripting helps with the > patch approval process? Generally release patch process works like this: - patch gets checked-in on the trunk - developer sends message to the code owner who approves

Dear testers, 8.0.0-rc3 was just tagged from the release_80 branch at r355015. We're running a little behind schedule now, but I think we're also close to be able to call this done. Please take a close look at this release candidate. Unless anything bad comes up, this is probably very similar to what the final release will look like. Testers, please run the test script, share your