[bug#48696] [PATCH 0/3] Documenting commit reverts and revocation

["Ludovic Courtès" <ludo@gnu.org>]

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>   @subsection Addressing Issues
>>
>>   Peer review (@pxref{Submitting Patches}) and tools such as
>>   @command{guix lint} (@pxref{Invoking guix lint}) and the test suite
>>   (@pxref{Running the Test Suite}) should catch issues before they are
>>   pushed.  Yet, commits that ``break'' functionality might occasionally
>>   go through.  When that happens, there are two priorities: mitigating
>>   the impact, and understanding what happened to reduce the chance of
>>   similar incidents in the future.  The responsibility for both these
>>   things primarily lies with those involved, but like everything this is
>>   a group effort.
>>   
>>   Some issues can directly affect all users---for instance because they
>>   make @command{guix pull} fail or break core functionality, because they
>>   break major packages (at build time or run time), or because they
>>   introduce known security vulnerabilities.
>
> I'm not sure what this paragraph is getting at?

It’s supposed to be provide concrete guidance to a committer wondering
whether they can/should/are entitled to revert a given commit.

> In any case, for security vulnerabilities, to affect all users they
> would also have to occur in major packages.

Agreed.  The word “known” is important here: if I remove *-CVE-*.patch,
or if I downgrade a package, I’m likely introducing a “known”
vulnerability; if I’m adding a new package that later happens to be
vulnerable, it’s not a “known” vulnerability (it’s just routine ;-)).

> I think the above text looks good. As noted above, I'm unsure about the
> second paragraph, but that's not a big issue.

OK, thanks for taking the time to discuss it.  I’ll send a v2 so
everyone gets a chance to chime in.

Ludo’.