--- I think this makes it easier to read this section. Otherwise, it's not immediately obvious that the "importing files" and "creating and using a branch" paragraphs are distinct kinds of changes, unrelated to the previous paragraphs.
OK for wwwdocs? htdocs/gitwrite.html | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 54f8005a..72bca381 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -157,25 +157,34 @@ list.</p> <p>The following changes can be made by everyone with write access:</p> +<ul> +<li> <p>Obvious fixes can be committed without prior approval. Just check in the fix and copy it to <code>gcc-patches</code>. A good test to determine whether a fix is obvious: <q>will the person who objects to my work the most be able to find a fault with my fix?</q> If the fix is later found to be faulty, it can always be rolled back. We don't want to get overly restrictive about checkin policies.</p> +</li> +<li> <p>Similarly, no outside approval is needed to revert a patch that you checked in.</p> +</li> +<li> <p><a href="codingconventions.html#upstream">Importing files maintained outside the tree from their official versions</a>.</p> +</li> +<li> <p><a href="#branches">Creating and using a branch</a> for development, including outside the parts of the compiler one maintains, provided that changes on the branch have copyright assignments or <a href="dco.html">DCO</a> certification. Merging such developments back to the mainline still needs approval in the usual way.</p> - +</li> +</ul> <hr> <h2 id="testing">Testing changes</h2> -- 2.52.0
