On 02/15/2018 03:08 AM, Panu Matilainen wrote: > On 02/14/2018 11:27 PM, David Cantrell wrote: >> 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. > > I can't believe what I'm seeing here. > > That old unused cruft hurts because old like Igor said, new people will > copy it over to new specs thinking this is some magic necessary > incantation (which is once was but no longer is). And no doubt some old > timers might not be aware that it's no longer needed and/or still add it > just out of habit, spreading the disease. Does it actually hurt or is it just unnecessary? Removing unnecessary things from spec files is fine with me, but I was not seeing this as actually breaking things at the moment. If BuildRoot lines have been in spec files for 10+ years and we are still building fine, is this really urgent or is it a nice to have? > At the same time people love to complain how much stupid boilerplate > stuff there is in every spec. Well hello, BuildRoot was made unnecessary > in rpm almost ten years ago, the packaging policy for Fedora already > updated accordingly many years ago, the last EL version requiring it > finally EOL'ed. And yet people have the nerve to complain when somebody > voluntarily cleans up this useless cryptic crap from their spec files! Not trying to speak for others here, but I have seen posts where package maintainers are annoyed by proven packager commits that touch a lot of packages. If we want the old timers to stop using unnecessary boilerplate, we should loop them in to that change. A pull request does exactly that. I get pull requests for spec cleanups from time to time and I appreciate it. The comment from the author usually explains why and sometimes even points to the current policy. This is great because otherwise I am not going to go and reread the policy for packages I have already created and currently maintain. Maybe we could also do re-reviews for packages that have existed for a long time and make sure they comply with current packaging policies? Another way to loop in the maintainers. Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
