On Wed, 5 Dec 2018, Richard Stallman wrote: > More precisely, how far we can _reduce_ what we require a user to know, > to do those things?
For example, we have the rules on comments that mean in many cases the required information should be in a comment and it shouldn't be necessary to refer to the history at all in those cases - many bug fixes or new features don't require referring to the history. I'm not proposing any change to the expectations on comments. We take ensuring proper comments seriously in glibc patch review, especially in tricky areas such as atomic operations and synchronization. For example, many projects expect various classes of changes to add tests to the automated testsuite. In that case, someone wondering why some code is there can try changing it and seeing if any tests fail. For example, many projects have their own guidance on how to work with their repositories, which may include example git commands. (Even with a perfectly intuitive version control system everyone is fully expert in, such guidance would still be needed, simply to document things such as branching conventions.) For example, many projects have documentation of internals such as how the source tree is arranged. For example, there are various ways in which someone running into difficulty can ask for help with their particular task (on the libc-help mailing list or #glibc IRC). It's not at all the case that someone wishing to fix a bug would need to be an expert in git in the absence of ChangeLogs; there are many sources of information, both on the design and motivation of particular code and on how to work with the source tree and the repository, and many ways for non-experts to get started and make progress. Sometimes a particular history investigation might prove to be trickier and need more expertise, but then sometimes a particular bug fix might also turn out to involve tricky issues as well and so be unsuitable for a beginner. -- Joseph S. Myers [email protected]
