similar to: Adding new fields to bugzilla

I'm a little vary of adding more fields, because I think we already have lots of fields that are never used. Having said that, your suggestions seem reasonable, and it would be cool if we could create tools to automate the release process a bit more based on this. On Mon, Jul 24, 2017 at 12:30 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Ping. > > On

On Wed, Jul 26, 2017 at 11:10 AM, Tom Stellard <tstellar at redhat.com> wrote: > On 07/26/2017 12:52 PM, Hans Wennborg wrote: >> I'm a little vary of adding more fields, because I think we already >> have lots of fields that are never used. >> > > I'm up for removing unused fields too. Which ones did you have in mind? I think URL, Keywords, Alias, and

On Tue, May 05, 2015 at 01:02:57PM +0100, Renato Golin wrote: > On 4 May 2015 at 21:55, Tom Stellard <tom at stellard.net> wrote: > > I am no longer accepting new patch nominations for the 3.6.1 branches. > > There are a handful of outstanding patches waiting for approval from > > code owners, I may still merge these if I get code owner approval before > > the

Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote: > Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at

Hi, I've been going through my queue of candidate patches for the 3.6 branch, and I think the process could be smoother if we had more code owners. So, I'd like to encourage people to nominate themselves or others as code owners for any part of LLVM that doesn't already have one. The responsibilities of a code owner include reviewing patches submitted to llvm-commits and approving

Hi, I would like to nominate Martin Storsjö as code owner for MinGW changes in LLVM. -Tom

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

Hi, I am no longer accepting new patch nominations for the 3.6.1 branches. There are a handful of outstanding patches waiting for approval from code owners, I may still merge these if I get code owner approval before the start of 'official' testing. We had originally planed to start 'official' testing today, however a regression was found in the 3.6 branch, so I would like to

On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote: > On 26 Nov 2014, at 16:50, Tom Stellard <tom at stellard.net> wrote: > > > > On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > ... > > I will try to look at the patches today. I'm going to delay the release a week > > or so, because of all the merge requests I've received,

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

On Thu, Apr 30, 2015 at 11:59:52AM +0100, Renato Golin wrote: > Tom, code owner nomination. > > Andrey is the most active developer, so I think it makes sense. How > long do we wait to change the file? Is there any process that you'd > like to follow? > I don't think there is a formal process, but usually the file gets updated once Chris approves. -Tom > cheers,

----- Original Message ----- > From: "Dimitry Andric" <dimitry at andric.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)" <llvmdev at cs.uiuc.edu>, "Tom Stellard" <tom at stellard.net> > Sent: Saturday, November 29, 2014 1:34:21 PM > Subject: Re: [LLVMdev]

Tom (and Andy, Owen, Evan, Nadav), I'd like the following commits placed into the 3.4.1 branch. I've attempted to sort this list by code owner: Andrew Trick: r203719 - PR17473 r203725 - This test need the X86 backend, move it to the X86 sub directory. [adjusts the test location from r203719] r202273 - Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use.

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

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an

Hi, Here is the schedule for the 3.6.2 release: June 15: Deadline to propose patches for the 3.6 branch June 15 - June 21: Grace period for reviewing proposed patches and resolving other issues. June 22: 3.6.2 -rc1 June 29: 3.6.2 release Also, I would like to try to try to experiment with using phabricator for proposing patches to the stable branch. This is not a

Hi, I would really like to see the LLVM project start to make official bug fix releases (e.g. 3.3.1, 3.3.2, etc.). I think that this would be useful for a lot of the users of LLVM, especially projects that use LLVM as a library. I am willing to help maintain bug fix releases, and I'm wondering if this is something that the LLVM project would officially support with a stable SVN branch and by

On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote: > On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote: > > Tom, > > > > now that 3.4.1 is out, any chance of a 3.4.2 with just the three > > fixes or at least merging them to the 3.4 branch? > > I've pushed the two approved patches to the 3.4 branch, can you > verify that they work with gcc

Hi, I would like to try again to do stable releases for LLVM 3.4. Even though we were unsuccessful with stable releases for LLVM 3.3, I learned some things going through the process, which I think will increase the chance for success with LLVM 3.4. So, here is my TODO list for a successful 3.4.1 release: 1. Get volunteers to help This is probably the most important thing on this list. Stable

On 15/05/2014 22:12, Tom Stellard wrote: > On Thu, May 15, 2014 at 01:38:32PM +0200, Tuncer Ayaz wrote: >> On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote: >> >>> On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote: >>>> Tom, >>>> >>>> now that 3.4.1 is out, any chance of a 3.4.2 with just the three >>>> fixes