51 lines
1.4 KiB
Markdown
51 lines
1.4 KiB
Markdown
|
Specific Workflows Proposals
|
||
|
============================
|
||
|
|
||
|
Moving project management out of the UI allows a very flexible scenario where
|
||
|
each workflow can be defined almost as a "greenfield project". The only
|
||
|
constraints are:
|
||
|
|
||
|
1. Operate on Project Git
|
||
|
2. OBS is used to build your project
|
||
|
|
||
|
Below are some proposed proposed workflows
|
||
|
|
||
|
|
||
|
Devel project
|
||
|
-------------
|
||
|
|
||
|
Uses both `pr-review` and `prjgit-updater` workflow. This allows the project's
|
||
|
packages to be updated with direct push of changes or via PR workflow
|
||
|
|
||
|
Maintainer permissions are handled via `maintainer-bot` workflow.
|
||
|
|
||
|
|
||
|
Factory / SLES / SLEM / SLFO / etc.
|
||
|
-----------------------------------
|
||
|
|
||
|
Uses `pr-review` workflow exclusively. Package updates are only done as a
|
||
|
consequence of PR to the project.
|
||
|
|
||
|
Maintainer permissions are handled via `maintainer-bot` workflow
|
||
|
|
||
|
|
||
|
Maintenance Updates
|
||
|
-------------------
|
||
|
|
||
|
Same as above, except build with `Buildonly: ` flags in project config file.
|
||
|
This prevents entire project from being rebuilt during maintenance.
|
||
|
|
||
|
PTFs
|
||
|
----
|
||
|
|
||
|
Same as maintenance, except that the forks are are not merged back into the main
|
||
|
project git but need to be rebased. Project Git simplifies tracking of package
|
||
|
updates -- only need to check if you have conflicting submodule update.
|
||
|
|
||
|
Embargoed updated
|
||
|
-----------------
|
||
|
|
||
|
`/pool` forked to `/security-pool` along with the project. Proposed updates are
|
||
|
then handled via `/security-pool` and only merged back to `/pool` after CRD
|
||
|
|