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 local development harder.
There have been a few ideas but nothing definite yet:
One idea was to declare some interfaces (e.g. those used by src/mainboards/**), with varying stability horizons (e.g. "only change right after a release"), or backward compatibility guarantees (although the details still seemed hazy on how that could work in practice.)
that would probably increase the burden to introduce such APIs. They must be designed much more carefully if they can't be changed at any time. That would also apply to our devicetree format which already evolves too slow, IMHO.
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.
One doesn't exclude the other, and there may be other approaches on how to make development easier without calcifying our codebase. Or maybe people don't see a problem that needs fixing?
I see a problem, but it's quite the opposite. IMO, upstream updates that affect all boards of a platform, for instance, are already too hard. One problem I've encountered multiple times is the lack of detailed public board documentation, e.g. schematics. Alas, for the platforms I work with, the first board ports in the tree are often those with the least public documentation. People with access to the documentation have become more helpful over the years, I think. So it's probably not a big issue anymore.
In any case, I wanted to bring it up in a larger forum to make sure that we find rough consensus across the community before a decision is made on how to proceed here.
Thanks. I think we first need a very precise description of the problem. Including some numbers (e.g. additional time spent on rebasing due to incompatible changes) to estimate how big the problem actually is. I don't see the big problem yet with the brief descriptions given.
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. Obviously, when somebody develops a bunch of patches and wants to upstream them later, that's at least one rebase. Are incompatible, site- wide changes already a problem in this case? Or are we talking about much more rebasing?
Nico
[1] minutes at https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj... [2] http://web.archive.org/web/20130315025026/http://www.coreboot.org/Flag_Days [3] https://review.coreboot.org/c/coreboot/+/52576