On Thu, Sep 26, 2019 at 8:33 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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 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. 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 > entirely? > 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 centralized interface. > > Looking forward to the discussion, > > Pierre > _______________________________________________ > devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-announce-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-announce@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ 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
