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 solution. What I tried to do was to bring 3mdeb perspective related to gerrit documentation proposal and discuss how problems we see can be addressed.
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.
Maybe it is odd, but backporting Intel Boot Guard or vboot to old branch and supporting it there seem to be equally odd. I also had in mind security bug fixes, which also may be not easy to back port in light of missive tree changes and lack of QA to confirm things works in the same way. Of course in security bug fixes would be way easier to backport then features.
Rebasing for maintainability is very vague. Throughout this discussion, it seemed that rebasing itself is the maintainability issue?
Question I was answering was from Julius, "why on Earth would you want to rebase that onto the latest master after you have stabilized?"
Typically we do not rebase on master but on tags, but it doesn't matter since "There is no stability guarantee".
Suggestion was, that we should do branches, what means we end up with 4.0.x, 4.6.x (where x is our patch on top of tag) etc. and backport whatever needed. My point was that maintainability cost is way lower when you have 5 projects on 4.12 instead spread through tags, since backporting is less expensive. What of course means you have to rebase older code to some "stable" point (e.g. 4.12) - it doesn't have to be upstream head. Of course this lead to LTS again.
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.
I already addressed that in gerrit discussion. I agree with that approach.
IMO feedback we gathering in this discussion could land in documentation to provide information how development should be handled in various situation we try to handle. At least we would not waste time for this kind of discussion, but will point to documentation where maintenance best practices would be described.
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.
Clearly the perception here is that my emails try to convince to make upstreaming harder. I'm not trying to do that. When I started discussion I mentioned this is little bit off-topic to tree-wide changes, but I was asked to bring my comments from gerrit here.
Concluding I'm promoting distributed QA and stable development point with some quality guarantees in form of QA report. I know there is not enough resources for that, but decided that discussion about tree-wide changes is good point to slowly start moving that forward.
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?
I enumerated that on gerrit, those are some examples. We can move discussion here, if you want. I'm not claiming those are unupstreamable patches - maybe we didn't tried hard enough or simply didn't have enough resources for that.
Maybe we can find upstream solutions for some of them?
I'm pretty sure we can, but I believe despite that some points from discussion will be still valid.
Best Regards,