Re: [Buildroot] [PATCH 3/3] configs: update defconfigs with custom versions to BR2_LINUX_KERNEL_LATEST_X_Y

From: Baruch Siach via buildroot <buildroot@buildroot.org>
To: Arnout Vandecappelle <arnout@rnout.be>
Cc: Titouan Christophe <titouan.christophe@mind.be>,
	 Titouan Christophe via buildroot <buildroot@buildroot.org>,
	 ju.o@free.fr, thomas.petazzoni@bootlin.com,  git@jdknight.me,
	 thomas.perale@mind.be
Subject: Re: [Buildroot] [PATCH 3/3] configs: update defconfigs with custom versions to BR2_LINUX_KERNEL_LATEST_X_Y
Date: Tue, 13 Oct 2026 08:58:28 +0300	[thread overview]
Message-ID: <8733ua2lbv.fsf@tarshish> (raw)
In-Reply-To: <505a5107-4e45-4b46-92c0-e4cd10025e9a@rnout.be> (Arnout Vandecappelle's message of "Mon, 12 Oct 2026 12:40:12 +0200")

Hi Arnout,

On Mon, Oct 12 2026, Arnout Vandecappelle wrote:
> On 12/10/2026 10:35, Titouan Christophe via buildroot wrote:
>>>> This is a tradeoff, really.
>>>> On one hand (A), there is the risk of breaking the functionality of a board by
>>>> bumping from one patch version to another.
>>>> On the other (B), any new Linux patch version brings a handful of security
>>>> fixes, and this happens on a weekly basis.
>>> The basic question is what are these deconfigs meant to achieve? My
>>> understanding is that defconfigs demonstrate hardware working with a Buildroot
>>> generated image. For many users this is the first Buildroot step. Hardware
>>> bring-up is non trivial, and defconfigs preserve a known working state for a
>>> given target system. defconfig is only an enabler for new users.
>> Indeed, this discussion should address the intended role of in-tree
>> defconfigs.
>> My personal opinion on this role:
>> - They provide (as you say) a first entry into Buildroot for many users.
>> - However, I believe they should build a somewhat up-to-date system, and
>> demonstrate ways for users to keep their boards up to date.
>
>  Another way to achieve that is to add a HOWTO to the docs that explains how
>  to use a defconfig. Something like:
>
> 1. Find the right defconfig.
> 2. make foo_defconfig; make; deploy
> 3. It boots? Joy! Now prepare for modification.
>    make BR2_DEFCONFIG=<my own defconfig> savedefconfig
> 4. Switch from the custom kernel to the corresponding LTS branch and test.
> 5. Switch to the latest kernel and test.
> 6. If it works, fixate that and contribute the change.

For the record, I like this direction. Especially if steps
(4) and (5) become as easy as possible for new users.

Thanks,
baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot