On Tue, May 5, 2020 at 11:43 AM Adam Williamson
On Tue, 2020-05-05 at 17:45 +0200, Tomas Tomecek wrote:
> On Tue, May 5, 2020 at 1:41 PM Petr Pisar <ppisar(a)redhat.com> wrote:
> > On Tue, May 05, 2020 at 12:41:06PM +0200, Tomas Tomecek wrote:
> > > Petr, I should have probably stressed that our target is Fedora (or
> > > even all Red Hat operating systems). Yes, there are hundreds of
> > > distributions and we cannot solve their problems. We are open for
> > > collaboration though - we cannot drive changes in distributions which
> > > we don't know or use.
> > >
> > If you only target Fedora, then it means that the same amount of Fedora
> > maintainers will maintain twofold amount of repositories. Does it indeed save
> > work? What's the benefit of maintaining more repositories?
> My personal expectation here would be that if I enabled source-git for
> my packages, I wouldn't want to touch dist-git and only work in the
> source-git repos. Yes, there would still be changes coming to
> dist-git, and I'd inspect those from source-git. I'd even ask
> contributors to use source-git for PR contributions if possible.
To give a provenpackager perspective on this - it rarely turns out to
be possible. Usually when we need to touch someone else's package, it's
to deal with an urgent problem - say an unannounced soname bump that
requires a bunch of packages to be rebuilt, a bug preventing a nightly
compose from running or causing a serious problem in it, something like
In those situations we usually want to fix the problem *now*, not
"whenever someone has time to review the 'upstream' PR and merge it and
do whatever they have to do to trigger a build 'downstream'".
So when I'm trying to fix an urgent issue in a package that tries to
keep its spec file elsewhere, I usually just fix it in dist-git and
issue apologies later. I don't see a way this is ever going to not be
the case unless you give all provenpackagers commit rights to the
'upstream' repo, or have a completely automated PR merging system that
also triggers a downstream build, or something like that.
With the model that the kernel has switched to, this would technically
still work. Of course by default, if we didn't pay attention, the next
time we do a build it would literally overwrite anything you changed.
I expect it is going to be a learning process to get the few people
who do actually commit to the kernel to work within the new model, but
in the meantime we can work with them to make sure that nothing gets
lost. Of course this works better with the fact that there is someone
dedicated full time to maintaining the kernel package, and might not
work so well with other things packages.
Ideally, at some point, dist-git just gets replaced with src-git as
the mechanism for package maintenance.