Vít Ondruch <vondruch@xxxxxxxxxx> writes: > Dne 06. 05. 20 v 20:39 clime napsal(a): >> On Wed, 6 May 2020 at 13:21, Fabio Valentini <decathorpe@xxxxxxxxx> wrote: >>> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: >>>> >>>> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a): >>>>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek <ttomecek@xxxxxxxxxx> wrote: >>>>> >>>>> Hi Tomas, >>>>> >>>>> I'll respond below with some of my experiences and opinions ... >>>>> >>>>>> Let’s talk about dist-git, as a place where we work. For us, >>>>>> packagers, it’s a well-known place. Yet for newcomers, it may take a >>>>>> while to learn all the details. Even though we operate with projects >>>>>> in a dist-git repository, the layout doesn’t resemble the respective >>>>>> upstream project. >>>>>> >>>>>> There is a multitude of tasks we tend to perform in a dist-git repo: >>>>>> * Bumping a release field for sake of a rebuild. >>>>>> * Updating to the latest upstream release. >>>>>> * Resolving CVEs. >>>>>> * Fixing bugs by… >>>>>> * Changing a spec file. >>>>>> * Pulling a commit from upstream. >>>>>> * Or even backporting a commit. >>>>>> * And more... >>>>>> >>>>>> For some tasks, the workflow is just fine and pretty straightforward. >>>>>> But for the other, it’s very gruesome - the moment you need to touch >>>>>> patch files, the horror comes in. The fact that we operate with patch >>>>>> files, in a git repository, is just mind-boggling to me. >>>>>> >>>>>> Luckily, we have tooling which supports the repository layout - >>>>>> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can >>>>>> easily inspect the source tree or make sure your local change builds. >>>>>> >>>>>> Where am I getting with this? >>>>>> >>>>>> Over the years there have been multiple tools created to improve the >>>>>> development experience: >>>>>> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g. >>>>>> the way Fedora kernel developers work on kernel [k]). >>>>> (snip) >>>>> >>>>>> In the packit project, we work in source-git repositories. These are >>>>>> pretty much upstream repositories combined with Fedora downstream >>>>>> packaging files. An example: I recently added a project called nyancat >>>>>> [n] to Fedora. I have worked [w] on packaging the project in the >>>>>> GitHub repo and then just pushed the changes to dist-git using packit >>>>>> tooling. These source-git repositories can live anywhere: we have >>>>>> support for GitHub right now and are working on supporting pagure. >>>>>> >>>>>> Would there be an interest within the community, as opt-in, to have >>>>>> such source-git repositories created for respective dist-git >>>>>> repositories? The idea is that you would work in the source-git repo >>>>>> and then let packit handle synchronization with a respective dist-git >>>>>> repo. Our aim is to provide the contribution experience you have in >>>>>> GitHub when working on your packages. Dist-git would still be the >>>>>> authoritative source and a place where official builds are done - the >>>>>> source-git repo would work as a way to collaborate. We also don’t have >>>>>> plans right now to integrate packit into fedpkg. >>>>> So, in my experience, source-git might be a workable solution for >>>>> packages with *big* downstream modifications. However, for everything >>>>> else, I think it's a way to make it easy to accrue technical debt and >>>>> to do cargo-culting with downstream patches. >>>>> >>>>> The vast majority of packages has *no patches* (or at most, one or two >>>>> of them) >>> (snip) >>> >>>> I don't really want to argue with this point, I tend to agree. Just out >>>> of interest, do we have some statistics to support this? O:-) >>> I did not have any stats when I wrote this, but now I do. >>> Parsing the rawhide spec files from [0] for lines matching >>> "^Patch[0-9]*:[ \t]*.*$", I get the following distribution: >>> >>> number of patches: number of packages >>> total: 21970 >>> 0: 15638 >>> 1: 3287 >>> 2: 1232 >>> 3: 598 >>> 4: 325 >>> 5: 221 >>> 6: 154 >>> 7: 97 >>> 8: 83 >>> 9: 57 >>> 10: 41 >>> 11: 27 >>> 12: 26 >>> 13: 25 >>> 14: 13 >>> 15: 13 >>> 16: 14 >>> 17: 15 >>> 18: 5 >>> 19: 8 >>> 20: 2 >>> 21: 11 >>> 22: 2 >>> 23: 4 >>> 24: 4 >>> 25: 5 >>> 26: 3 >>> 27: 4 >>> 28: 5 >>> 29: 5 >>> 30: 2 >>> 31: 6 >>> 32: 4 >>> 33: 3 >>> 34: 1 >>> 35: 4 >>> 37: 2 >>> 38: 1 >>> 41: 1 >>> 42: 2 >>> 46: 1 >>> 47: 1 >>> 48: 3 >>> 49: 1 >>> 50: 2 >>> 51: 1 >>> 53: 1 >>> 54: 1 >>> 66: 1 >>> 68: 1 >>> 71: 1 >>> 75: 1 >>> 78: 1 >>> 79: 1 >>> 85: 1 >>> 127: 1 >>> 170: 1 >>> >>> In relative terms: >>> >>> - 71% of packages have ZERO patches >>> - 15% have ONE patch >>> - 5% have TWO patches >>> - 3% have THREE patches >>> - 5% have MORE than THREE patches >>> >>> Most packages have none (71%) - or at most two - patches (91%, my >>> original "guess" for "vast majority"), some have 3-5 patches (5%), and >>> a minority (4%) has six patches or more. So it seems this backs up my >>> claim :) >> These are some great stats! >> >> But I would like to note that exploded repos (or source-git repos) >> have at least two other advantages. >> >> 1) they consume less space than tarballs for each version because >> objects in git repo are deduplicated >> 2) instead of downloading/uploading tarballs, you can just do >> something like: git pull --rebase upstream master; git push > > > You still need to have tarballs for SRPM. Therefore the exploded > sources actually consumes more space, because you still have tarballs > and on top of that you have git repo. That's the case now, but doesn't have to be the case. We could decompress and dedup if we wanted, but it's not worth the effort to do that. Like many things, it's down to how much effort it's wroth. Thanks, --Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
