Dne 06. 05. 20 v 13:20 Fabio Valentini napsal(a): > On Wed, May 6, 2020 at 10:37 AM Vít Ondruch <vondr...@redhat.com> wrote: >> >> Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a): >>> On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek <ttome...@redhat.com> 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 :) > > Fabio
Thank you very much indeed! Vít _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
