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