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. > Three questions though: > - What about the upstream projects that still only publish a tarball at release? > Should the packager explode that tarball into a git repo? > Do we keep the current way of uploading the tarball? I guess I answered that already. > - Won't this make pull-request for new update harder? Suddenly you have the diff > of both all of the upstream changes as well as the spec file and potential > patches. > In most cases the spec file and the patches is what will matter but for large > code-base the diff could be quite significant then. By "new update", I presume you mean rebasing to new upstream version. Currently with my separate git repo/branch, I would just force push the branch overwriting old history, but obviously that's no desirable for Fedora's historical record. It would make more sense to create a new branch when switching to the new upstream release, as again this is what upstream would do when maintaining stable branches for multiple releases. > - 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
