On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé <berra...@redhat.com> wrote: > IMHO all changes should be opened as merge requests in pagure. This gives > the regular package maintainers a window of opportunity to review the > change before it is merged. If there's no response from the package > maintainer after a couple of weeks then a proven packager can go ahead > and approve the merge request.
Well said. I'd advise to create PR - wait week or 2, if left without response - create BZ for the specific PR as not everyone watches PRs and PR notifications, and wait week or two, if left without response - send a direct mail to the package maintainer. But having at least the PR and a useful commit message would be much appreciated. > At the same time I think it is good to remember that Fedora package > maintainers should think of themselves as guardians, not owners, and > thus should expect to receive contributions from others, including > provenpackagers, doing cleanups to follow Fedora guidelines better. In the case of Fedora, for any part of the project - we should expect to receive contributions. I'd also level up and say, we all should encourage contributions to any part of Fedora. Every maintainer may be in for a different goal, so it may not be applicable to everyone, but I like the parable to maintainer being more of a guardian. Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote: > > [snip] > > > Granted, these are dissimilar to initial Michaels's issue. But how can I be > > sure that if I touch some of the packages, I won't be told that they were in > > such state for purpose? > > IMHO all changes should be opened as merge requests in pagure. This gives > the regular package maintainers a window of opportunity to review the > change before it is merged. If there's no response from the package > maintainer after a couple of weeks then a proven packager can go ahead > and approve the merge request. > > Essentially proven packagers can follow the same workflow as anyone else > does for contributing to a package that they are not a (co)maintainer of. > They just need the extra priv of being able to approve their own MR at > their discretion. Pushing directly to git, bypassing merge requests, > should not be required in order to achieve what provenpackagers exist > to do. > > At the same time I think it is good to remember that Fedora package > maintainers should think of themselves as guardians, not owners, and > thus should expect to receive contributions from others, including > provenpackagers, doing cleanups to follow Fedora guidelines better. > > With 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
