Re: [PATCH] diff: fix --color-moved-ws=allow-indentation-change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> On Tue, Sep 11, 2018 at 11:16 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>
>> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>>
>> >>  [...] So this should be sufficient.
>> >
>> > Yup.
>> > Thanks for keeping track of this patch, as I lost track of it.
>> >
>> > thanks,
>> > Stefan
>>
>> So does the above exchange mean that
>> <20180904135258.31300-1-phillip.wood@xxxxxxxxxxxx> is ready to go
>> with your Acked-by?
>
> Acked-by: Stefan Beller <sbeller@xxxxxxxxxx

Thanks.

> I thought this was implicit, would you be interested in a more formal
> communication for this, c.f.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n513
> sections 12 and 13.

It wasn't like I was explicitly asking for an ack because that
section tells us to do so in this case.  Rather, I didn't follow the
state of this patch, for which the original author of the recent
feature ended up saying "I lost track of it".

If a reviewer and/or an acker anticipates that I, who by definition
needs to know the final state of more topics than any single
individual contributor does, may not remember the state of each
individual topic, and tries to be a bit more explicit, our
communication may sometimes end up being extra redundant, but some
other times, doing so would reduce the need for one extra roundtrip.

If I need a clarification, I'll ask anyway, just like I did in this
case, so I do not think it is all that necessary to be rigidly
"formal", especially among list regulars.  Just a simple common
sense courtesy to try reducing each other's workload and memory
burden is probably sufficient.

Thanks.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux