> Date: Tue, 23 Oct 2018 22:05:27 +0900 > From: Rin Okuyama <rokuy...@rk.phys.keio.ac.jp> > > On 2018/10/23 2:33, Taylor R Campbell wrote: > > Perhaps it would have been better to see another iteration or two of > > drafts, but (a) bike shed discussions can be long and tedious and can > > discourage contributions, and (b) we can always revise README.md as a > > living document -- no need to revert altogether when we can just edit > > it to improve it. > > Well, it makes sense on one hand. But, on the other hand, your argument > can be very dangerous if it is abused; I really hate an attitude like > "Oh, discussion is falling into a bike shed! Let's commit it to shut them > up!" Of course, I do understand you are not a person to do such a thing.
You make a good point -- it would be bad form to sneak unwelcome changes in under the pretense of avoiding bike sheds. This case seems OK to me because, overall, I felt the response on tech-toolchain was positive -- e.g., https://mail-index.netbsd.org/tech-toolchain/2018/10/10/msg003296.html https://mail-index.netbsd.org/tech-toolchain/2018/10/10/msg003303.html The reservations in the tech-toolchain thread were about details, choices of wording, &c., which can always be improved in a living document. > Yes, we must explain the relation between CVS master and GitHub mirror, > at least. Others are minor problems although I feel it better to be > consistent with our existing documents. For example, architecture > names in http://wiki.netbsd.org/ports/ are not capitalized at all. I tweaked the document a bit to just copy the opening paragraph from netbsd.org, and to make a link to the ports page. If you or maya don't like it that way, feel free to put back the particular architecture names. (If anyone wants to put it back, for the particular names, I think we should probably say either (e.g.) `AArch64', `VAX', and `Motorola 68k', or `aarch64', `vax', and `m68k', depending on whether we want to emphasize the branding or the NetBSD code name for each thing.) Feel free to suggest more changes -- it need not be perfect before it can serve a useful purpose, as a living document.