similar to: RFC: Release process changes

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/ - Release notes and documentation With RC2 the 3.2 release has reached the point where it is feature complete and we can turn the attention to updating documentation, especially the release

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*

I have been having discussions with various members of the development community in regards to changes to the way we manage open source Asterisk releases. The changes that we eventually decide on will determine how we manage the 1.6 version of Asterisk. I will be posting much more detailed information about 1.6 in the near future. What I'm looking for right now is some opinions on version

Dear testers, 7.0.0-rc3 was just tagged (from branch revision r341805). No further release candidates are currently planned, so this is a release candidate in the real sense: unless any serious issues surface, this is what the final release will look like. Please run the test script, share your results and upload binaries. Please also take a look at the release notes and other docs; small

Hi all, I'm working up some changes in the way LLVM is released. Attached is the latest HTML file for HowToReleaseLLVM.html. The major change is in how we do branching and tagging. I want to use a hierarchical version of tags for the various release candidates and final release. The structure of the tags would be something like this. The 2.9 release branch:

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

On Nov 16, 2012, at 3:52 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > >>> 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

Hi, It's about time to start thinking about the 3.8.1 release. Here is a proposed release schedule: May 25 - Deadline to request a change be merged to the 3.8 branch. June 1 - Deadline to merge changes to the 3.8 branch. June 1 - 3.8.1-rc1 June 8 - 3.8.1-rc2 (if necessary) June 15 - 3.8.1 Release If you want a patch included in the 3.8.1 release, send an email to llvm-commits with the

I'm wondering why the lit tests didn't catch this as part of testing rc1 on ARM. On Thu, Jan 26, 2017 at 11:25 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > XRay is tested automatically on build-bots with tests in LLVM and > compiler-rt . Or are you asking for manual testing instructions? > Of these 2 patches, the compiler-rt patch depends on LLVM patch because

The Asterisk Development Team is pleased to announce the the second release candidate of 1.6.0.11, the release of 1.6.1.2, the first release candidate of 1.6.1.3, and the fourth beta of 1.6.2.0. These releases are available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/ . The release of 1.6.1.2 fixes a remote crash security vulnerability in the RTP stack. The

Aiming at a release later in October (before Xen Summit I would hope), I''d like to cut RC1 next week. Please indicate any bug fixes that so far may have been missed in the backports already done. Jan

> 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? > I would like to propose addition of the > "folder/file (F)" field. The format > would be the same as used by Joe,Owen > and Justin This won't

How is XRay tested? IIRC, Renato didn't see any test failures on ARM? Merging sounds reasonbaly, I'd just like to understand what's the risk for the branch. On Thu, Jan 26, 2017 at 10:29 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > Hans, these changes reached trunk in https://reviews.llvm.org/rL292516 and > https://reviews.llvm.org/rL292517 . Could you look?

Will the PR's marked as blockers of PR36649 be merged in or do we need to do something specific? On Thu, Apr 26, 2018 at 12:28 AM, Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I've just tagged the 6.0.1-rc1 release. Testers may begin testing and > uploading > binaries. Also, any tester who has not tested 5.0.2-rc1 and would like to >

Hi, I would like to start a discussion about improvements to the stable release process, but first, here is a proposed schedule for the 4.0.1 release. May 1, 2017 -rc1 May 22, 2017 Deadline for submitting merge request May 29, 2017 Deadline for merging changes. June 3, 2017 -rc2 June 10, 2017 Final Release This is slightly different from previous stable releases in that we are doing an early

Hi all, The 3.7 release branch was created from trunk at r242221 today (around 10:40 pm UTC). Branch policy: - Any doc changes can go in. Updates to the release notes are highly encouraged, and should be committed directly to the branch. - All other patches should be approved by the release manager (me) and the appropriate code owner. To get a change merged, commit it to trunk, and then reply

Hello, Recent code owner activities have led to what I would call loss of referential integrity in the CODE_OWNERS.TXT file. Changes are fine but the information in the CODE_OWNERS.TXT does not allow to positively identify code owner of the particular file or patch. The problem stems from the usage of the "description (D)" field which is overloaded with meaning. Most people put

Hi, The number of stable patches has slowed down in the last few weeks, and we are approaching the halfway point between 3.3 and 3.4, so I think now is a good time to start planning for the 3.3.1 release. Here is the tentative schedule: September 3: 3.3.1-rc1 - This won't actually be a 'real' Release Candidate. The purpose of rc1 will be to update and test the release scripts

Dear testers, 7.0.0-rc2 was just tagged (from branch revision r340437). There have been a bunch of merges since rc1, and hopefully many of the issues with the previous candidate are fixed in this one. Please run the test script, share the results, and upload binaries. I will publish source tarballs, docs, and binaries on the web page once they're ready. Thanks, Hans

Hi, I was wondering what the policy is for applying fixes to released branches. In particular I have fix that would be useful to have in LLVM 3.5. I recently found and fixed a bug [1] in the way CMake files are generated by the Autoconf/Makefile system and fixed this in r217484. I figured it would be more sensible to ask about this in a thread separate from [2] because this is a much more