On Tue, May 05, 2020 at 09:42:22AM -0700, Adam Williamson wrote: > 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. IME that isn't really a huge problem. We maintain master libvirt spec upstream, and when a provenpackager has had to make a critical change in Fedora it wasn't really a burden on us. We've just synced the change upstream ourselves after the fact, and thereafter everything was fine again. The kind of changes that provenpackagers are doing are usually pretty simple and easily understood & resolved. Larger invasive changes (updating spec file to use new best practice for python macros last year was an example), are not things that are time critical. So in those cases it is more reasonable to require going to the master source-git repo. > 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. I think both those options would be more trouble than the problem they're trying to solve. As long as need for provenpackager emergency fixes is pretty infrequent, it is easier to just accept them making quick fixes to dist-git and sync back to source-git manually after the fact. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
