similar to: LLVM Releases: Upstream vs. Downstream / Distros

> On May 11, 2016, at 9:16 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This is a long email :-) I've made some comments inline, but I'll > summarize my thoughts here: > > - I like to think that the major releases have been shipped on a > pretty reliable six-month schedule lately. So we have that going for > us :-) > > - It

FWIW, for our ARM Compiler product, we follow top-of-trunk, not the releases. Next to picking up new functionality quicker, it also allows us to detect regressions in LLVM against our in-house testing quickly, not 6 months later. We find that when we find a regression within 24 to 48 hours of the commit introducing it, it's much cheaper to get it fixed. In my opinion, it would be better

On 11 May 2016 at 17:16, Hans Wennborg <hans at chromium.org> wrote: > This is a long email :-) I've made some comments inline, but I'll > summarize my thoughts here: Thanks Hans! I'll respond them inline, below. > - I think we should use the bug tracker to capture issues that affect > releases. It would be cool if a commit hook could update bugzilla > entries

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 (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel (LTS or distro tree). I

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 (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel (LTS or distro tree). I

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

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

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

>> 3. For many (most?) developers, changing to a monolithic git repo is a >> *bigger* workflow change than switching to separate git repos. Many >> people (and at least some downstream infrastructure) use the git >> mirrors exclusively, aside from git-svn for committing. >> >> I believe the idea is to continue to maintain the read-only independent >> git

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

Hi Hans, Since you are actively doing this kind of things, your feedbacks is particularly valuable. Thanks! > On May 2, 2016, at 3:45 PM, Hans Wennborg <hans at chromium.org> wrote: > > On Mon, May 2, 2016 at 1:35 PM, Quentin Colombet via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I am sending this proposal to get feedbacks on how we could make the tagging

On Wed, Apr 3, 2013 at 5:44 PM, Tom Stellard <tom at stellard.net> wrote: > 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

On Tue, 2015-09-08 at 03:47 -0600, Jan Beulich wrote: > > > > On 08.09.15 at 11:24, <ian.campbell at citrix.com> wrote: > > Release cycle > > ============= > > > > Waldi commented that the stable release cycle was too long. Would like > > to see a release after any large security update. > > > > We asked if the RCs for stable releases

Xen upstream BoF ================ We had a discussion around Xen and packaging at Debian's annual developer conference (Debconf) a few weeks back: https://summit.debconf.org/debconf15/meeting/279/xen-upstream-bof/ These are my notes, I think there is probably stuff of interest to most distro people, not just Debian folks. The session was scheduled in a small, out of the way, room. Around 2

Hi, I am sending this proposal to get feedbacks on how we could make the tagging of bug fixes and regressions more obvious. The idea is to provide easily accessible information to help deciding what to cherry-pick in a release branch. * Context * People shipping compilers based on LLVM may not completely align with the official releases of LLVM. Thus, the stabilization of each custom release

Hi, I would like to propose a few changes to the LLVM release process. The current process is documented here: https://llvm.org/docs/HowToReleaseLLVM.html There are two parts to this proposal. The first is a list of clarifications, which are things we are currently doing that aren't documented. The second is a list of changes which would actually modify how releases are currently managed.

On May 2, 2016, at 5:45 PM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> People shipping compilers based on LLVM may not completely align with the official releases of LLVM. Thus, the stabilization of each custom release may happen at different period of time. Because of that, release managers have to come up with their own strategy to decide which commits should

Hi all, I mentioned this idea yesterday on IRC already and would like to discuss in the greater context of the mailing list. NetBSD is about to import LLVM and Clang into its repository; FreeBSD already has done that a while ago. This creates some interesting maintainance questions. FreeBSD has followed the LLVM/Clang releases and backported various fixes locally. NetBSD will after the 3.4 release

I attach a patch for phoenixcontact_modbus.c This patch does the following: * Marks driver as DRV_BETA * Fixes stale data detection when cable is disconnected I can open a pull request if needed. Kind Regards, -Spiros p.s. please consider a faster tag/release schedule as currently linux repositories include old versions. Sure we can make packages ourselves, but it's better to have support