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@xxxxxxxxxx> 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_maintenance_and_canonicity 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 _______________________________________________ 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
