Allow patches to be batched by themselves only

Development Approved RFCs
#1

Summary: Allow patches to be batched by themselves only.

I allow this RFC document to be modified and redistributed under the terms of the Apache-2.0 license, or the CC-BY-NC-SA 3.0 license, at your option.

Motivation

This RFC is to allow users to configure batch size limit by providing an option to allow patches to be batched by themselves only.

Guide-level explanation

Appending "single on"or "single=on" to the bors review command will force a patch to be batched by itself only and will never be put it a batch with other patches nor will other patches join its batch, like so:

bors r+ single on
bors r+ single=on

Once a patch is reviewed with "single on" appended, all future reviews on the patch will remember the option and the patch will always be batched alone.

If this behavior is no longer desired, it can be disabled by appending "single off" or "single=off" to the review command and can be re-enable later by appending "single on" to a review command.

bors r+ single off
bors r+ single=off

Additionally, the single command may be used without a review command like to turn the behavior on or off without having to review.

bors single=on
bors single=off

Reference-level explanation

The following options to the existing "bors r+" command, along with its alias, will be added:

bors r+ single on
bors r+ single off
bors merge single on
bors merge single off
bors single=on
bors single=off

These commands will enable and disable the functionality to force a patch to always be batched by itself. Because the option is appended to the review command, once the option is handled, the review command will also be handled.

To support the option, the "patches" table will require a column to store the flag which will be checked before batching the patch.

Checking whether a patch should be batched alone will be performed during the handling of the review command and during the bisection of a batch. Batches that are currently running or waiting will be left alone.

Drawbacks

There shouldn't be any drawbacks since the option only affects patches which have received the specified command and can be disabled if desired.

Rationale and alternatives

  • This design is a simple solution to providing the users a method to limit batch size.
  • An alternative solution would be allow the user to specify the max number of patches a batch can hold which would affect all patches in a project.

Prior art

  • The original bors system used implemented this solution. Unsure if other CI/CD systems implemented this system.

Unresolved questions

  • Is it necessary for the bisecting logic to honor the "single on" option? If the patch is already in a batch, it would either be merged in without any issues or fail sooner or later. Additionally, since the option is appended to the review command, the patch shouldn't ever be seen by the bisecting logic unless the patched r+'ed again while it's already in a batch.
  • Should the option also handle patches that are already in a running/waiting batch? Should it pull out the patch and place it in a separate batch by itself?

Future possibilities

None foreseen.

See also

Implemented by pull request #839 on GitHub

1 Like
#2

One thing you probably do want is to make sure the bors merge alias works, so bors merge single should work, too.

1 Like
#3

Ah I haven't thought about the aliases. That should also be supported as well.

On a related note, is there away I can edit the draft RFC? Or will I be able to add that in once the draft phase is over?

#4

Yeah, in the bottom bar with the heart, reply, and "..." buttons, there should also be a pencil button.

#5

Odd, I'm seeing the pencil icon on my message on I don't see the pencil icon on the post itself.

#6

Try it now.

#7

Thanks I see it now. I've edited the post to include the alias.

#8

Okay, this RFC seems pretty good.

It's going into its Final Comment Period. It will probably be accepted.

#9

Why can't we separate single away from r+?

If you want to turn it on but don't want to review, bors single on.

But I guess, you should also allow specifying separate commands together by doing either:

  • bors merge single on
  • bors single on merge

We even have = being used already. So, we can make the above even better:

  • bors merge single=on
  • bors single=on merge

This actually allows us to change the initial option a bit:

  • bors single=on
  • bors single=off

And then allow bors single to toggle between on and off.

1 Like
#10

I also think that separating single away from r+ would be a good idea as well.

I believe those interested in this single feature are interested in order to have BorsNG not use its batching strategy as described in this post: Batching strategy vs one-at-a-time. To implement a one-at-a-time strategy, maybe a bot could put bors single=on on every pull request and then the owner wouldn't have to remember to put single on after every initial r+. Although at that point, having a configuration option for BorsNG might be a better solution.

I don't think allowing the single to be seperated away from the r+ command would hurt, so I'll add it to the RFC.

However, I'm not sure if just using bors single to toggle would be necessary. If a pull request's comments get long enough, the user might just use single=on instead of tracking the toggles. Although I admit my experience with GitHub and BorsNG are limited to small projects so please correct me if having a toggle option is still desirable.

#11

I actually didn't like the toggle thing I suggested after giving it a bit of though. It would be hard keeping track of it. Let's not do it.

#12

I don't like toggling, either, but I do like the idea of having standalone commands for just bors single=on and bors single=off.

#13

This topic was automatically closed after 14 days. New replies are no longer allowed.

https://bors.tech/rfcs/0425-allow-patches-to-be-batched-by-themselves-only.html