openSUSE:ALP/Workgroups/Git-Packaging-Workflow/WorkPackages/Submission-Workflows
Mission
Built a robust proposal on how to manage the ALP package sources in git with the goal to ease packager life.
Goals
Ease the packager life, by primarily building on git rather than having to learn too many OBS specifics in order to maintain distribution packages.
Exactly what problem will this solve?
How it is
The majority of existing employees/contributors and also newcomers have knowledge and experience with the (de-facto standard) GIT version control system and command line client. On the other hand the OBS version control and command line client is not very wide spread. Additionally the OBS version control is in many regards weaker than GIT in managing version control effectively.
Consequences
The specifics of OBS version contol have to be learned by everyone to be able to effectively work on packages. There is no synergy with the wider developer community in regards to documentation on how to achieve workflows. As OBS version control is very OBS centric it is also not supported in most general development tools like IDEs, GUIs, CI services etc.
Workflows that are particularly problematic with the OBS version control and osc:
- branches: Each âbranchâ in OBS is in itâs own project/package with its own history. For any package (like aaa_base) there are many different OBS projects that hold the code (e.g. osc -A https://api.suse.de maintained aaa_base) in different states. Yet no cross-branch workflows (merge, rebase, cherry-pick etc.) exist which makes working with âbranchesâ harder than it needs to be.
- No way to sign commits individually and no way to verify that what OBS returned is what was committed earlier
- Working with revisions (checkout, diff, resolving merge conflicts etc.) is hard. Especially with linked packages where you need to find expanded srcmd5 manually etc.
- more sophisticated commands like bisect and revert donât exist
- ignoring local files isnât easy
How it should be
The (source file) version control part of the packagers workflow is done by GIT and the git command line client.
The rest of the OBS workflows like builds, build configuration (flags, attributes, prjconf etc.) and the OBS collaboration workflow are staying like they are.
?Should osc wrap some git commands to ease the transition, e.g. osc ci => git commit && git push ? Perhaps a bit more: osc branch
which would setup all relevant git repostiroies, git-lfs, etc. as required; osc sr
which could find the relevant parent project where to send the something like SR
- Please clarify what you mean with OBS collaboration workflow stays the same? That sounds like we would _never_ use git merge requests, but instead OBS submit requests? Perhaps use a concrete package from Factory as an example and point out where we would stop using git. - Jan Z
For whom do we solve that problem?
We first and foremost target packagers that help maintain our distributions. The most important people in that group are the people that maintain a huge amount of packages (power-users). The needs of distribution and maintenance managers are influencing the trade-offs in this workgroup.
How much work, do we estimate, this is roughly?
What alternatives do we have?
- Implement the âmissingâ version control functionality and broaden documentation of version control in OBS.
- Move most workflows into some SCM and use OBS only as build engine (https://etherpad.opensuse.org/p/alp-git-distro-goals))
Why now?
The Adaptable LInux Platform (ALP) project will likely lead to an increased need for product composition, so now is a good to time to make packagers life dealing with that better.
How will we measure success for this project?
- Contributors knowledgeable in general development tasks and git donât have to learn (a lot)/ anything new
- Common workflows should have the same or fewer steps than with current tooling for the pacakger
- Handle workflows via âbetter knownâ workflows (GitHub PRs, Gitlab MRs, GiteaâŚ.) rather an yet another tailored solution for OBS
What factors are critical to success?
- Good and complete transition from current situation to GIT repos
- Local builds need to be possible
- Support for all the multi-package (project) workflows we have
- devel projects, branch projects with more than one package, osc build âalternative-project
- (multi-action) submit requests
- staging