Re: Proposal: Add review tags to patch review workflow.

[Joel Brobecker <brobecker@adacore.com>]

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.

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.

> 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!

-- 
Joel