On 15/02/18 08:52 -0500, David Cantrell wrote:
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?
If it's not urgent does that mean it shouldn't happen? If not now, when? Is March non-urgent change month? Is another 10 years the right time? Personally I think right before a mass rebuild is a good time to do such things, because we're re-verifying everything builds. Until every package is in Koschei we have a big problem with packages bitrotting and FTBFS going unnoticed for months.
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.
Somebody who maintains 10 packages might get 10 pull requests, but you only need to loop them in once. Email does it once. If a maintainer doesn't care why it was done, they don't even need to read the email. "Oh, somebody removed a line from the spec, but it still builds ... I guess they knew what they were doing."
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?
Do we have the resources to do that? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
