Labels applied by prprocessor in Foreman core

Hello everyone,

Recently there has been some interest in applying labels to the Foreman Core repository.

There is one to apply the ui label based changes in the webpack directory and another to generalize that to include app/assets. Both are good and I’m sure we can work that out.

In https://github.com/theforeman/prprocessor/pull/120 I have two suggestions for stable branches. In the first we apply a label per version (1.18-stable means a 1.18 label). The other is *-stable means Cherry pick. Looking for feedback if we want both, just one (and if so, which one?) or neither.

I have also seen the WIP label. We already have some detection if a PR is WIP so we can probably apply the label automatically allowing you to easily filter out WIP commits. Another thought is not applying the Needs review label if it is WIP making it more useful. Is this a good idea?

The open question is: are there other labels we want to apply?

1 Like

I’d really these labels:

bug / enhancement - to distinguish if the pr is a bug that needs more attention than a new feature

priority/important - priority/critical-urgent - to mark critical prs that need special attention, e.g. a security issue or a major bug

needs ux - prs that need attention by ux folks

area/vmware (and others) - to indicate what area or component a PR affects (like provisioning, puppet, ui, …)

a backport label to indicate backported features into stable branches (i would avoid the term cherry-pick here as it does not have to be a cherry-picked commit)

I wonder if we should read this from the Redmine issue which has a tracker Feature/Refactor or Bug.

Makes sense but this is probably one that humans should apply.

I’d prefer a more generic ux label over needs ux.

Could file locations be able to determine this or is it too spread out? I get that file locations will never cover everything but it be worth the effort?

Agreed. Perhaps a more generic one is Stable branch? That would also cover infra fixed that aren’t backports (pinning dependencies, releases etc).

1 Like

+1, makes sense

Ansible uses that technique already. From my understanding, it works quite well. As an alternative we could also rely on the redmine issue category.