On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote:
Good Morning Everyone,
At Flock, a few of us met to discuss a future vision of the packager workflow. This discussion was triggered by the realization that a number of initiatives are happening around packaging in Fedora but there is no real shared vision on what we want the packager UX/workflow to be. The lack of vision on the packager workflow means we could deploy something today, thinking it is the improvement over the current workflow but would prevent us from (or make it harder to) doing other changes afterwords that would be even more beneficial..
So once that concern was raised, we took some time during the Fedora Infrastructure hackfest to gather the people interested around a white board and brainstorm on what a future packager workflow could look like.
We tried not to link this process to any tool in particular as well as focus on the what and why rather than any how.
Here is what the vision we came to and that we would like to discuss:
○ Every changes to dist-git is done via pull-requests
Allow pull requests, but don't force them upon me. There are plenty of times I want to do things via the CLI. Also, I'd only be interested in using pull requests more if it was in something like GitLab because the Pagure workflow/developer experience is too painful to bother with.
○ Pull-requests are automatically tested
Sounds fine to me (GitLab's CI pipeline is pretty sweet).
○ Every commit to dist-git (ie: PR merged) is automatically built in koji ○ Every build in koji results automatically in an update in bodhi
The combination of these two makes no sense to me. I do plenty of work where I don't want to build it (specfile cleanup, patches, configuration changes, etc.). I want a build that goes to users be explicit.
A better model, in my opinion, is to build every *tag*. To do a new kernel build I could make a tag like "kernel-5.4-rc1..." and the tag would be parsed into the specfile's NVR and built.
Do you like this vision? Would you change some pieces of it? Would you change it entirely? In an ideal world, what would packaging software look like to you?
Ideally? Working with specfiles and dist-git for patching and updating is unpleasant. I want to work from the source tree of the repository and use git to manage additional patching. Ideally I'd have a packaging repository with the upstream as a git remote and my update process is git-pull with git-rebase/git-cherrypick for patches. I don't ever want to deal with dist-git in my work.
We're playing with a workflow like this for the kernel and so far I much prefer it.
- Jeremy