On June 24, 2021 6:08:17 PM UTC, "Zbigniew Jędrzejewski-Szmek" <zbyszek@xxxxxxxxx> wrote: >On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote: >> On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok <mhroncok@xxxxxxxxxx> >wrote: >> > >> > On 24. 06. 21 11:16, Tomas Tomecek wrote: >> > > ## Choosing git forge to host source-git repositories >> > > We need to find a home for all the source-git repositories. This >is >> > > actually a really hard task because we have many options >(github.com, >> > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or >> > > on-premise) and different expectations: some projects already >have >> > > repos set up on different platforms while Pagure is the primary >forge >> > > now. Since the CPE team is investigating GitLab as a forge, it's >even >> > > harder for us to figure out the primary forge. We may end up >> > > supporting both actually: pagure.io and gitlab.com. What are your >> > > thoughts on this topic? Would you prefer pagure.io or gitlab.com >> > > More info: >> > > * https://pagure.io/fedora-source-git/sig/issue/1 >> > > * https://pagure.io/fedora-source-git/sig/issue/7 >> > >> > I would expect that since the soruce git is just an intermediate >thing, >> > supporting "any forge" is nice to have, but hard. I'd start with >some common >> > options (Pagure + 1 other) and see where you'll get. >> >> Yep, that's exactly what I'd like us to do. As soon as we have the >> service which accepts processes events up and running, it shouldn't >be >> that hard to teach it new fedora-messaging messages or webhook >> payloads. >> >> > > ## High-level workflow proposal up for review >> > > Hunor proposed a high-level workflow linked below and I strongly >> > > recommend reading it. We have also started discussing many >details in >> > > the process, such as getting archives: should we generate one >from the >> > > source-git repo or use the official release archive from >upstream? >> > >> > One thing to consider is that the upstream tarballs might be >cryptographically >> > signed and packages should verify the signature in %prep. >> >> This is a very good point - in such a case, we should always pull the >> official upstream tarball instead of generating a new one downstream. > >Hmm, but how would that work? I thought that the whole point of >source-git is to build from a commit that contains some upstream >version + downstream patches + downstream distro config like the spec >file, >and that the build step of applying downstream patches just doesn't >exist. >If you reuse the upstream tarball, then by necessity those downstream >patches need to be serialized and applied on top like in dist-git. So >you lose the property that the checkout from version control is *the* >source you build, but you also lose the property that the source you >build is what was signed (since patches are applied). But if the tooling automatically creates the "correct" srpm for you (e.g. either upstream tarball + patches or a git tarball), then I'd consider that a valuable improvement already. Sure, it might not be perfect, but it would help. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
