On Thu, Nov 5, 2020 at 3:44 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > Ben Cotton <bcotton@xxxxxxxxxx> writes: > > > > The spec file updates will be automated and changes will be pushed > > directly to dist-git once they are ready. > > -1. I think you should use pull requests for this, and continue to > believe that mass-pushing changes to dist-git is an abuse of > provenpackager. > While the individuals actively participating in this discussion are likely willing to deal with any changes as approved, and some wish to do it themselves in advance rather than having a bulk change applied to the packages they shepard, it is my belief that there are a lot of packagers that will welcome someone else doing the changes for them, especially when they have many packages, or are only an occasional packager that does not fully grok all the packaging infrastructure/artifacts and may not always pay close attention to these change proposals, and could easily be surprised if their package FTBFS at the next (mass) rebuild due to one of these types of changes. I don't know how to measure the "silent" majorities of packagers opinions/preferences that such change proposals should default to, but I certainly believe we should do what is preferred and easiest for the majority (and not for specific people), especially when the change impacts around a third of the packages out there. My gut tells me that automatically adding in the BR make to the package source, if not already there (giving those that wish to make the change themselves an opportunity to add it now) is going to be the best for the most, but I have no actual data to support that conclusion. And, for what it is worth, recent changes that impacted lots of packages (for F33, the cmake macro changes) resulted in updates by the change owners to packages so that the packagers could, should they choose, mostly ignore the change proposal and focus on other things. _______________________________________________ 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
