9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font
Date: Sat, 11 May 2024 10:00:57 -0500	[thread overview]
Message-ID: <10658a6d-38bc-4b49-bc13-c42cc0113034@posixcafe.org> (raw)
In-Reply-To: <E34884BCF95C6780D14FF9080661214F@smtp.pobox.com>

On 5/10/24 23:31, Romano wrote:
> I looked back over my replies and I couldn't see where I was pushing
> for inclusion.  I thanked you for your feedback to begin with.  I
> wasn't rejecting your review but I wanted to understand some of your
> feedback better.  I understood what you were saying in regards to it
> not being accepted.
> 
> But based on your last response I think you didn't understand what I
> was saying, or rather the context in which I was saying what I was
> saying.  Perhaps when I wrote, "But I think this is a start, and
> makes things more bearable at least for me." you took that as me
> pushing for inclusion?  Or in my last reply re: not letting the
> perfect be the enemy of the good?  In my responses, I was explaining
> how it was useful for me, and of course that's anecdotal: patches
> often are.  I thought my question before my "more bearable " comment
> re: just the scrollbars and my followup questions after (all in the
> same email) would make it clear I wasn't pushing for inclusion. But
> that didn't mean that I thought the discussion was over regarding
> different paths forward. Your last response made it clear to me that
> you (and perhaps others) thought I was pushing for inclusion. Sorry
> about that.


Yes the "its a start" and other phrases that read as excuses about
the state of code read as an argument for inclusion. I get quite frustrated
when I give feedback about code and it is selectively ignored, like what I said
about fixing the existing graphical programs assumptions about the border. You
also were still asking about including just including the scrollbar changes, again
after I said that we need to figure out what the interface is instead of just committing
code. Perhaps push is too strong of a word, but you clearly were still presenting reasons
why it should be included.

> 
> My last email response was with the understanding that I knew it was
> rejected and I wasn't trying to force its inclusion.  I did have
> comments regarding what was considered hacky and how I've seen commits
> accepted that do (knowingly) break assumptions/previous interfaces.
> Things that I've seen done around here.

It is only done with careful consideration and extra care must be taken
to modifications of fan favorites like rio. I am telling you that this
is "moving the water dish" too much but you don't seem to want to believe me.
The fact that it happens sometimes does not give you a blanket excuse to do
it whenever you want.

The reason I was not super enthusiastic to scale based on font was because
this would change the existing rio environment for people who currently use
a larger font. Like this is a pretty big "taste" change.

> 
> Anyway, in an attempt not to be misunderstood in the future I will try
> the following boilerplate response: "
> Thank you for reviewing.  I understand by your response that the patch
> is rejected by you.  However, I have some related follow-up questions
> and comments.  I don't expect any reply, especially if you consider my
> follow-ups have already been addressed.  I also don't want to make you
> think I am pushing for the patch as written to be included: I am not.
> 
> So having said that, ...  [my follow-ups] ..."

Arguing for and/or making excuses for code reads as you pushing that
things are "Ok as is" and I interpret this as pushing for inclusion as is.
You don't need boiler plates just stop doing that if you don't actually
think the patch is good as is.

> 
> In the past I have followed up on patches I sent to the mailing list
> but which were never commented on. I was told earlier (I think in
> January, IIRC) that if no comment had bern given after a week it's
> okay to follow-up.

Sure, this was not a follow-up this was an argument against the issues
I raised against the patch implementation.

> 
> And I often have seen messages here like "patches welcome" and
> also lambasting those who ask about something to be changed given a
> response akin to "talk is cheap, show me the code." So up until now I
> have figured showing at least some effort with a patch (which might
> very well be rejected) is better than just asking about scaling and
> sizing.

Sure, now we have a whole discussion about how to implement this.
You just have to continue working on it, patches are rarely ever
good enough on first cut to be included. Patches are posted, people
give feedback and folks go back and add that feedback to their code.
You are missing this part where you got back and work on the suggestions
made about the code, I know you've done it before for patches so I am not
sure why you seem to averse to it now.

At the end of the day you have code for yourself now for you to use.
You've solved the problem for yourself.

> 
> Again, thank you for all you have helped me with on this list and on
> gridchat.

I don't have anything against you my dude. This conversation just had big
"take it or leave it" energy about the state of the code. Excuses for
why merging code that was going to break other graphical programs was ok,
merging conventions that we may or may not actually want to commit to.
Saying "well if anyone else wants this diff here it is". Can you really
not see how I would interpret this as wanting to continue with how the
code is?

I am really not interested in sitting here and arguing intent, I stated
my issues with how the conversation has gone. I don't know what to say
if you really can not see how I arrived at these interpretations.


- Moody


  reply	other threads:[~2024-05-11 15:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-10  6:13 Romano
2024-05-10 13:27 ` Kristo
2024-05-10 14:01   ` Stanley Lieber
2024-05-10 14:17 ` Jacob Moody
2024-05-10 18:43   ` Romano
2024-05-10 19:15     ` Jacob Moody
2024-05-10 19:40       ` ori
2024-05-11 16:45         ` hiro
2024-05-11  4:31       ` Romano
2024-05-11 15:00         ` Jacob Moody [this message]
2024-05-11 16:54           ` hiro
2024-05-13  5:18           ` Romano
2024-05-11 16:42       ` hiro
2024-05-10 21:00     ` sl
2024-05-11  4:34       ` Romano
2024-05-13  5:38         ` Romano
  -- strict thread matches above, loose matches on Subject: below --
2024-05-09 21:04 Romano
2024-05-10  0:14 ` Jacob Moody
2024-05-10  0:34   ` sl
2024-05-10  6:20   ` Kurt H Maier
2024-05-10 14:10     ` Jacob Moody
2024-05-10 14:16       ` Stanley Lieber
2024-05-10 14:20         ` Jacob Moody
2024-05-10 14:23           ` Stanley Lieber
2024-05-10 14:21         ` ori
2024-05-10 14:33           ` Stanley Lieber
2024-05-10 14:37             ` Stanley Lieber
2024-05-10 14:58       ` Kurt H Maier
2024-05-10 15:28         ` Stuart Morrow
2024-05-10 16:11           ` Stanley Lieber
2024-05-10 16:43             ` Stuart Morrow
2024-05-10 16:50               ` Stuart Morrow
2024-05-11 16:36               ` hiro
2024-05-11 16:30             ` hiro
2024-05-11 16:27       ` hiro
2024-05-11 16:36         ` Jacob Moody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10658a6d-38bc-4b49-bc13-c42cc0113034@posixcafe.org \
    --to=moody@posixcafe.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).