On Thu, 2019-09-26 at 16:24 +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). If we want to generate tarballs, we need to think about translations as well. While some projects do have translations as part of their source code repository, others currently pull them in at tarball build time. This would have to be accounted for or otherwise the resulting tarball would miss the translations. > > 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? > - 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. > - 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? > > > Thanks for your inputs! > > 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 _______________________________________________ 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
