[coreboot] Changes to the coreboot Project Structure
stefan.reinauer at coreboot.org
Tue Mar 25 02:33:33 CET 2014
* David Hubbard <david.c.hubbard+coreboot at gmail.com> [140323 20:33]:
> On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko <
> phcoder at gmail.com> wrote:
> On 23.03.2014 19:24, ron minnich wrote:
> > So I believe the problem is not the idea of gatekeepers, but the
> > manner in which they are proposed to work. Can you tell me what about
> > this upsets you? I want to understand.
> The problem is that the proposal is that all commits go through
> gatekeepers. It's bottleneck. It makes much more sense to have per-path
> maintainers and tiered code.
> E.g. we could keep all boards rather than shooting them and the ones
> that are considered to be too old can have less stringent requirements
> on commits. This will free the qualified people time to concentrate on
> boards where it's most important.
> Also it will benefit "unimportant" boards as well as they'll be easier
> to keep.
> Then per-path maintainer and gatekeeper are contradictory concepts. How
> one can be maintainer if he can't commit to his maintained code. I feel,
> for example, that nehalem code and resulting boards are my
> responsibility and I should be able to commit there easily. Getekeeprs
> will make this impossible as I'm more or less the only one who knows
> nehalem code *and* cares about it.
> I feel like the top-level maintainers would be only about overall
> structure, not about details in Board:foo/bar they've never even seen
> and solving disputes. Making everything go through 6 people is
> unfeasible as 6 people can't represent broad range of interests and some
> parts of code will get neglected more that they have to be of simple
> scarceness of resources.
> Without speaking for anyone or about anything else, can Stefan comment on this
> proposal by Vladimir? It seems relatively cool and reasonable.
Tried to do so in the other mail... There's too much risk involved in
working directly on upstream. The downsides just outweigh the benefits
(for everybody, really)
For example, when getting to the "hot phase" of a new product, we don't
even use our chromium "top of tree", but create a firmware branch
specifically for a new product. Patches relevant to that product go into
that branch (and top of tree, aka HEAD) but NOTHING else. For every
firmware image that is released, there are also tests involving
thousands and thousands of reboots and suspend/resume cycles to make
sure that the product is absolutely stable. Because if 1/100k resumes
crashes that means for a million users there are ten users every day
whose computers crash. This level of testing is simply not possible when
aiming at a moving target.
More information about the coreboot