On 02/14/2018 02:41 PM, Igor Gnatenko wrote: > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote: >> On 02/14/2018 11:44 AM, Remi Collet wrote: >>> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit : >>>> Just a small heads up, ... >>> >>> >>> As I said on IRC >>> >>> - waste of time >>> - waste of energy >>> - absolutely no value >>> >>> And >>> >>> - abuse proven packager privileges > >> +1 > > Ralf, Remi, David, > > Please, read policy[0] once more. > >> Sometimes there are situations where it's simply a lot easier to fix stuff > directly in Git than via bugzilla and the proper maintainers. So much easier > that we should leave this path open. These situations shouldn't arise that > often. Some examples of situations were bypassing the proper maintained is > considered fine: >> […] >> * small fixes or adjustments for new or modified packaging > guidelines can be done directly in Git after being announced some days > in advance. > > I just missed waiting for few days (kinda intentionally), because it would not > help anyone and will just disturb maintainers to do the actual work whereas it > doesn't make any sense because cleanup is automated. > > > [0] https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino > r.2C_general_or_cleanup_changes > I am not disputing the policy. I feel this change is pointless and is a lot of commits for no real benefit. They are not fixes. You're just scrubbing spec files that are not broken. Who cares? Update the packaging policy and be done with it. Leaving this tag there hurts nothing. It's also worth noting that Pagure gives us pull requests for these sort of changes. While a proven packager can drive a monster truck through the package repositories unchecked, the nice thing to do in the community is to bring the issue to the attention of the package maintainer and let them handle it. Pagure lets you send pull requests for this (you can even automate it) and then leave it with the package maintainer to take or ignore on their own. Just because we have removed something like the BuildRoot tag from the packaging policy does not automatically invalidate every existing spec file. -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
