> Commit access is completely open. If the code matches the expected style, doesn't cause the related tests to fail, and doesn't cause performance regressions it's accepted into the codebase. If it doesn't it's removed.
It seems to me that any spec. that went into sufficient detail to allow this would be more or less writing the project in another language, meaning there's no actual benefit. I can't imagine that a spec. that doesn't get into that level of detail would be sufficient to prevent all malicious/unwanted commits (say, subtly weakening cryptofunctions or leaking user data over side-channels).
>"It seems to me that any spec. that went into sufficient detail to allow this would be more or less writing the project in another language, meaning there's no actual benefit."
The benefit is in designing code at a higher level of abstraction, one that can be easily reasoned about. It is possible to design code at a high enough level where the specs and the code are one and the same, but most languages haven't got the type system sophistication of something like Idris or Haskell, which is a key component of pulling off this feat. The vast majority of code is written in languages that do not lend themselves to code as specification. Code contracts and other complimentary techniques (such as automated test generation) can go a long way to counteract those shortcomings.
Crypto functions are a special case. In this instance you won't save time by defining specifications as the requirements on algorithmic correctness are much higher than average. However, in this case the ideal would be formal verification, and that still requires a specification, it's just likely to be more verbose than you'll want for day to day code checking.
Lastly, consider the alternative if you don't use specifications. At this point the burden of performing code checks is with humans. With a large, fast-moving codebase it's unreasonable to expect any one individual to understand all the parts that constitute the whole at a sufficient level to stop new bugs creeping into code. It happens on every project, no known exceptions. With that in mind, why wouldn't you want to put in a framework to help catch bugs automatically? New bugs will still occur, but with a well specced program this should be at a vastly reduced rate.
It seems to me that any spec. that went into sufficient detail to allow this would be more or less writing the project in another language, meaning there's no actual benefit. I can't imagine that a spec. that doesn't get into that level of detail would be sufficient to prevent all malicious/unwanted commits (say, subtly weakening cryptofunctions or leaking user data over side-channels).