On Wed, Jun 30, 2021 at 08:11:38AM -0500, Justin Forbes wrote: > On Wed, Jun 30, 2021 at 3:40 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Tue, Jun 29, 2021 at 03:13:10PM +0200, Tomas Tomecek wrote: > > > 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. > > > > It's an "upstream maintenance branch" PLUS the .spec bits that specify > > how to build a package. > > > > > 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 > > > > But that describes dist-git *exactly*. Where is the difference? > > > > In the spirit of openness that Fedora is based upon, it must be very > easy to determine what patches we carry as opposed to upstream, and > exactly how we build things. I very much agree with this. > This does not go away even if we get to > the point where dist-git no longer exists, and we can build directly > from source-git. In the meantime, dist-git is the "canonical source > of truth" for fedora packages, so there is a middle step to convert > from source-git to dist-git. With both, the difference in using > source-git means there is an exploded tree there, with patches > applied. This makes debug and development much easier. There is also > git history, which hopefully contains a lot more background than > currently exists in dist-git. Finally, it makes bisecting a much more > simple process, whether the offending patch is in upstream or > downstream changes. [See my long reply to the parent message...] The difference between current source-git proposal and what I describe is that we skip the step where commits are serialized as patches. But this makes it *easier* to see what changed: instead of dealing with text diffs, we can use tools like gitk, gitg, git log filters, etc. All the changes are still there, and we can view them as any other git commit. The approach with serialized patches does have one advantage: - we can use source-git as a front-end to dist-git and dist-git still looks like before. But we pay a heavy price for this (see the other message): - non-trivial histories are not supported - maintainers must do busywork with patch rebases - we rewrite git history all the time And I think this effort is wasted: if a project uses source-git as a front-end to dist-git, people will preferably look at the source-git history anyway. So it's OK if the dist-git history doesn't contain the details of patches. This is no different from upstream git history: I will use an upstream tarball to build, but will use the real upstream repo for history and bisections. Zbyszek _______________________________________________ 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
