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

On Fri, Mar 06, 2026 at 08:27:24PM +0100, Daniel Engberg wrote:
> 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.
> 
> If you're intentionally introducing more regressions into the tree it's
> clearly not going to in the right direction.

I don't see how is that a regression, it looks more like portlint(1) is
not well aware of flavors and how can they affect knob ordering, perhaps
it should be fixed instead?

Don't get me wrong, I like helpers and find them useful, but not at the
cost of spreading the intention over several groups of loosely related
knobs vs. putting it all under two respective branches of one, single
conditional.

If you disagree I'd like to hear some technically sound arguments; links
and pointers alone won't cut it.

> Does that mean people can take over your ports whenever they feel like
> it?

No, it doesn't; and does not apply here: I de facto maintain this port
if you study commit history, and timeout on your PR should have hinted
you as well.

./danfe