similar to: [LLVMdev] RFC: Bug fix releases for 3.3 and beyond

On Tue, Apr 02, 2013 at 09:59:39AM -0700, Chris Lattner wrote: > On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > > 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.

On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > 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 >

Hi Tom, This is a great idea, we have ourselves back-ported fixes from trunk in LLVM 3.2 we are using. For stable release is it reasonable to count on a new BUG-fix release every two months for instance ? Seb > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Stellard > Sent: Tuesday, April 02, 2013 6:52 PM

On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > 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

For the record, I'm not opposed to this. I'm mostly playing devil's advocate. But I do feel that these are issues that need to be thought out before we continue. -bw On Apr 2, 2013, at 2:10 PM, Tom Stellard <tom at stellard.net> wrote: > On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote: >> On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at

On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote: > On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > > > 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

On 4/2/2013 11:51 AM, Tom Stellard wrote: > > 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. Does this really make sense with a 6 month release cycle for the main releases? Who are the customers who

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

Sean Silva <silvas at purdue.edu> writes: > The largest barrier that I see, which nobody seems to have mentioned, is > the community culture. [snip] Well, the plan I described assumed "zero collaboration from the developers" for exactly the reasons you mentioned. IMO it is possible to bring a "maintenance branch" which is preferable to the development branch for

On Tue, Apr 2, 2013 at 12:51 PM, Tom Stellard <tom at stellard.net> wrote: > 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

On Wed, Apr 03, 2013 at 05:12:42PM -0400, Sean Silva wrote: > On Wed, Apr 3, 2013 at 4:09 PM, Tom Stellard <tom at stellard.net> wrote: > > > > > > > How many customers out there are shipping their LLVM-based products > > > without actually including the LLVM sources? If they do include the > > > sources, they may fix the bug locally, especially if

Hello everyone, We are in the process of formalizing the governance model of the GlusterFS project. Historically, the governance of the project has been loosely structured. This is an invitation to all of you to participate in this discussion and provide your feedback and suggestions on how we should evolve a formal model. Feedback from this thread will be considered to the extent possible in

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, 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 01/15/2020 05:03 PM, Reid Kleckner via llvm-dev wrote: > Tom Stellard told me to use `git cherry-pick -x`, and if you look at the release branches, you can see it is used, although the old style is used as well. I'm not sure what script is being used there. > I recommend updating the merge.sh script to use `git cherry-pick -x` and then deleting the merge-git.sh script. -Tom >

On Tue, Apr 02, 2013 at 05:47:33PM -0700, Bill Wendling wrote: > On Apr 2, 2013, at 2:10 PM, Tom Stellard <tom at stellard.net> wrote: > > > On Tue, Apr 02, 2013 at 11:52:09AM -0700, Bill Wendling wrote: > >> On Apr 2, 2013, at 9:51 AM, Tom Stellard <tom at stellard.net> wrote: > >> > >> As Chris said, the only thing preventing this is manpower.

Excuse my ignorance (I'm not great with Git) but how would it differ for workflows of people who use a Git repository for local work but still use `svn up + patch + svn commit <list of files>` to actually land post CR or for NFC patches, while resolving conflicts during a pull into a local (non-trunk) branch manually, after the eventual full switch to GitHub? I'm aware that SVN

Hi, As part of the migration of LLVM's source code to github, we need to update our developer policy with instructions about how to interact with the new git repository. There are a lot of different topics we will need to discuss, but I would like to start by initiating a discussion about our merge commit policy. Should we: 1. Disallow merge commits and enforce a linear history by

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,

On 13/07/2023 16:09, Thomas Zimmermann wrote: > Hi > > Am 13.07.23 um 16:41 schrieb Sean Paul: >> On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig >> <u.kleine-koenig at pengutronix.de> wrote: >>> >>> hello Sean, >>> >>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: >>>> I'd really prefer this patch