| 1 |
On 28.7.2021 20.30, Alec Warner wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> When we accept a git commit, many judgments must be made. Some |
| 5 |
> judgements are automated (and we can reject commits that do not pass |
| 6 |
> these judgments). Some of them are not automatable, and we rely on |
| 7 |
> committers to make that judgement with their mind. Not all committers |
| 8 |
> will judge things the same way and that is OK; it's a risk they take on |
| 9 |
> (as a committer) and that the organization takes on (as, in the case |
| 10 |
> above, we may need to audit contributions from time to time.) I'm not |
| 11 |
> certain it's a sane argument to simply say "well this judgement is not |
| 12 |
> automatable so we shouldn't have that judgement at all." |
| 13 |
> |
| 14 |
> The judgements are the value you bring (as a human committer.) If I |
| 15 |
> could automate your work then I would; then I wouldn't need committers |
| 16 |
> anymore. However I do not think this is possible in practice. This is my |
| 17 |
> point relating to the rules above. If there were a set of codified rules |
| 18 |
> I could program a computer to do them (make them automated judgements.) |
| 19 |
> I'm suggesting this is not the case and again you as a committer need to |
| 20 |
> exercise your own judgement when accepting a commit. There is still the |
| 21 |
> distinction of "how do I as a committer make good judgements" and it's |
| 22 |
> clear we are struggling in this area. |
| 23 |
> |
| 24 |
|
| 25 |
Very vaguely, should a clarification / example be written, where for |
| 26 |
example eclass code and newly introduced complex ebuild code *might* |
| 27 |
require an acknowledged sign-off from the contributor? While simple |
| 28 |
version bumps, EAPI-bumps with given new eclass functions don't? |
| 29 |
|
| 30 |
-- juippis |
Archives