Re: Review process improvements

From: João Victor Bonfim <joaovictorbonfim+git-mail-list@protonmail.com>
Date: Jan 9, 2022, 03:26 UTC
Message-ID: <rcGd-SpUU-W-tTnksrZa3gaeC9Kswpy7oPiOyp-GGV5WJgkoICgiD5ppeFz3h89h0l8C1fSRv5XcI6pqR4uEaG8mh29uWmPUDk-NORRkt2o=@protonmail.com>
In-Reply-To: <YdTuMlAkVIivp1bg@google.com>

> That makes sense to me. As Ævar mentioned - just because he and I are
> working on config a lot right now, doesn't mean we will still care in
> 2023. And remembering to remove yourself from the MAINTAINERS file is a
> pain.

 Maybe make a "contributors" file instead and merely list there who have
contributed with Git, what have they contributed with (or group
contributors by their types of contribution) and means of contact, like
institutions they are a part of, e-mail addresses, telephone numbers,
while highlighting that all e-mails related to Git are expected to be
shared with the mailing list unless stated otherwise. Also make the
input of personal information beyond name voluntary.

> Some providers (at least Gmail, and based on João's reply-to address,
> protonmail as well) allow mails addressed to
> e.g. "my-name+from-git-list@example.com" to be delivered to
> "my-name@example.com" regardless of what follows the +;

 Although ProtonMail allows the use of + aliases, no filtering
is done automatically.

> I have only recently seen you begin to post here, so welcome! and I
> think I saw someone else mention in another thread, but I'll say again
> now: in general, please wrap your lines at ~80ch when replying to the
> mailing list;

 Is "80 ch" 80 American units? (half-joke)
 I also have no idea on how to configure that.

Show 8 quoted lines

> I'm not really sure what you mean by "non-committal" here. I will say
> that messages coming from the Git mailing list does not imply that
> messages are safe in any way; we get plenty of spam and phishing mails
> making it past vger.kernel.org's filters. The proposal of a MAINTAINERS
> file was definitely not a proposal to modify the review process itself;
> as always, the expectation is that code should be reviewed by a number
> of contributors to ensure it's doing what it says it is trying to do. I
> don't see that that will ever change.

 Brain fog, I don't exactly remember either. From what I got I was
thinking about the servers sending messages in the name of the parties
listed, not only to them. Also I might be thinking of people sending
malicious code through commits and git operations and it causing
problems and also about e-mail addresses being compromised.

> For what it's worth, in my Gmail web client I filter out any mails
> beginning with `[PATCH` - because in web client I am like you and
> usually only want to participate in broader discussions. So I think
> there is already a solution for filtering the way that you want to.

 Can't we automate it at the source, though...
 ;A;

Show 10 quoted lines

> As I mentioned in my mail, we are only conducting review of commit
> messages and cover letters, not of code - specifically because it is
> so important to perform in-depth code review out in the open, for the
> reasons you say. Code review should always happen on this list, and I'm
> not suggesting to change that. (That's true of patches submitted via
> GitGitGadget too, by the way - we don't perform review in the comments
> on those GGG pull requests, for these same reasons.)
>
> As for the Googley review know-how.... like I mentioned in my reply to
> the main thread a moment ago, there's not that much "secret sauce". :)

 I still believe that methods of reviewing commit messages might be
helpful if shared collectively.

Show 5 quoted lines

> However, if you're curious, you might keep an eye on the #git-devel
> channel - we have recently started doing public "review club" live
> meetings and inviting the Git community to join us in reviewing patches
> on the Git list. The next one is this week, so if you're interested and
> the timezone works out, you'd be welcome to join us.

 I both don't know what is Devel and how to use it and don't believe
anxiety will allow me, specially since I am very socially anxious, I
am using a TV screen as a "temporary" monitor and it triggers my
sensory sensitivities, because of the amount of information and light
(having a text heavy profession might have been a bad idea), and...

*panic*

... anxiety??? (better not delve too deep into that can of worms)

> Yes, I agree this is the best way to do documentation. Human ability to
> parse or no - having the same information in two places means that
> inevitably, one place will become stale. ;)

 Maybe use <iframe>s to embed files onto each other? Also make explicit
or (inclusively) allow the frames to be hidden or collapsed with a button?

> Again, welcome to the project.

<3 Thank you!

 - João Victor Bonfim, please use any pronouns.