Change security release process development workflow
Security release process is one of the major pain points of our release, if not the top one due to the impact.
Security release process is different from our regular work and as such is causing a lot of confusion for all engineers working on security issues.
The whole process is documented in https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md but we rely on people reading and understanding the whole flow before they start working. This has been proven to be a major issue as people push to wrong remotes by accident or merge things they shouldn't. We attempted streamlining this process by having descriptive docs, protecting security branches and so on but that did not work.
We need to find a different way of handling this whole process or find a better way of educating everyone.
Few pain points:
- Security issue is opened on GitLab.com so engineers use GitLab.com automatically to do work
- Even with security harness scripts, engineers do not use them so they end up accidentally pushing to GitLab.com
- Even if they land on dev.gitlab.org where they should be working on, maintainers are used to merging MR's after review so they get prematurely merged causing further confusion for RMs
We need to consider if it is worth trying to incrementally change the process further or just do a radical overhaul of security release from engineering side. Maybe something like creating a development box where engineers need to work when they work on security releases.