On Fri, Oct 21, 2022 at 9:42 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > +- 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! > > + 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. > > +- 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/ > > > +- Less than a week before the release, a mail with the relevant information is > > + sent to <distros@xxxxxxxxxxxxxxx> (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)".
