similar to: [LLVMdev] Need 2.7 release team volunteers

Bah, headers still broken, sending to list this time: On Sat, Mar 13, 2010 at 6:30 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Sat, Mar 13, 2010 at 11:10 AM, Tanya Lattner <lattner at apple.com> wrote: >> >> On Mar 13, 2010, at 7:01 AM, R P Herrold wrote: >> >>> On Sat, 13 Mar 2010, Tanya Lattner wrote: >>> >>>>> I

LLVMers, As LLVM grows and begins to support more targets and more frontends, its becoming a very large task to qualify a release. Therefore, I'm seeking a couple of active members of the community to volunteer to be a part of the LLVM release team (for 2.6+). This does not replace general user testing during the release process. Members of this LLVM Release Team will need to be very

On Oct 6, 2011, at 2:35 PM, Joerg Sonnenberger wrote: > On Fri, Sep 30, 2011 at 04:45:33PM -0700, Bill Wendling wrote: >> As of today, there are two weeks left until we branch for the 3.0 >> release. Please get your changes in as soon as possible so that they >> are well-tested before the branch. And please keep on top of any failures you see. >> >> Now would be

Hello, Tanya > 4) Mingw x86 (Anton do you want to continue this?) Yes, I'm still going to prepare llvm-gcc mingw32 images. However, the testing procedure for mingw is slightly different due to lack of dejagnu stuff. However, I have plans to fix the main LLVM testsuite to be more mingw32-friendly :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint

The 2.7 pre-release testing ends tomorrow March 24th (11:59PM PDT). I've updated the 2.7 release schedule to include a one week regression fixing week. This is only for regressions found in 2.7 and not for miscellaneous bug fixes. I will no longer be merging in patches that are not a regression as defined in our release process (http://llvm.org/docs/HowToReleaseLLVM.html#release-qualify).

I noticed that the mingw release only contains binaries and not libraries nor header files. I think it would be nice if the mingw release contained the same files as the other releases. This would mean that people who want to use LLVM with the Haskell bindings on Windows don't have to build and install LLVM (first installing mingw), but they could just download binaries and install those.

The 2.7 pre-release2 is available for testing: http://llvm.org/pre-releases/2.7/pre-release2/ Please complete all testing by April 23rd EOD. We are shortening this testing period a bit to get the release out soon since its been delayed so far. The release team has done our qualifications and we think its of high quality and ready to go. As this is the last pre-release, we only accept fixes for

Hi LLVM Friends, Fans, Followers and Fanatics, LLVM 2.7 is live! You can download it here: http://llvm.org/releases/ and read about it here: http://llvm.org/releases/2.7/docs/ReleaseNotes.html This release includes approximately 6 months of development that provide major enhancements and new features over the LLVM 2.6 release. This includes significantly better generated code, improvements to

Ok, I have good news! Thanks for the help! On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Many of you are probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and > the list of regressions very high. The list has finally dwindled > down to the following regressions: > > Linux/x86: >

On Tuesday, I began my pre-release2 testing. We will no longer be accepting any patches for 2.6 unless they meet the criteria of a regression: http://llvm.org/docs/HowToReleaseLLVM.html#release-qualify I've already filed a few regressions. Please see the master 2.6 bug: http://llvm.org/PR4886 Assuming the best, the 2.6 release schedule is as follows (shifted 2 weeks): Sept 25 -

Hello all! The 2.6 release is currently blocked by a number of bugs that need to be fixed. Please see the master 2.6 bug (see depends on field): http://llvm.org/bugs/show_bug.cgi?id=4886 If anyone can volunteer to help out, please do so! The 2.6 release will not progress until these bugs are fixed. We hope this is the last of them! Thanks, Tanya -------------- next part -------------- An

On Tue, 30 Mar 2010 14:09:03 -0700, Tanya Lattner <xzss at ____.com> wrote: > All, > > There has been a huge lack of response to the release. We need people to > help fix regressions and to participate in testing the release. Without > this support, I see no reason that the release team should spend their time > qualifying a release. > > We need to get all

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Many of you are probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and the > list of regressions very high. The list has finally dwindled down to > the following regressions: > ... > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] For my

On Oct 27, 2011, at 5:37 PM, Michael Price wrote: > Has there been much thought of attempting to automate this process? I could imagine a fairly standard script that scrubbed a history for interesting tidbits. Of course a standard methodology for labeling types of commits would help this in the future. > > A very simple script could at least do unique word counts and throw out words

Tanya Lattner wrote: > Many of you are probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and the > list of regressions very high. The list has finally dwindled down to > the following regressions: > > Linux/x86: > SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT] Increasing ulimit to 230 Mb (from

Tanya Lattner wrote: > So, I need to rerun all the tests and package things up. Chris is > working on the release notes. Hopefully we can have this out by the end > of the week. Did you apply my patch to get 2.3 to build in Visual Studio 'out of the box'? ... I never saw any more replies and I'm not subscribed to llvm-commits, so I don't know if it went in. m.

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)

All, There has been a huge lack of response to the release. We need people to help fix regressions and to participate in testing the release. Without this support, I see no reason that the release team should spend their time qualifying a release. We need to get all regressions fixed before 2.7 can continue onto pre-release2. Please take a look at all release blockers:

Has there been much thought of attempting to automate this process? I could imagine a fairly standard script that scrubbed a history for interesting tidbits. Of course a standard methodology for labeling types of commits would help this in the future. A very simple script could at least do unique word counts and throw out words that match a dictionary (like parts of speech, contributer names,

We need some volunteers to help with the 3.0 release notes. Traditionally, Chris has been the one to go through all the commits (6 months worth!) and come up with a concrete list of things that have changed in 3.0. Ideally, its much better if this document is incrementally updated as well, but we know how that goes. This is a huge amount of work and with the pace that LLVM/Clang are being