On 25.03.2014 02:33, Stefan Reinauer wrote: > * David Hubbard <david.c.hubbard+coreb...@gmail.com> [140323 20:33]: >> On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko < >> phco...@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 > > >
signature.asc
Description: OpenPGP digital signature
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot