openSUSE:ALP/Workgroups/Git-Packaging-Workflow/Minutes/20221111
- Agenda
- Overview on the goals
- Open Questions
- Task breakdown
- Identify missing components – what is missing to start working
- How to work together going forward #
Attendees
- Alberto Planas
- Adam Majer
- Dan Cermak
- Dirk Mueller
- Ludwig Nussel
- Alex Lau
- Dominique Leuenberger
- Richard Brown
- Gustavo Boiko
- Jiri Srain
- Stefan Weiberg
- Stephan Barth
- Bruno Leon #
Minutes
- Overview of the goals
- Develop packages for ALP in git
- Low the barrier entry for new developers: use the existing git ecosystem
- Non-goals (good to have) secure chain distribution
- Factory first is still the rule – the workflow will be validated first in a playground based on Factory, not on Factory itself
- Once it is validated, we will change
- Part of the goal is consolidate the set of tools into a minimum, dropping OSC in favor of GIT
- One identified problem: lack of a process to make decissions
- Primary focus: the packager! A good outcome can include that the release manager still use OBS / OSC
- The project config (for a release manager PoV) will benefict of being tracked in GIT
- Should it be maintained in a project specific git or alongside the packages (and package changes)
- If maintained separately, how do we link/synchronize package changes and projconf changes?
- AI: Adam + Alberto will make a proposal for next wednesday meeting about package+project workflow
- Measure of success (did we reach the goals)
- A packager can contribute without using OSC, only GIT
- The required knowledge for contribution are: GIT + general overview of development process
- Number of command / clicks should be similar or less than the current one (tricky, maybe discarded)
- New workflow not very different from the current one, or well known by developers (github pr, gitlab mr)
- Presented a model with a single pool of packages, where all the SR reach them. This somehow remove devel projects. The package maintainer needs to review / aprove the changes before merge
- Devel projects on OBS are usefult to define ownership, but also to group packages that belong together (KDE, GNOME), that can be tested together
- Is Maintenance workflow part of this goal? Better delegate it for later
- Privacy of changes / commits that belong to single customers can be done via different GIT repositories
- The package will have a “factory” branch, but “main” will be what OBS can use to build the package
- This is making factory some special, as the “factory” branch is also describing the product
- Once how to aggregate packages are solved, this will be used for ALP / SLE …
- Tasks that needs to be done
- [Mold from Ludwig is here for testing submodules and pbuild]
- Set a new playground in OBS. This playground will mirror the full workflow (commits, PR, bots, review process, openQA, etc). A small set of packages can be Ring-0, or a similar packages from ALP (so we can build the DVD for openQA)
- Implement the “grey” bubbles from the general draw, that contains the logic and bots that will drive the process.
- Setting a playground: In git for the pool + OBS for building (scm_sync); Ludwig Nussel + Dirk
- Package source
- Staging bots: Dan + Dominique + Richard
- openQA:
- Source && Legal review:
- Next meeting: Report progress next week at the same time (1/2hr)
- Setup kickoff / workshop with group in 2-3 weeks time for the 2nd goals (aka the dist-git-goals discussion)
- Communication to the community earlier than christmas