On Fri, Oct 21, 2022 at 9:42 AM Junio C Hamano [off-list ref] wrote:

quoted

+- Code review can take place in a variety of different locations,
+  depending on context. These are: patches sent inline on the
+  git-security list, a private fork on GitHub associated with the
+  draft security advisory, or the git/cabal repository.

Here, we name "the git/cabal repository" but the word never appears
again in the document, we later refer to the same thing "private
repositories that are owned by the Git project, with tightly
controlled access", but to outsiders, it is not clear that they are
the same thing.  Perhaps writing

    ..., or the git/cabal repository (private repository owned by
    the Git project with tightly controlled access).

here, and replacing the later reference with just "the git/cabal
repository", would be sufficient.

Fixed in the next version!

quoted

+  Contributors working on a fix should consider beginning by sending
+  patches to the git-security list (inline with the original thread),
+  since they are accessible to all subscribers, along with the original
+  reporter.

Or we can make it a separate bullet point, which may make it simpler
to read in the source form.

Fixed, thanks for pointing that out.

quoted

+- Once the review has settled and everyone involved in the review agrees that
+  the patches are ready, the Git maintainer, and others determine a release date
+  as well as the release trains that are serviced. The decision regarding which

We typically know how involved the final changes would be (i.e. the
minimum time it would take for us and involved others to prepare the
release) way before all the t's are crossed and i's are dotted in
the patches, so setting the release date may be done much earlier.

Distilled into s/ready/nearing the finish line/

quoted

+- Less than a week before the release, a mail with the relevant information is
+  sent to [off-list ref] (see below), a list used to pre-announce
+  embargoed releases of open source projects to the stakeholders of all major
+  distributions of Linux as well as other OSes. This includes a Git bundle
+  of the tagged version(s), but no further specifics of the vulnerability.

I am not sure how much value it adds to have ", but no further..."
at the end.  Anybody who sees this e-mail has the Git bundle, which
is relative to the last stable release, and can be used to create
the full source of the releases by anybody who has access to the
public Git repositories.  The source includes the release notes in
the Documentation/RelNotes/ directory that describe everything to
know about the vulnerabilities the releases address.

I think it makes sense to just remove the entire last sentence, as the
relevant information is referenced in the parenthetical "(see below)".