On Fri, May 14, 2021 at 11:48 AM J. Eric Ivancich <ivancich@xxxxxxxxxx> wrote: > > Hi Ilya, > > This process seems to have led to mistakes and wasted cycles by some (many?) contributors, such as me, and some of which you make reference to. For example, after the initial force-push on a base branch I unknowingly did a rebase on a backport branch, due to an automated email, only to have to undo the rebase once the base branch was restored. Some of my backports generated lots of extraneous emails, now list many additional contributors, along with some additional invites for reviewers. Yes, it's a real mess and everyone hates this process. The point of the process is to avoid having to rewrite (rebase) any commits. The -saved branch is used for the current tip of whatever release branch we're hotfixing. The release branch is then hard reset to the last minor release, hotfix patches applied, and then a new release is generated. That last part relies on the branch name as part of the release and is the cause of all these gymnastics. Once the new release is done, the -saved branch merges the new minor release (one new merge commit) and then the release branch hard resets to the -saved branch. This process causes github to freak out and add a number of commits to all of the backport PRs. The "fix" for that is to change the base branch for every backport PR to -saved and back which results in the spam you see. We don't know a better way around that, sorry. Ultimately, the release scripts need to be fixed to no longer require these gymnastics. -- Patrick Donnelly, Ph.D. He / Him / His Principal Software Engineer Red Hat Sunnyvale, CA GPG: 19F28A586F808C2402351B93C3301A3E258DD79D _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
