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(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT