On Fri, May 6, 2022 at 3:51 PM Frantisek Lachman <flachman@xxxxxxxxxx> wrote: > > Hi Miro, > > that's a really valid point that we should somehow resolve. Is this always the case with the mass rebuilds that they should be left unbuilt or just with your Python rebuilds? > > I am thinking about multiple options here: > > 1) configurable allow-list / block list for committers (for the user and/or for the whole service) > * For our projects, we would allow just the `packit` user that we use for submitting the dist-git pull requests. > * We could probably react to just `packit` commits for all the users but I don't like this all-or-nothing approach. (That people are required to use all the Packit's features or none.) > > 2) check the committer for not being a proven packager (Packit is not a proven packager and we don't want to change that. We would like to have as few permissions as possible.) > * I don't see any technical problem with the implementation here and personally see this as a possible solution. > > 3) use a commit message to skip/trigger the build > * We can't inform everyone about this feature so skipping the build by commit command is probably not a good idea. > * And forcing the commit structure to trigger the build makes it hard to use. > > We can probably think about this more, but the second option looks the best for me so far. Automation is not reduced and work for proven packagers is untouched. What do you think? Would this work for you? Or, do you have any better idea/solution? The problem I see here is that it doesn't encompass many other situations, like commits by co-maintainers or members of groups that are maintainers of the package. For example, a non-provenpackager member of the @python-sig group who might work on the Python mass rebuild. Or a non-provenpackager co-maintainer needs to rebuild the package in a side tag for version bump X. Option 1) sounds much better to me. Because if the commit is done by packit, it is definitely safe to trigger the build. If the commit is not done by packit, you just cannot know if it's safe or not. Fabio _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
