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
|
|
|