Re: Patch bumping (was Re: Feature Patch: Use completion to view parameter values)

[Lawrence Velázquez <larryv@xxxxxxx>]

> On Apr 13, 2021, at 8:32 AM, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> 
> [Marlon: Your quote attribution line is indented one more level than is
> conventional]

This is how Apple's email clients quote.  I couldn't tell you why.

> Leaving #4 "considerably longer" would decrease temporal locality in the
> patch authors' brains, would reap less "the project noticed my lack of
> response" benefits (cf.
> https://producingoss.com/en/managing-participants.html#delegation-followup),
> and would be more likely to find the patch author busy with other things
> and unable to follow up and post a revised patch.

Good point.

> You don't actually say what benefits you seek to attain. Is it about,
> say, bumps that are replies to previous bumps?  If so, I'd propose, say:
> 
> - A bump that is a reply to a non-bump should be sent with delay X.
> 
> - A bump that is a reply to a bump should be sent with delay Y.
> 
> - A bump that is a reply to a bump that is a reply to a bump should be
>  sent with delay Z and added to git (as proposed in workers/48303).
> 
> - A bump (that is a reply to a bump)³ should not be sent.

I'm not sure about varying delays, but it would be nice to have a
place to stash discussions to avoid infinite reminders.

>> Additionally, it would be helpful if committers remember to inform us
>> when a when a patch has been accepted/rejected/applied,
> 
> This would be helpful for other other reasons too:
> 
> - It would let the patch submitter know their patch has been accepted.
>  (Simply committing the patch to git without replying to it might leave
>  the patch submitter think they were ignored.)
> 
> - It would make it easier for other committers

(and me!)

> to skip PATCH threads that have already been handled.

-- 
vq