openSUSE:ALP/Workgroups/Git-Packaging-Workflow/WorkPackages/Submission-Workflows

Jump to: navigation, search

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?

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