I guess this relates to #12. Perhaps @felixfontein's idea to add a different label when a backport suceeds is a better one.

Sometimes backporting fails without the backporting bot code completing (bug, or process is killed). In that case adding a label won't work.

Thanks for the suggestion! Some kind of a design vision / UX / config structure would be welcome. As for the crashes, I'd mention the case of GitHub's own eventual consistency and outages. Still, we could probably do an optimistic "best effort", like other apps.

Note that when you talk about a failing backport and just one label, it might be confusing as people often request backporting to many branches. The newest ones succeed while the older ones might be more suseptible to conflicts. It might end up being a confusing thing.

Also note that the bot is stateless.

Thanks for the suggestion! Some kind of a design vision / UX / config structure would be welcome.

Yeah, sure. I'll give it more thought.

I proposed a solution in #40.