Re: Isar v1.1 Release Candidate 1

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 22.04.26 15:44, Zhihang Wei wrote:
> 
> 
> On 4/22/26 12:45, Jan Kiszka wrote:
>> On 22.04.26 12:42, Zhihang Wei wrote:
>>> Hi everyone,
>>>
>>> I have just tagged v1.1-rc1 as release candidate 1 for Isar v1.1.
>>>
>>> Please test on your downstream if necessary. Feedback is welcome.
>>>
>>> Other patches will continue to be tested but will not be applied before
>>> v1.1 is out. If you think any other patches should be included in v1.1,
>>> please let us know.
>>>
>> We still have the semi-cooked change of Felix in there that shuffles the
>> DTBs in differently incompatible ways around. Why are your tagging this?
>> We were still not settled here.
>>
>> Jan
>>
> 
> I've asked for steps to reproduce and made 1.1-rc1 proposal in [1] and
> would expect a response to it.
> 
> Could you please restate your proposal? Is it to keep 79e10791(the
> revert) and drop 8c34bb25(prefixing DTB) and tag as 1.1-rc2?
> 
> Dropping 8c34bb25 will break trixie builds for some targets. If we do
> that, the trixie dtb overlap issue should be fixed together with the
> final dtb solution in 1.2.

Renaming DTBs as Felix did is a suboptimal idea due to the complications
this will cause in picking up DTBs from the deploy folder. A folder with
original filenames (which are an API as well) is also what OE uses. It
just does not care about the conflicts we are seeing in some special
setups (like Isar CI) with multiconfig. If we really want to support
such scenarios, for DTBs as well as for other(!) artifacts, we should
establish a pattern for all of them, document and implement that based
on the DTB example.

However, if we cannot settle in time, the by far best solution is the
pure revert so that the API is back to pre-1.0, and we can design,
implement and test the best solution without any hurry and without
continuously breaking APIs. This is what I strongly recommended prior to
the 1.0 release as well.

The deployment issues seen with multiconfig in Isar CI can be almost
trivially be side-stepped for now by using separate builds for
conflicting targets. That would also be beneficial for CI pipelines that
allow a scale-out.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/597ba94c-92eb-4b36-82c0-0d38ce8d0016%40siemens.com.