Re: Is dist-git a good place for work?

[Vít Ondruch]

Dne 06. 05. 20 v 13:20 Fabio Valentini napsal(a):
> On Wed, May 6, 2020 at 10:37 AM Vít Ondruch  wrote:
> > Dne 05. 05. 20 v 18:37 Fabio Valentini napsal(a):
> > > On Mon, May 4, 2020 at 5:06 PM Tomas Tomecek  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