> >> Of course, there'll always be a gap when a new platform is added. We > >> could make it a rule, though, that no commit should be merged to the > >> master branch, before the one that hooks the build test up is reviewed. > >> > > This means that such code isn't build tested for even longer, effectively > > the whole development cycle until all the ducks are lined up. > > you mean it's less tested when it's sitting in the review queue, waiting > for the hook-up? I don't see any difference in that aspect. As long as > it's not hooked up for Jenkins, only the developers that work on the > new platform will do build tests. And they can only spot conflicts when/ > after rebasing the patch train, no matter if parts of it are already > merged. However, in case of conflicts, one could update patches that > aren't merged yet. But for patches that are already merged, one would > have to write fixups (more patches) and would have room to repeat the > error (I feel like I've seen fixups for fixups before).
For an individual developer this might make sense, but for large projects I think that will make automation and coordination across multiple companies unfeasible. The likely outcome is that large projects are developed internally and eventually we see a huge code drop after the product has been released (when the "ducks are lined up" as Patrick says), and by then nobody involved with development really cares about fixing up the code since their paycheck depends on launching the next thing. Then the community moans about not having a voice earlier in the process and wonder why companies aren't doing development upstream. In other words we go back to 2012 when Chromebooks started appearing upstream (hundreds of patches at a time being pushed from an internal repo to upstream) or 2020 when massive coreboot patches based on an old commit get posted elsewhere (like https://github.com/teslamotors/coreboot). > > Maybe even in a designated area within src/mainboard? "Staging" perhaps? > > Probably overkill, how about simply having a warning instead of the > board name in the Kconfig prompt? Agreed, and moving code around also makes history more difficult to follow so it's best to get the code structure in place early on if possible. > > > > > We have a number of conflicting goals (having usable code presented to > > users, getting development into the main tree early to prevent code drops > > after everything is said and done, incremental changes to ease review and > > following what's going on) and that would provide a reasonable compromise: > > the unfinished code is clearly identified as such but it's there for > > (automated) testing and we can encourage incremental, incomplete changes > > there. > Ack. +1. It's a difficult set of goals to balance, but we should certainly strive to improve the process for everyone. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
