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 > security and maintainability. Second case is interesting since, if you > maintain 5 projects which are 4.12 based it is way different then > maintain 4.0, 4.6, 4.9 etc. 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. Rebasing for maintainability is very vague. Throughout this discussion, it seemed that rebasing itself is the maintainability issue? I've seen some company size arguments on Gerrit. From my perspective, it doesn't get much smaller than the firmware department I work for. That's filled by about 40% of my time and beside some help from students nobody else. In this situation it turns out that the only strategy that scales is to upstream as much as possible. So, what do we do: Of course, we can't upstream every last bit. So we maintain local branches per product. On top of upstream, that usually contains the patches to add a new board which we try to upstream (I'm much behind lately, I have to admit) and maybe 10~20 commits that are too specific to upstream. Most common cause of a rebase is that we need support for a new platform. If the last board was upstreamed in the meantime, that only leaves these 10~20 commits to rebase. And these usually are local enough (e.g. our own board ports, utils) to not conflict with any tree-wide changes. There's a wrinkle: To upstream as much as possible, this often includes changes that affect all boards of a new platform. That's why I'm arguing against making such changes harder. My humble theory: Upstreaming is hard, hence we maintain more downstream patches, hence it's harder to rebase. If we now make upstreaming harder to ease the latter, we'll find ourselves in a vicious circle. You mentioned 4k LOC of downstream patches on Gerrit. Maybe we should try to figure out case-by-case what led to keeping them downstream? Maybe we can find upstream solutions for some of them? Nico [1] https://review.coreboot.org/c/coreboot/+/52576/1/Documentation/getting_started/gerrit_guidelines.md _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
