Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prioritise evaluation for PRs with security label #653

Open
felschr opened this issue Sep 26, 2023 · 4 comments
Open

prioritise evaluation for PRs with security label #653

felschr opened this issue Sep 26, 2023 · 4 comments

Comments

@felschr
Copy link
Member

felschr commented Sep 26, 2023

How about prioritising evaluation for PRs with the 1.severity: security label?
That could speed up the process of patching vulnerabilities.

Related: #397

@felschr
Copy link
Member Author

felschr commented Sep 26, 2023

Another idea: At least for PRs with the security label, ofborg could create automatic backport PRs right away instead of waiting for the original PR to be merged.
This would also start the evaluation right away.

Not entirely sure how problematic that would be with referencing commit hashes in the cherry picked commits.
Perhaps the PR could be created as a draft (which still invokes evaluation) and once the original PR is merged it could be updated & marked as ready. Ideally without causing another evaluation.

This would simplify & speed up backports of security fixes even further.

Related: #437

@Artturin
Copy link
Member

automatic backports would be more suitable for a github action because ofborg doesn't create commits.

@felschr
Copy link
Member Author

felschr commented Sep 26, 2023

Oh, you're right. I kinda thought those were created by ofborg as well, but I mixed that up.
It might still require some kind of coordination between ofborg & the backport GitHub action.

What happens when a force-push only updates commit messages, and contents remain unchanged from before?
Does that cause a reevaluation by ofborg? Could that be avoided?

@mweinelt
Copy link
Member

ofborg could create automatic backport PRs right away instead of waiting for the original PR to be merged.

Security responses for the stable release are usually different from that we take for unstable. This means we often cannot backport the change we did to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants