Dear Piotr,
Am 10.05.21 um 13:51 schrieb Piotr Król:
On 5/10/21 1:45 PM, Paul Menzel wrote:
Am 10.05.21 um 10:51 schrieb Piotr Król:
On 5/8/21 9:24 AM, Paul Menzel wrote:
Am 28.04.21 um 00:38 schrieb Piotr Król:
(...)
This is one part of the problem, other is specifications compati
On 5/10/21 1:45 PM, Paul Menzel wrote:
> Dear Piotr,
>
>
> Am 10.05.21 um 10:51 schrieb Piotr Król:
>
>> On 5/8/21 9:24 AM, Paul Menzel wrote:
>
>>> Am 28.04.21 um 00:38 schrieb Piotr Król:
>>
>> (...)
>>
This is one part of the problem, other is specifications compatibility
where A
Dear Piotr,
Am 10.05.21 um 10:51 schrieb Piotr Król:
On 5/8/21 9:24 AM, Paul Menzel wrote:
Am 28.04.21 um 00:38 schrieb Piotr Król:
(...)
This is one part of the problem, other is specifications compatibility
where ACPI is one that breaks things often. coreboot moves with ACPI
compiler
On 5/8/21 9:24 AM, Paul Menzel wrote:
> Dear Piotr,
Hi Paul,
>
>
> Thank you for bringing up these issues.
>
> Am 28.04.21 um 00:38 schrieb Piotr Król:
(...)
>> This is one part of the problem, other is specifications compatibility
>> where ACPI is one that breaks things often. coreboot mo
Dear Piotr,
Thank you for bringing up these issues.
Am 28.04.21 um 00:38 schrieb Piotr Król:
On 4/21/21 8:33 PM, Patrick Georgi via coreboot wrote:
In our leadership meeting[1] we discussed how we should deal with
tree-wide changes (ranging from "new file header" to "some API is gone
now"
Am Sa., 8. Mai 2021 um 03:08 Uhr schrieb Julius Werner :
> I understand that you might like to have both [features and stability] but
> I think that's just fundamentally impossible -- big new features just tend
> to require deep, invasive changes.
+1
> I think we could encourage that, I don't t
> > Rebasing for security seems odd. Usually one has to re-evaluate security
> > completely after a rebase. In my experience, security features randomly
> > break upstream like everything else. There is no stability guarantee.
>
> Maybe it is odd, but backporting Intel Boot Guard or vboot to old br
Piotr Król wrote:
> I don't understand argument about running significant ("enough") of
> the infrastructure. Why maintainers of platforms do not run their
> part of infrastructure which support those platforms?
I think this is a key point. It's a lot easier to develop centralized
solutions, so th
On 5/6/21 11:34 PM, Nico Huber wrote:
> Hi Piotr,
Hi Nico,
>
> it feels like we are discussing the wrong things here. I've also looked
> at the Gerrit discussion[1]. We are discussing solutions, while the root
> cause is not understood yet.
Of course it was not my intention to push any soluti
Nico Huber wrote:
> > Another idea brought up was to require that such changes come with
> > documentation and, ideally, migration support in the form of scripts and
> > the like. We had something like this in the past[2] and I created a
> > proposal[3] to establish it as a rule and build a culture
On 5/6/21 2:43 PM, Patrick Georgi wrote:
> Am Do., 6. Mai 2021 um 14:03 Uhr schrieb Piotr Król
> mailto:piotr.k...@3mdeb.com>>:
>
> If 3mdeb maintains some boards, we already testing those and would be
> glad to hook, in secure way, to patch testing system, but I would like
> to know
Hi Piotr,
it feels like we are discussing the wrong things here. I've also looked
at the Gerrit discussion[1]. We are discussing solutions, while the root
cause is not understood yet.
On 06.05.21 00:13, Piotr Król wrote:
> There are many reasons for rebasing or updating firmware to name few
> sec
Am Do., 6. Mai 2021 um 14:03 Uhr schrieb Piotr Król :
> If 3mdeb maintains some boards, we already testing those and would be
> glad to hook, in secure way, to patch testing system, but I would like
> to know where is interface documentation so I can evaluate cost of
> integration and convince cus
On 5/6/21 1:35 AM, Julius Werner wrote:
>>> As an
>>> open source project, coreboot doesn't have anywhere near the resources
>>> to do enough QA to guarantee that the tip of the master branch (or any
>>> branch or tag, for that matter) was stable enough to be shipped in a
>>> product at any point
> > As an
> > open source project, coreboot doesn't have anywhere near the resources
> > to do enough QA to guarantee that the tip of the master branch (or any
> > branch or tag, for that matter) was stable enough to be shipped in a
> > product at any point in time... even Linux cannot do that, and
On 5/5/21 10:56 PM, Julius Werner wrote:
Hi Julius,
> Sorry for being a bit late here, but I wanted to second what Nico
> said. It's important to not add undue burden to the development
> process. I think the master branch is meant for development, not for
> shipping long-term stable products.
Sorry for being a bit late here, but I wanted to second what Nico
said. It's important to not add undue burden to the development
process. I think the master branch is meant for development, not for
shipping long-term stable products. If you're installing coreboot in a
train or medical device, then
On 4/21/21 8:33 PM, Patrick Georgi via coreboot wrote:
> Hi everybody,
Hi,
>
> In our leadership meeting[1] we discussed how we should deal with
> tree-wide changes (ranging from "new file header" to "some API is gone
> now"). The concern was that right now, anything can change at any time,
>
Am Do., 22. Apr. 2021 um 22:58 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > tree-wide changes
> ..
> > there may be other approaches on how to make development easier
>
> I'm a big fan of semantic patching as provided by coccinelle and used
> heavily in Linux kernel developme
Patrick Georgi via coreboot wrote:
> tree-wide changes
..
> there may be other approaches on how to make development easier
I'm a big fan of semantic patching as provided by coccinelle and used
heavily in Linux kernel development.
Perhaps one way to make lives easier is to require tree-wide chang
Hi,
On 21.04.21 20:33, Patrick Georgi via coreboot wrote:
> Hi everybody,
>
> In our leadership meeting[1] we discussed how we should deal with tree-wide
> changes (ranging from "new file header" to "some API is gone now"). The
> concern was that right now, anything can change at any time, making
21 matches
Mail list logo
