Maxim Cournoyer writes: > Christopher Baines writes: > >> Particularly to cover the case where things might need to happen with the >> build farms if changes are reverted. >> >> * doc/contributing.texi (Commit Access): Add guidance on reverting commits. >> >> Change-Id: Iba320b76b0927b693c75054b5473a50bdd77c7ee >> --- >> doc/contributing.texi | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/doc/contributing.texi b/doc/contributing.texi >> index d4784de452..c94ae940fa 100644 >> --- a/doc/contributing.texi >> +++ b/doc/contributing.texi >> @@ -2945,6 +2945,20 @@ Commit Access >> a consensus about the problem, learning from it and improving >> processes so that it's less likely to reoccur. >> >> +@subsubsection Reverting commits >> + >> +Like normal commits, the commit message should state why the changes are >> +being made, which in this case would be why the commits are being >> +reverted. >> + >> +If the changes are being reverted because they led to excessive number >> +of packages being affected, then a decision should be made whether to >> +allow the build farms to build the changes, or whether to avoid >> +this. For the bordeaux build farm, commits can be ignored by adding them >> +to the @code{ignore-commits} list in the >> +@code{build-from-guix-data-service} record, found in the bayfront >> +machine configuration. >> + > > It makes sense to me, but note that I'm increasingly weary of adding > more to this already lengthy section. > > It'll be nice when we finally have something sitting between us and the > git server to automate checks such as 'oh, this rebuilds too much, > sorry, you'll need to create a feature branch' or 'oops, the test suite > failed', etc. Thanks for taking a look, I've pushed this to master as 061c5820d1bacde60782b3d82ffb9770454dc658. And yeah, I agree it would be good to have automation/process to prevent these issues, this is just a stopgap measure.