openSUSE:ALP/Workgroups/Git-Packaging-Workflow/WorkPackages/Submission-Workflows-Protoype
Workflow of a Package modification
Concept picture
Phase 1
In this first phase, the package maintainer would be receiving a contribution to an existing package in the form of a Pull request. For the prototype an on-premises hosted Gitea instance is being used because it was considered a more certification-ready approach than going with a Software-as-a-Service approach like GitHub, although in the design nothing is depending on Gitea-specific features so the implementation can be replaced by another Git Hoster/Frontend later.
This Pull request would undergo the following steps:
- The package maintainer is getting notified about the existence of a new PR
- The package specific tests including a build test are triggered an the test results are reported alongside the PR
- The package maintainer is reviewing the change and submits a vote (but does not merge it)
- Once maintainer voted, the pull request gets picked up by the staging bot and will undergo a staging-integration test and the additional reviews needed for primary-distribution integration (source-review, legal checks, openqa)
- The release engineer validates that all conditions have been met and merges the PR into the factory branch
This workflow assumes that all the steps needed to integrate a change into the "factory" branch of the package are attached to one PR, and the package maintainer as well as the contributor can track their status from the PR alone without having to visit any other system or webpage to get an overview on the status.
For packages that are developed in a coordindated team/subset, it is possible that changes are tested in a "devel" branch, which would be outside the scope of this description.
In this Phase 1, the changes are handled package-by-package and integration tested against a "factory" (following the "Factory first" development workflow paradigm). Once a change has entered the factory branch, derived distributions (like in this picture the ALP distribution) can decide to cherry-pick the change, potentially at a lower integration threshold as the particular change has been already integration tested.
In this Phase 1, the release engineer would continue to operate using the existing Build Service Staging mechanics and project maintenance. This also means that the existing issues with e.g. prjconfig remain unresolved. These are intended to be addressed in the later stage when the distribution maintenance moves into a git project as well.
Phase 2
In this phase the project is also maintained in the git repository, and the distribution release engineer is also operating purely outside the OBS UI/mechanics in Pull requests. This has a larger impact on the current project handling and build resources needed so it will require further thought on how to implement that in a scalable fashion. One could imagine that this is similar to running "pbuild" as a CI / Action on a PR and collecting the test results (+ results of further testing from means like e.g. openQA) and adding that as a buildresult to the PR of the distribution git.
Consequently every PR would be build in isolation, which is similar to how currently there are multiple "Letter-Stagings" in the distribution development in the Open Build Service. However, each change to a PR would likely cause a full rebuild as previous build results cannot easily be reused.
Concept Picture
In this model, the build service project would be entirely defined by a git repository and every distribution increment would consider of one or more package updates that are being tested together in a single PR.