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 > ○ 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 There was a pretty nice proposal during Flock from ngoma and ignatenkobrain (https://flock2019.sched.com/event/SH8l/improving-packaging-experience-with-automation). In particular, the rpm release bump would be done automatically. If we also agree to autogenerate %changelog from git commit descriptions, we would avoid most conflicts. > - We need to fine a place to insert the end-user information about an update (in > the PR description?) Why not in the description of individual commits? PRs are a volatile thing. Each commit is supposed to describe a single logical change, so we could agree that the commit message automatically becomes part of the changelog and the bodhi update description. We'd also need a way to say that some commits don't bring not-user visible changes. Some kind of marker in the commit message text should work for this. > - 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?). I don't think this is the right approach. If we rearrange things so that conflicts are not a big issue (occasional conflicts will always happen with branches, but let's say that it is the exception, not the rule), then branching is cheap and we can still use dist-git in current form. Git *is* meant to be used with branches. Right now, many (most?) packages have different content in different branches. Package versions and update guidelines and changes to packaging make this almost unavoidable. The only option to make things work without branches would be to require lots of conditionals (which is not a nice option for packagers, and generally conflicts with automatization). Also, it should be possible for the new process to coexist with existing practices to avoid a flag day. For some packages, possibly indefinitely. Also, restricting ourselves to a single branch (and a single PR) would mean a loss of flexibility. Consider the following scenario: a new point update comes out for a package. It is a bugfix release, and we want to push it to all stable branches that currently have the same version. But for one branch the test fail, because one of the dependencies is too old. If we have multiple PRs, this is not a big issue: we might decide to push the update to some branches, but not others. > 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? This proposal doesn't talk at all about the earlier part: how to automatize the full process from upstream release to bodhi update. The packit project tries to solve some of that, but by piling up solutions on top of existing services. If our own infra was made more flexible and more automatic, then I think we could build much better process to make the whole packaging process from upstream to end user automatic. My vision is that (for projects which are sufficiently mature and trusted to merit this), I can click a checkbox that means: when upstream release happens, open PR in dist-git, when that PR passes gating, merge it, then create bodhi update, when that release passes QA requirements, push update to stable. anitya/upstream-release-monitoring already does the detection of the upstream projects. Your proposal would solve the step between koji and bodhi. Gating is slowly happening. The last step is now also automatic, and updates are pushed based on time. The part that would open a PR for dist-git and merge it if checks pass is still completely missing afaik. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
