For commit messages the labels are useful mostly when scanning the
commit history, like searching for some commit that could've caused
something /without knowing where that change was made/, because it
enables you to quickly filter out commits by their label instead of
having to read the entire title.
I think in particular there is value in labeling documentation/build
system changes; it allows me to worry less about the phrasing because I
can assume the reader to have some context. For example,
"[FLINK-X] Remove deprecated methods" vs "[FLINK-X][docs] Remove
deprecated methods".
You could of course argue to use "[FLINK-X] Remove deprecated methods
from docs", but that's just a worse version of labeling.
On 5/19/2021 10:31 AM, Arvid Heise wrote:
Dear devs,
In the last couple of weeks, I have noticed that we are slacking a bit on
the components in PR/commit messages. I'd like to gather some feedback if
we still want to include them and if so, how we can improve the process of
finding the correct label.
My personal opinion: So far, I have usually added the component because
it's in the coding guidelines. I have not really understood the benefit. It
might be coming from a time where git support in IDE was lacking and it was
necessary to maintain an overview. I also have a hard time to find the
correct component at times; I often just repeat the component that I find
in a blame. Nevertheless, I value consistency over personal taste and would
stick to the plan (and guide contributions towards it) if other devs
(especially committers) do it as well. But this has been causing some
friction in a couple of reviews for me.
Could you please give your opinion on this matter? I think it's important
to note that if long-term committers are not following it, it's really hard
for newer devs to follow that (git blame not helping in choosing the
component). Then we should remove it from the guidelines to make
contributions easier.
Thanks
Arvid
