Re: git: 8bd89ab595cb - main - deskutils/qownnotes: the port had been updated to version 26.3.3
- Reply: Daniel Engberg : "Re: git: 8bd89ab595cb - main - deskutils/qownnotes: the port had been updated to version 26.3.3"
- In reply to: Daniel Engberg : "Re: git: 8bd89ab595cb - main - deskutils/qownnotes: the port had been updated to version 26.3.3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 06 Mar 2026 20:05:25 UTC
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