On Thu, Sep 26, 2019 at 2:32 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > Good Morning Everyone, Alright. I don't often reply to discussion threads like this, but here we go. > 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 This seems to be overkill. Especially merge conflicts when dealing with frequently-changing packages will make this impossible. > ○ Pull-requests are automatically tested If using Pull Requests is optional, I'm all for it. > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji I don't think this is wise. On the one hand, it will create even more workload in koji, and on the other hand, running "fedpkg build" for things I *actually* want to get built is no burden at all. Other steps in the process dominate. > ○ Every build in koji results automatically in an update in bodhi This might sound like a good idea, but it breaks down when I think about: - referencing RHBZs, - specifying update type, severity, reboot/logout, stable/unstable karma limits, etc., - mulit-package updates (this might involve buildroot overrides for stable releases). I don't think there's a way around manual update creation. > ○ Every update in bodhi is automatically tested Isn't this already the case? > ○ 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 Exactly. This is a big pain point in packaging, but it can be solved without changing everything else (and it might be even a prerequisite for other changes). > - We need to fine a place to insert the end-user information about an update (in > the PR description?) How do you want to do that for complex updates? Embedding YAML in the commit message? :D (That was a JOKE, please don't use yaml, it's terrible.) > - 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 Being able to use shared forks for collaboration sounds like a good idea, but again, this is an orthogonal problem. > - We need to figure out how to enable opening a pull-request again multiple > branches at one. Again, dealing with the changelog and package Release numbers somehow is a prerequisite to make this work for branches other than rawhide and N+1. > 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 for one like the clean correspondence of fedora branches <=> git branches. It makes working with packages that have different contents in different branches of fedora easy, and intuitive. Once the main source of conflicts between branches (mass rebuild etc. changelog messages and differing Release numbers) is fixed, PRs can automatically be created against multpile branches without issues. But, I also think hiding complexity within our tooling is a *bad idea*. There's too much *magic* hidden away already, and rpkg+fedpkg, python-fedora, bodhi-client, koji-client, etc. are piles of spaghetti code even *before* adding all this new stuff (I mean, things work remarkably well, but looking at the code makes me want to cry each time). Shoving even more functionality into these projects will make them *less maintainable*, not more. Just my 2¢ (or more). Fabio > 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-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
