On Thu, Sep 26, 2019 at 8:33 AM Pierre-Yves Chibon <pingou(a)pingoured.fr> 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..
In general, I like that people are thinking about this, but the
proposed workflow doesn't seem that great to me.
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
Yuck. This seems quite terrible to me. Pull requests are great for
collaboration, but they add extra steps to working with git that isn't
necessary during routine maintenance.
○ Pull-requests are automatically tested
○ Every commit to dist-git (ie: PR merged) is automatically built in koji
○ Every build in koji results automatically in an update in bodhi
○ Every update in bodhi is automatically tested
○ If the tests pass, the update is automatically pushed to the repository
These automated steps seem like they could be very problematic.
Updates in git can currently represent incremental progress. For
example, I might want to merge 5 PRs and then manually add a changelog
entry, before doing a build.
For this workflow to work nicely we need to fix a few things first:
- We need to work on the change logs in the spec files, as otherwise
pull-requests are going to conflict more often than not
With version-controlled package sources, changelogs in SPEC seem so
obsolete to me. They are already problematic today when they conflict
due to changes in multiple branches.
- We need to fine a place to insert the end-user information about an
the PR description?)
- When a group of people want to collectively work on a change (involving one or
more packages), they’ll need a place to collaborate. This could be someone’s
fork or, preferably, a fork of the project collectively maintained by that
For example: the python SIG would have a group with forks of the different
python packages they are working on
- We need to figure out how to enable opening a pull-request again multiple
branches at one.
That's not a good way to use git. This seems almost certainly likely
to result in cherry-pick'd branches. Git has excellent branch merging
features. Merging branches, rather than cherry-picking across them,
results in commits representing the same changeset being present in
multiple branches, making it easier to search git history and identify
which branches contain a specific change. Multiple PRs or
cherry-picked commits make this harder, and more likely to result in
regressions in some branches.
A better way to use git would be to patch the oldest version you
intend to patch, and merge that branch forward into newer branches,
merging any conflicts along the way. This will help avoid regressions
(if all changes are merged) and will make it easier to see which
branches contain a particular commit. Though, some people don't like
seeing merge commits.
Why should we agree now on a long term vision?
A concrete example to this, I have been playing with the idea to get ride of git
branches in dist-git for a while now. Basically use git as it is meant to be
used: have one branch for development (most often master) and branch of master
when you need to, not simply because a new version of Fedora happened.
However, if we implemented this, we would break the workflow described above as
suddenly there would be no way to specify that a given PR is meant to land in a
certain version of Fedora or another (Is this PR for rawhide? F31? F30? All of
them? Some of them?).
Having this idea of where we want to go should give us a goal as well as way to
reflect if changes we think are good in isolation would actually help achieving
this vision or not.
This proposal was based on the brainstorming session a few of us had at flock,
but before we can see how to implement it we need more inputs and this is where
you come in :)
Do you like this vision? Would you change some pieces of it? Would you change it
In an ideal world, what would packaging software look like to you?
I just don't see this proposed workflow as solving the biggest
problems that packagers face. For me, I think the biggest problem that
packagers (particularly newer packagers) face is discovery of all the
services involved in the packaging workflow, and the need to visit
separate UIs to get answers.
Rather than try to automate the workflow through these separate
services, I'd rather work be done to create a central packager
interface that helps packagers track where a package is in the
workflow, and to facilitate moving from one phase to the next. For
example, an interface could show something like a list of branches for
a package, and whether there is a corresponding build from those
branches. A button to the right of each branch could be shown which
does the equivalent of `fedpkg build` on that branch (grayed out if
there exists a build already for that commit and branch), and then
another column with a similar button to create an update.
In addition to helping the packager move a package through the
workflow, such a centralized interface would also provide information
about dependencies, their orphan/retired status, whether they've
changed since the last build. It could also show a listing of bug
reports, help maintain co-maintainer privileges, and other similar
stuff. Basically, everything the packager needs in one place.
I think such an interface would be far more useful, just to document
the existing workflow, and help packagers know what to do, than trying
to change the workflow and automate it. We shouldn't be looking at
disruptive changes to the workflow... we should be looking at lowering
the bar to packaging by making it easier to manage the current
workflow. And then, if we find that there are changes to the workflow
itself, we do that later, with corresponding changes to the
> Looking forward to the discussion,
> devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: