[coreboot] Changes to the coreboot Project Structure
Vladimir 'φ-coder/phcoder' Serbinenko
phcoder at gmail.com
Tue Mar 25 06:20:59 CET 2014
On 25.03.2014 02:33, Stefan Reinauer wrote:
> * 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.
I don't see how this prevents any of my propositions for the bulk of the
boards. The problem you describe isn't going away with your proposition.
We still want to have a top which is supposed to work on all boards.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 274 bytes
Desc: OpenPGP digital signature
More information about the coreboot