Hi.
Thinking about Aaron’s plans some more and discussing some details, I’d like to propose a way to move things forward that I believe avoids the traps of older attempts at rewriting coreboot while keeping everyone in the loop.
We’ll start a new branch, proposed name coreboot-experimental. It doesn’t start from scratch but is branched from master at some point. coreboot-experimental will operate under different rules than master that simplify breaking things to push the design forward:
1. abuild is modified to know about two classes of boards: those “on board” the experimental branch, and those which are not. This can be as simple as adding some tag to the board status file (proposal: “experimental”)
2. abuild builds everything and reports everything but only “fails” for “experimental” boards, to get a clear view on jenkins
3. the tree keeps all chipsets and mainboards, so we keep history
4. breaking changes are accompanied by setting “experimental” tags on boards supported by that change. We might want to establish a rule of reporting those changes (and how to cope with them) on http://www.coreboot.org/Flag_Days
5. Supported_Mainboards might need some work to report both branches properly (so people can see at a glance if a board is supported by master, experimental or both)
6. jenkins builds both branches
7. interested parties can revive boards by fixing them
8. changes to master can be ported to coreboot-experimental. The other direction likely breaks things
9. at some point coreboot-experimental is either a success and becomes the new master, or it’s not and vanishes (maybe after picking the good ideas). Ideally this happens fast enough that master didn’t diverge too badly.
Comments? Patrick
Patrick Georgi wrote:
- at some point coreboot-experimental is either a success and becomes
the new master, or it’s not and vanishes (maybe after picking the good ideas). Ideally this happens fast enough that master didn’t diverge too badly.
Comments?
This sounds like a standard topic branch workflow which is what I thought we were using all along.
//Peter
Am 2014-04-04 19:59, schrieb Peter Stuge:
Patrick Georgi wrote:
- at some point coreboot-experimental is either a success and becomes
the new master, or it’s not and vanishes (maybe after picking the good ideas). Ideally this happens fast enough that master didn’t diverge too badly.
Comments?
This sounds like a standard topic branch workflow which is what I thought we were using all along.
The deviation wrt topic branch workflow is to build a branch (where more than one feature can happen before we prove the things work) instead of gerrit topics, and that we allow (and formalize and encourage) a certain level of breakage in that branch. Essentially points 1 to 8 :-)
Regards, Patrick
Am 04.04.2014 07:03, schrieb Patrick Georgi:
- abuild is modified to know about two classes of boards: those “on
board” the experimental branch, and those which are not. This can be as simple as adding some tag to the board status file (proposal: “experimental”)
- abuild builds everything and reports everything but only “fails” for
“experimental” boards, to get a clear view on jenkins
This is active now on gerrit: http://review.coreboot.org/#/c/5488/ The branch name is "experimental" (no need for a coreboot- prefix in the coreboot repository).
- breaking changes are accompanied by setting “experimental” tags on
boards supported by that change. We might want to establish a rule of reporting those changes (and how to cope with them) on http://www.coreboot.org/Flag_Days
Any opinions on this one? The old flag day events can probably be deleted, so we could restart it.
- Supported_Mainboards might need some work to report both branches
properly (so people can see at a glance if a board is supported by master, experimental or both)
This still needs to be done.
- jenkins builds both branches
This is active.
Regards, Patrick
-
Patrick Georgi -
Peter Stuge