From: Luis Machado <luis.machado@arm.com>
To: Joel Brobecker <brobecker@adacore.com>,
Simon Marchi via Gdb <gdb@sourceware.org>
Subject: Re: Proposal: Add review tags to patch review workflow.
Date: Tue, 27 Sep 2022 09:42:40 +0100 [thread overview]
Message-ID: <7c6afd40-a31e-cf28-de82-f9cd5b6a4772@arm.com> (raw)
In-Reply-To: <674788ed-f691-447c-206d-4a4e15347d4b@arm.com>
On 9/27/22 09:39, Luis Machado via Gdb wrote:
> Hi Joel,
>
> Thanks for bringing this up.
>
> On 9/26/22 17:42, Joel Brobecker via Gdb wrote:
>> Just thinking out loud...
>>
>>> I completely agree with the proposal. I really like the fact that it
>>> makes communication less ambiguous. Following some process (or changing
>>> the process) can feel a bit heavy for long-timers, but I think it makes
>>> things much clearer for newcomers.
>>
>> Speaking of ambiguous, one thing that we used to do well in the past
>> but then kind of got worse was the subject prefix we used to use
>> to indicate the status of a patch. In particular, we used to reserve
>> certain keywords for that in the subject (e.g. "RFA" vs "PATCH", or
>> "OB" for obvious, etc). We lost that part, not sure exactly when,
>> but I suspect sometime when we transitionned to Git.
>>
>> Something else also that I have been feeling the last year or two
>> is that I'm not sure people now explicitly confirm to the list
>> when a patch is pushed.
>
> I think that's been happening, yes. But the IRC bot mentions commits explicitly, and
> developers tend to see updates in the git repo when they update the sources.
>
> With that said, in general the frequent GDB contributors tend to be quite busy (with
> GDB or other things), so I'm inclined to say it is positive to have less steps to
> take care of to push a change.
>
> For example, ChangeLog's were a big time sink, and we managed to get rid of that rule. I think
> that was very positive.
>
> We still have other potential improvements waiting to be discussed, like auto-formatting of code
> with some tool like clang-format. Time spent correcting formatting is not very useful.
>
>>
>> The reason I mention this is to show that perhaps we're getting back
>> to the fact that our email reviewing system is still email-based.
>> One way to address the various limitations is by adding more
>> processes, as suggested here. This has the good property of being
>> fairly cheap to discuss and implement, at the cost of a small
>> added overhead. I don't have a strong opinion about it, either
>> for or against (and given the amount of time I have to contribute
>> anyway, I don't think I should have a say).
>>
>> With that said, I have a feeling that switching to a system designed
>> to manage patch submissions and reviews, no matter imperfect, is going
>> to solve a lot of the limitations of the current email-based system.
>> So that's another option worth reviewing from time to time, I think.
>> I understand that selecting, deploying and trying new review systems
>> requires a fair amount of effort. But having seen the benefits of
>> using several different such systems, I am convinced that the gains
>> will be very much worth whatever the drawbacks of that system might be.
>
> That's a fairly good point, and I agree. We tried a patch reviewing system (gerrit)
> before. For me, at the time, it was obvious that the number of reviews increased
> significantly. It was just easier to do reviews that way. If you had 5 minutes, you
> could scan for a small change and give some feedback. The list of patches to-be-reviewed
> was never forgotten.
>
> But back then we didn't want to risk alienating global maintainers that didn't like gerrit or
> liked the e-mail system better, so we dropped that effort and put nothing back in its place. It feels
> to me patch reviewing by non-contributors lost some of the traction it had gained with gerrit.
Oops. I mean non-contributors -> non-maintainers.
>
> It is not a secret that some of us contributors would like to see improvements in this area, hence
> my suggestion to address patch reviewing/more maintainers/CI-based testing as topics for the GDB BoF.
>
> But at the end of the day, it's up to the global maintainers to make a decision on this topic, or to
> let contributors know they are open to adopting improvements.
>
> So, in summary, I see the proposal to add tags as a way to improve a patch reviewing system that
> is not being capable of keeping up with demand. I doubt we would need such tagging if we had a
> proper reviewing system in place (be it gerrit, patchworks or any other).
>
>>
>>> Assuming we will go through with this proposal, it will need to be
>>> documented on the wiki so we can easily refer people to the procedure.
>>> Probably the ContributionChecklist page?
>>>
>>> https://sourceware.org/gdb/wiki/ContributionChecklist
>>>
>>> Will you be able to take care of this when needed (do you have write
>>> access to the wiki)?
>>>
>>> In the mean time, message to others: please let us know if you agree
>>> with this, it's difficult to know we have the support of the community
>>> if everybody silently agrees!
>>
>
next prev parent reply other threads:[~2022-09-27 8:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 11:04 Bruno Larsen
2022-09-25 22:38 ` Lancelot SIX
2022-09-26 13:55 ` Simon Marchi
2022-09-26 16:42 ` Joel Brobecker
2022-09-27 8:39 ` Luis Machado
2022-09-27 8:42 ` Luis Machado [this message]
2022-09-27 9:38 ` Lancelot SIX
2022-09-27 21:07 ` Thiago Jung Bauermann
2022-09-26 21:32 ` John Baldwin
2022-09-27 8:06 ` Bruno Larsen
2022-09-27 12:02 ` Simon Marchi
2022-09-27 12:03 ` Bruno Larsen
2022-09-27 17:11 ` John Baldwin
2022-09-27 7:58 ` Bruno Larsen
2022-09-27 12:03 ` Simon Marchi
2022-09-26 15:59 ` Luis Machado
2022-09-26 16:32 ` Elena Zannoni
2022-09-27 8:30 ` Bruno Larsen
2022-09-27 20:50 ` Thomas Schwinge
2022-10-07 7:49 ` Bruno Larsen
2022-10-07 20:46 ` Simon Marchi
2022-10-08 6:23 ` Eli Zaretskii
2022-10-08 11:55 ` Simon Marchi
2022-10-08 12:44 ` Eli Zaretskii
2022-10-09 0:29 ` Simon Marchi
2022-10-10 9:27 ` Bruno Larsen
2022-10-10 9:47 ` Eli Zaretskii
2022-10-10 10:11 ` Bruno Larsen
2022-10-10 11:27 ` Eli Zaretskii
2022-10-10 12:31 ` Bruno Larsen
2022-10-10 13:14 ` Eli Zaretskii
2022-10-10 13:26 ` Bruno Larsen
2022-10-10 15:25 ` Eli Zaretskii
2022-10-10 13:34 ` Pedro Alves
2022-10-10 9:39 ` Luis Machado
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=7c6afd40-a31e-cf28-de82-f9cd5b6a4772@arm.com \
--to=luis.machado@arm.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).