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
○ 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
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
- We need to fine a place to insert the end-user information about an update (in
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
group.
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.
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
entirely?
In an ideal world, what would packaging software look like to you?
Looking forward to the discussion,
Pierre
_______________________________________________
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
