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. 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
