On Fri, 2018-02-16 at 10:52 -0500, Neal Gompa wrote: > On Thu, Feb 15, 2018 at 11:19 AM, Jonathan Wakely > <jwakely@xxxxxxxxxxxxxxxxx> wrote: > > On 15/02/18 11:10 -0500, David Cantrell wrote: > > > > > > On 02/15/2018 11:02 AM, Jonathan Wakely wrote: > > > > > > > > On 15/02/18 08:46 -0500, David Cantrell wrote: > > > > > > > > > > First, I actually don't care if this change is made or not. My personal > > > > > opinion is that it's a nice-to-have cleanup that will probably not cause > > > > > problems, but you never know with that many packages. So that's why I > > > > > feel it should be approached using pull requests. We have that > > > > > functionality now thanks to Pagure, which is something we *never* had in > > > > > dist-cvs or the former git system. Is that tedious? Yeah, it is. But > > > > > pushing a change like that across many packages will not necessarily > > > > > explain to package maintainers why that was done. If packages have not > > > > > been cleaned up in that amount of time and things are still building, I > > > > > question the urgency of the change. Pull requests give package > > > > > maintainers an opportunity to be part of this change. Others have > > > > > pointed this out too. Otherwise things like this will likely continue > > > > > happening and package maintainers will overwhelming remain in the dark > > > > > about what changes should be made in spec files. > > > > > > > > > > > > What's the real benefit to getting each maintainer to remove the tag > > > > themselves via a pull request? After they get the pull request and > > > > understand the motivation they now know about something that should > > > > not be in their spec files. Is it really necessary for them to know a > > > > negative? Should they also remember a list of other tags that > > > > shouldn't be in there, or should we just remove the cruft, make sure > > > > the docs, examples and templates don't have those tags, and move on? > > > > > > > > Remaining in the dark about a tag that has no meaning doesn't seem > > > > harmful. > > > > > > > > > My thinking there is that the PR serves as a way to communicate this > > > change to package maintainers who have been copying existing spec files > > > and templates to make new packages. Concern was mentioned that package > > > maintainers keep using this tag when they don't need to, so the message > > > has not been received. I think a PR serves as a good way to communicate > > > that to maintainers. > > > > > > So remove it from all our specs and templates and let it be forgotten. > > > > People keep copying it from existing specs because nobody has done the > > work of removing all the existing uses before now. > > > > Once it's gone we can make rpmlint warn about it, so it doesn't keep > > coming back. > > > > As upstream for rpmlint, I do not believe anyone cares at all about > rpmlint in Fedora. One more warning or error won't mean anything. From > time to time, I have considered making a proper rpmlint policy for > Fedora, but I always decide not to because it's clear that that people > don't care about it and ignore it. I think this is more or less a chicken and egg problem - rpmlint output is currently so insanely bad and useless that most people indeed ignore it. So arguably if the output was better more people would likely use it. > > Until we can fail builds on rpmlint errors (as both Mageia and > openSUSE do), it's pointless to consider rpmlint as something that > ensures things stay clean and sane. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
