On Fri, Sep 15, 2023 at 04:02:04PM +0200, Frantisek Lachman wrote: > Thanks Dan and Daniel for the responses. You both are right. For our > defence, this is always setup by an existing Fedora user (=human). > > I can't speak of rel-eng (and honestly don't know) how problematic > this "physical removal" on request is. > We can at least promote the licence check more > and provide instructions on what to do if something does not fulfil the rules. > (E.g. as a part of the issue Ankur created and mentioned > (https://github.com/packit/packit/issues/2035)) > > Does anyone have any realistic solution (or an improvement) to this > for Packit itself? > > We can also stop uploading the source to the lookaside cache (or make > it configurable), > but the benefit of such automation is significantly reduced. I think it isn't too hard to make it acceptable, just stick a flag in the middle of your process that human has to acknowledge eg: 1. Release monitoring files the new BZ ticket (it already includes wording warning the maintainer to review the new release for licensing changes). This BZ would have a flag set 'license-review=?' initially 2. Maintainer reviews the new tarball to check the license situation is all still golden. If OK, maintainer toggles flag to license-review=+, else toggles to license-review=- 3. Packit sees the flag approval and its magic happens to upload tarball and file pull request, etc If you wanted to be especially helpful, perhaps Packit could compare the old and new tarballs, and present the maintainer a list of newly added files as a BZ attachment. It could also run 'licensecheck -r' on old and new tarballs and report any notable changes. Still needs human review, but that might help nudge the maintainer to actually do the license review, as I bet it is often skipped on rebases. 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@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, report it: https://pagure.io/fedora-infrastructure/new_issue
