similar to: [LLVMdev] 1 Week before 1.9 Branch Creation

> It is now 1 week before I will create the 1.9 release branch. When will the front end stablize relative to this? It would help in tracking down failures if the front end was frozen a bit before everything else. Andrew

Hi, Tanya! >* November 6, 2006: Code freeze and release branch created. Documentation > revisions. Does it mean that I can commit my changes to LLVM until November 6? Thanks. Tony. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061030/1e4ae18f/attachment.html>

LLVM Developers, It is now 1 week before I will create the 2.0 release branch. I'm asking that all platform maintainers and available llvm developers review the nightly tester results. Please XFAIL any dejagnu tests that are currently failing, fix any warnings, and review the results of the full llvm test suite. If a test failure is determined to be something that needs to be fixed before

Tanya M. Lattner wrote: > I'm asking that all platform maintainers and available llvm developers > review the nightly tester results. Please XFAIL any dejagnu tests that are > currently failing, fix any warnings, and review the results of the full > llvm test suite. If a test failure is determined to be something that > needs to be fixed before the release, please fix it or

I will be creating the branch at 9PM PST. Please refrain from checking in any large changes until after the branch creation. I'm still seeing unexpected dejagnu failures for PPC and X86. Platform maintainers, please XFAIL these and file bugzilla bugs. Email me if you have concerns or questions. -Tanya

LLVMers, Sorry for the delay in this email. The 1.8 release has been pushed out 1 week, so today marks 1 week before I create the 1.8 branch. I'm asking that all platform maintainers and available llvm developers review the nightly tester results. Please XFAIL any dejagnu tests that are currently failing, fix any warnings, and review the results of the full llvm test suite. If a test

Aaron Gray wrote: > It would be good to have a mailing list for test results where 'make check' > results could be posted so that there is some reference and people could > avoid repeating builds. There's the llvm-testresults list, but I find it less than fully useful because it's not immediately obvious from scanning message subjects if there's been a test

> I very much want to get my regalloc refactoring changes in but I don't > have a consistent platform to test them on. Someone broke llvm-gcc > bootstrapping late last week or this week. How large of a change have you made? With 3 days before the branch creation, I strongly advise people not to be checking in major changes. > Can we please freeze features for a while and get

> Tanya M. Lattner wrote: > >> How large of a change have you made? With 3 days before the branch >> creation, I strongly advise people not to be checking in major changes. > > Depends how you look at it. Structurally, it separates two files into > four and moves some functionality from one class to a new class, so in a > sense that's a big change.

Tanya M. Lattner wrote: > How large of a change have you made? With 3 days before the branch > creation, I strongly advise people not to be checking in major changes. Depends how you look at it. Structurally, it separates two files into four and moves some functionality from one class to a new class, so in a sense that's a big change. Code-logic-wise, it does nothing at all. I will

I'd like to tag and create the branch for llvm and llvm-test soon. Does anyone still have tests to XFAIL, warnings to fix, or other critical bug fixes? Please respond to this mail and let me know ASAP if you are done or need more time. -Tanya

Just a reminder, I'll be re-creating the 2.5 branch tonight at 9pm PST. -Tanya

This is just a friendly reminder that the 1.8 release is coming up. Here are the important dates: * July 12, 2006: Email sent out asking platform maintainers to XFAIL tests, check for regression/file bugs, and check in any final stuff for the release. * July 19, 2006: Code freeze and release branch created. Documentation review. * July 26, 2006: Pre-release online for testing * August 2, 2006:

I've finished adding the -rundejagnu option to the nightly tester script, which was the last step to fully support Dejagnu. I think now is the appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot of work went into using QMTest, so I think we should make this decision carefully and before the 1.4 release. Here are the pros and cons in my eyes, please feel free to add your

> On Monday 02 February 2009 13:20, Tanya M. Lattner wrote: >> Just a reminder, I'll be re-creating the 2.5 branch tonight at 9pm PST. > > What does re-creating mean? Why can't the previously-created 2.5 branch > simply be updated? It means deleting the branch and creating a new one. > I ask because svn history will look a little wierd and it makes it harder for

On Monday 02 February 2009 13:20, Tanya M. Lattner wrote: > Just a reminder, I'll be re-creating the 2.5 branch tonight at 9pm PST. What does re-creating mean? Why can't the previously-created 2.5 branch simply be updated? I ask because svn history will look a little wierd and it makes it harder for third parties to track revisions and do merges.

Tanya Lattner wrote: > >> 1. I'm still looking for volunteers to test MacOS X and Solaris. >> If you'd like to volunteer, please email the list to let us know. > > > I'll do minimal testing on Sparc. I'm not going to look into any > regressions though since no one has been really watching Sparc since I > graduated and I am sure there are

On Sunday 28 November 2004 00:24, Tanya Lattner wrote: Just some comments from a QMTest user... Note however, that even with them, dejagnu looks better. > Cons of QMTest: > 1) You have to use the gui to add directories. I think you're wrong. Manually creating a directory would work, as QMTest does not place anything special in directories. > 2) You have to use the gui to XFAIL

Tanya Lattner wrote: > I've finished adding the -rundejagnu option to the nightly tester script, > which was the last step to fully support Dejagnu. I think now is the > appropriate time to discuss keeping QMTest or switching to Dejagnu. A lot > of work went into using QMTest, so I think we should make this decision > carefully and before the 1.4 release. > > Here are the

The various intrinsic assert/crashes should all be fixed on mainline CVS (they are PR733, which I just fixed). The only ones that I'm wary of are: XPASS: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-20- StaticRedeclare.c.tr FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2005-12-04- DeclarationLineNumbers.c: In the former case, I would guess that the test isn't