[coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.
> Stefan
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140325/ae4a41ba/attachment.sig>