Dne 05. 05. 20 v 18:42 Adam Williamson napsal(a):
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
that.
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.
On this place, I would like to remind this guideline:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintena...
And I don't think this is in place just due to one off fixes as Adam
mentioned, but because of mass cleanup of Fedora .spec files. In recent
history, I remember removal of %clean sections, Group tags and removing
the scriptlets.
Vít