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 around documenting sweeping changes.
I think it's nice to use a script and if one does, sharing it is obviously a good thing. But demanding that would again burden up- stream development.
Do you place spatch in this category?
I mean, do you see it as too burdensome to mandate that changes affecting the tree more than some TBD threshold are to be generated by an spatch which must also be contributed?
Clearly it is one step more to create that spatch instead of just changing all the files, but in my experience it pays off very quickly; it will never miss any files and it pays forward, helping others in the community who share the goal but can't yet push/publish.
Not only does coccinelle understand the C language but it's indeed built for the very purpose of refactoring C code across large codebases. I admit that I am biased though; I find semantic patching quite fun. :)
Werner mentioned that it might take longer to write an spatch than change something in two boards. If we do decide to try to reduce efforts through spatches then we could start out by having a high-ish threshold for what changes must include an spatch and also set a sensible date for review of outcomes of the experiment?
I think we first need a very precise description of the problem.
I think that's fair, although I can imagine upstream changes to cause problems when working on a board for a platform that's newish with platform support upstream moving around.
My guess is that somebody is trying to rebase downstream work rather often. Is that the case? If so, I'd ask what the reasons for each rebase are.
If so, I guess to not stray too far from master.
Nico Huber wrote:
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.
Thanks for sharing your situation!
Are your boards usually on the newest platforms, or more often on more mature platforms?
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.
So I have to ask again, do you really mean that requiring spatches is "making such changes harder" ?
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?
Certainly a good idea!
Thanks
//Peter