On 3 January 2018 at 18:16, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: [..] >> 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). Thank you drafting next steps which needs to be done. Will try to follow. > 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. Totally agree. Maybe it was not obvious but my original though was introduce it using as simple way as it is only possible then after commit imminently push all fixed packages to rebuild to confirm that none of those changes (which many will be introduced more or less by manual modifications) are affection at least correct build of those packages on official builders. This could minimize number of possible mistakes. [..] > 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. I think that it it will be closer to 90% :) Nevertheless I think that whole set of +1300 specs could be divided in some batches in which first will go specs which can be corrected using exact text substitution then in next steps all specs which needs to be treated individually. Just one more clarification that all those changes should start when FPG will be updated and in %changelog should used the same text pointing to new FPG rule or pagure ticket. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
