On Mon, 11 Jul 2005, Giovanni Bajo wrote: > My personal position is that making documentation patches *blocked* by > review (as happens with code) is wrong. The worst thing it can happen is > that the documentation patch is wrong, and the doc maintainer can revert it > in literally seconds (using the Wiki; in minutes/hours using the TeX).
It's not for the doc maintainer to know whether most doc patches are correct or not; it should be the maintainer of the relevant parts of the compiler who reviews them in general. > Nobody is going to be blocked by this; no bootstrap will be broken; no wrong > code will be generated. This ain't code. In many common cases, the Wrong code will be generated when someone relies on subtly wrong information in the documentation. It is a well-established failure mode even on the best wikis (i.e. Wikipedia) that someone inserts subtly wrong information because of not knowing better (or not knowing that there is controversy among experts about which of two versions is correct) and this does not get corrected soon if at all. There may be *policies* of providing references to back up claims made, but (a) that can't work in the context of GCC and (b) I don't see Wikipedia edits routinely getting reverted simply for lack of substantiating evidence. We're dealing with subtle matters where there may be no one expert on the subject, and where reversion may not in general be any better than applying the patch: where the proper response will involve discussion of the individual edit to clarify the basis for the claims made and whether things should be refined. Perhaps the wiki could automatically send all changes to gcc-patches to assist in review? -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
