On Thu, Jun 24, 2021 at 8:09 PM 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). What you just described I understand as an (upstream) maintenance branch and is not what we call source-git. Our definition of source-git is: * upstream release tarball * downstream code changes applied as patches during %prep * additional configs for sake of building and testing It's not that one workflow is better than the other: teams tend to pick one and use it to maintain their project based on their preference and ease of use. I hope we'd be able to support both workflows but right now we focus on the source-git part. HTH, Tomas _______________________________________________ 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
