-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert "Replace --quiet with --banner (#23343)" #23396
Conversation
While I was ok with |
No?. The revert is certainly not targeted at the author of the PR, that was a correct fix to the issue it closes. However, it was an issue that asked for a name change to one that doesn't reflect what the option was doing so to be more welcoming we should think more before openning issues and have more discussion before inviting new contributor to work on it. |
I have made a PR with an alternative solution: #23399. We can decide which one makes more sense, merge it and close the other one. Your solution may make more sense. If you'd communicated your position in a less abrasive and confrontational way, we could have come to a conclusion here with a lot less debate. The ongoing passive aggressiveness about me opening an issue for a clear mismatch between a command-line option's name and its help message is not helpful. |
Sorry if it sounds like passive aggressive, that's not really what I mean. However, I do think that issue was openned too quickly and have encouraged new contributor to work on it without discussion. I certainly believe you have the capability to check the uses of the option and see if it really means "disable banner" so I think that should be done. I usually observe that issues openned in this manner are not the most useful ones so I always do some simple code browsing/changing (5-10mins) before openning an issue that's not clearly a bug (like crashes) to make sure that the issue itself makes sense. |
How slowly should I open issues? Should I write issues down in my moleskin notebook and ponder them for a week before filing them on GitHub? I did check the help message of the option and the implementation. I missed the one place where |
Enough to decide if something is a good idea other than the one instance it comes up. 1day should be long enough.
One week can be a little too long but yes, that is good and I do that all the time.
Hmm, it was merged one day after the banner issue was brought up and the same day after the first reply to that comment. And I was actually quite surprised that it was treated as a good sign for the change even though it is acknowledged that the new name is very weird compare to what the option actually does. |
As usual, we seem to be talking past each other but the timeline of #23343 does not agree with what you seem to be saying. In any case, I'm done with wasting time on this, so I'll be moving on. |
So just to clearify what I'm saying without asking for reply, in case part of it was not clear enough and can be misinterpreted.
The PR was merged on Aug. 21st, 12:02 pm. The banner issue (I guess this was a typo, I mean the warning issue) was brought up Aug. 20th, 8:50 am, which was 27hrs 12mins before the merge and the first reply to that comment was at Aug. 21st, 11:14 pm, 48mins before the merge. |
The opening of the second issue wasn't problematic, so I'm not sure why that's relevant. |
The second issue isn't related, the link I post links to the |
Is this PR still relevant now that #23399 has been merged? |
This reverts commit dcb46b3
and clarify the help message of
--quiet
.Fix #23380
Reopen #23342
AFAICT there isn't a clear need for #23342 since quite startup seems to cover all usecases. The discoverability of
-q
is also pretty good (it's in-h
) and the name is pretty standard (gdb
,python
).