René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Automating revert commits","articleBody":"@pablogsal recently opened a PR for automating revert commits.\r\nI agree with the issue but respectfully disagree with that particular proposal.\r\n\r\nCopying the reasoning from [Pablo's comment](https://github.com/python/buildmaster-config/pull/535#issuecomment-2407221523): \r\n\r\n\u003e [There should be automation that will] open (but doesn't merge) revert PRs when a builtbot builder has failed [...].\r\n\u003e\r\n\u003e The idea is not to force the revert on people because a human still needs to merge the PR and the discussion needs to happen as well but to start the process in a way that's not someone opening a revert PR to someone else (it's a bot opening the revert PR).\r\n\u003e\r\n\u003e This won't caught everything but it will caught as many things we can be sure that are caused by a single commit and the PRs will be open by a bot and not a human, highlighting that this is an automated process to not have the CI broken.\r\n\u003e\r\n\u003e The problem that this solves is not having the CI red for a long time making fixes or reverts more challenging as time passes and the reverts are not clean anymore. We have discussed many times (not only in this last core dev sprint) that having the buildbot failing for a long time makes things much more difficult, specially when issues start to pile up and people are slow to act..\r\n\r\nMy own plan of action would be to allow humans to initiate the process:\r\n\r\n- [ ] Teach `cherry-picker` to `--revert` commits. (Note that in Git, cherry-picks and reverts are very similar once started, see the `--continue` option [for `cherry_pick`](https://git-scm.com/docs/git-cherry-pick#Documentation/git-cherry-pick.txt---continue) and [`revert`](https://git-scm.com/docs/git-revert#Documentation/git-revert.txt---continue).)\r\n- [ ] Teach @miss-islington to open a revert PR, and re-open the issue, when a new `needs-revert` label is added. The GitHub comment should explain that we revert because failing CI can hide other issues.\r\n- [ ] *Then*, have Buildbot automation apply the label, so that a human isn't initiating the action.\r\n\r\nDoes that sound reasonable?\r\n\r\n(FWIW, my current priority is putting breaking PRs, and individual test failures, on the [dashboard](https://buildbot.python.org/#/release_status) -- the first step for a  revert or fix is for the failure to show up there.)","author":{"url":"https://github.com/encukou","@type":"Person","name":"encukou"},"datePublished":"2024-10-22T14:40:46.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":18},"url":"https://github.com/559/core-workflow/issues/559"}