On Wed, Jan 03, 2018 at 05:33:38PM +0100, Tomasz Kłoczko wrote: > On 3 January 2018 at 17:09, Igor Gnatenko > <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > [..] > > First thing you should do is to open a ticket for FPC[0] in order to fix > > guidelines. > > > > Once it is approved by FPC, I can help you dealing with this as a proven > > packager since it is trivial enough. Count me in too, I'd be happy to help. > Done https://pagure.io/packaging-committee/issue/736 Once the guidelines are removed, I think the optimum way is to a) generate patches for all 1300 packages b) post them publicly c) allow the public-at-large and a few committed people to review them d) after a week of delay use pp powers (you now have at least two volunteers, so this shouldn't be an issue) to push those changes directly to distgit e) rebuild select packages (maybe one hundred, to test for any regressions). Why not rebuild all packages? This is a trivial change, and a mass rebuild is coming up anyway, so there doesn't seem to be a need to rebuild everything twice. Why not post PRs? 1300 PRs will be a pain to manage. It'll also put a big strain on pagure. I think PRs should be reserved for stuff that we _want_ people to review individually, not for mass changes like this. As to the specific way to implement point a): either the tools mentioned by Charalampos or Neal, or maybe even a simple 'sed -i' + 'rpmdev-bumpspec' would work. I expect that the only way that doesn't require too much thinking or time is to identify the few common patterns that are used to call gtk-update-icon-cache and turn them verbatim into a huge search&replace invocation. This should work for 99% of packages, and the remaining ones can be done by hand. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
