Re: git: 8bd89ab595cb - main - deskutils/qownnotes: the port had been updated to version 26.3.3

On 2026-03-06 21:05, Joseph Mingrone wrote:
> On Fri, 2026-03-06 at 20:41, Daniel Engberg <diizzy@FreeBSD.org> wrote:
> 
>> On 2026-03-06 20:36, Robert Clausecker wrote:
>>> Hi Daniel,
>>> Am Fri, Mar 06, 2026 at 08:27:24PM +0100 schrieb Daniel Engberg:
>>>> On 2026-03-06 19:30, Alexey Dokuchaev wrote:
>>>>> On Fri, Mar 06, 2026 at 05:50:56PM +0100, Daniel Engberg wrote:
>>>>>> On 2026-03-06 08:05, Alexey Dokuchaev wrote:
>>>>>>> commit 8bd89ab595cb9f03ab29068b1a0c08795d438781
> 
>>>>>>>     deskutils/qownnotes: the port had been updated to version 26.3.3
>>>>>>>     Reduce vertical space to help Makefile maintainability by merging
>>>>>>>     sporadic use of helpers and two per-flavor conditionals into one;
>>>>>>>     drop needless default flavor assignment.
> 
>>>>>> You've now introduced more regressions (check portlint) and review
>>>>>> https://docs.freebsd.org/en/books/porters-handbook/book/#flavors-using .
>>>>>> Please fix your commit or back it out.
> 
>>>>> There's nothing to fix, it looks exactly how I want it to look without
>>>>> impeding future updates which I've been doing for past five years, as
>>>>> de jure maintainer is inactive.  I believe I've provided sufficient
>>>>> explanation in the commit log why I dislike scattering stuff belonging
>>>>> to one flavor around several places.
> 
>>>>> I appreciate your attention to detail, but rigorously obeying lint tools
>>>>> and general guidelines when they pessimize things more than do any good
>>>>> is bad engineering practice.
> 
>>>>> ./danfe
> 
>>>> If you're intentionally introducing more regressions into the tree it's
>>>> clearly not going to in the right direction. Does that mean people can take
>>>> over your ports whenever they feel like it?
>>> Please remember that portlint warnings are warnings and not errors for
>>> a reason.  What portlint recommends is more of a guideline than a hard
>>> and fast rule, and committers can decide to go against these recommendations
>>> if they believe that to be a reasonable choice.
>>> Please stop badgering committers for violations of rules you have made up.
>>> Adding a change that introduces a portlint warning is not a regression.
>>> Yours,
>>> Robert Clausecker
> 
>> You've been wrong on multiple occasions so please read up instead of jumping in just for the sake of it. You've already made it quite clear on about your standards. It clearly diverges from Porters Handbook AND introduces regressions.
> 
> What exactly is a regression in this case?  If you're demanding that
> someone else's work be backed out, please provide specific examples.
> 
> I tend to prefer standardized formatting since it makes automating large
> changes easier, but I agree with others that these are guidelines and
> shouldn't be treated as rules set in stone.  If this is just a
> formatting change and the person effectively maintaining the port is
> more comfortable with the current layout, why is it such a problem?
> 
> Joe

Agreed, standardized formatting helps a lot and streamlines the effort 
for everyone which is why we have these guidelines are used train people 
to be aware of and actually apply them. They're not set in stone because 
sometimes it may simply break the port however one could argue that 
you're likely doing something wrong in the first please leading up to it 
but that's besides the point in this case. However when you deliberately 
go out your way and break it which both Porters Handbook and tools tells 
you is wrong and ignore it cases issues for everyone in the long run and 
organizational if everyone starts doing their own thing. Submit PRs to 
Porters Handbook if you have an idea that you might think will improve 
things so everyone is using the same "template" otherwise why do we even 
have Porters Handbook and bother training people by referring to it?

Best regards,
Daniel