On Thu, Sep 26, 2019 at 03:33:11PM +0100, Daniel P. Berrangé wrote: > On Thu, Sep 26, 2019 at 04:24:29PM +0200, Pierre-Yves Chibon wrote: > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote: > > > 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 packages I maintain, my preference is to touch dist-git as little > > > as possible. Ideally I would never touch dist-git at all & rather wish > > > it didn't exist at all in its current form of spec+patchfiles. > > > > > > Instead I prefer a clone of the master upstream git repo and maintain a > > > branch with patches cherry-picked into it. This is used to auto-generate > > > patches for the Fedora RPM, at the same time updating the patch file list > > > in the RPM spec. The only manual step is adding the changelog entry & > > > bumping release number. > > > > > > The ideas above around associating CI with pull requests make a lot of > > > conceptual sense & align with modern github/gitlab software development > > > best practices followed by non-distro software upstreams. Automatically > > > triggering builds from merged PRs similarly makes sense, especially > > > if that can automate bumping spec release number & adding a changelog > > > entry based on the pull request subject. > > > > > > > > > Obviously I can still use my upstream git repo branch and change the > > > scripts to generate a pull request to dist-git instead. The downside > > > is if the PR fails, I now how to rebase my real git repo & re-submit > > > and new PR. > > > > > > So if we're talking "ideal" long term vision though, I'd rather eliminate > > > the dist-git repo intermediate step as IMHO it adds no value, only complexity > > > for the sake of historical compat with the way Red Hat distros has worked > > > dating back years. Its time to say goodbye to this historical way as the > > > world has moved on since this spec+patches approach was invented in the > > > days of CVS source control. > > > > > > Allow packagers to have a clone of the upstraem git repo, and use the > > > pull-requests and run Fedora CI testing against the Fedora branch of > > > the upstream repo instead of against dist-git. > > > > > > In this way, maintaining packages in Fedora would be functionally identical > > > to how an upstream project maintains their own stable branches. The only > > > Fedora difference would be that the branch would need to include the RPM > > > spec file in some well defined place. > > > > I like this. > > It means that the build-system would have to generate the tarball of the source > > and put it into dist-git at srpm-build time (I believe we still want to store a > > copy of the sources used for a build). > > It doesn't have to generate a tarball. There's still the option of using the > lookaside cache to acquire the tarball as today. I don't mind the lookaside > cache since its rarely touched, doesn't cause inconvenience in the same way > patches in dist-git do. I had in mind generating the tarball as a way to make sure the sources don't disappear and we are able to reproduce the builds > > - Do you have in mind that the copy/fork of upstream would be in our dist-git or > > in other places on the internet? If the later, how would you recommend > > contributors to find it? > > Ideally I think Fedora would have a git server than host the Fedora > branches, as it is nice to have a single point of reference for all > Fedora additions. It could even be the current dist-git server, just > with the upstream repo mirrored into it, instead of our current patches+ > spec approach. If the mirrored repo are somewhere that is somewhat under Fedora's control it solves the tarball question from above since in this case we can make sure that the git repo or a commit in it doesn't disappear suddenly solving the reproducibility question. Pierre _______________________________________________ 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
