* David Hubbard david.c.hubbard+coreboot@gmail.com [140323 20:33]:
On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko < phcoder@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.
Stefan
On 25.03.2014 02:33, Stefan Reinauer wrote:
- David Hubbard david.c.hubbard+coreboot@gmail.com [140323 20:33]:
On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko < phcoder@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
On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko < phcoder@gmail.com> wrote:
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.
All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure?
ron
-
ron minnich -
Stefan Reinauer -
Vladimir 'φ-coder/phcoder' Serbinenko