So here&#39;s a suggestion, inspired by the Go release process.<div><br></div><div>0. We have a standard go/no-go test, ideally a single command, that marks a board as &quot;good.&quot; </div><div><br><div>1. in a given quarter, we have a set of mainboards in src/mainboard that are known good and are easily enumerable (via ls, ideally; i.e. I don&#39;t have to go to a web site to see which boards are good). Call this Q+0.</div><div><div><br></div><div>2. in any given quarter, we are working on the mainboard release for the following quarter. I.e., we are fixing code in src/mainboard. Call this Q+1.</div><div><br><div>3. Because a trivial chipset change can break many mainboards, the only thing one can change for the following quarter is code in src/mainboard; all other code changes can only apply to the quarter-after-next. Call this Q+2.</div><div><br></div><div>4.  at the end of each quarter is the release; the set of boards &quot;known good&quot; by the test (see 0) at the end of that quarter will be listed in (1) as the known good set. </div></div></div><div><br></div><div><br></div><div>We hence have several overlapping activities, covering three quarters, made more complex by the fact that fixing mainboard A can, if it involves chipset code, break mainboard B. Hence the requirement that code other than src/mainboard code can only apply to a release in the quarter-after-next.</div><div><br></div><div>ron</div><div><br></div><div><br></div><div><br></div><div><br></div></div>