I think a big problem with the component labels is that there is a) no defined set of labels b) no way to enforce the usage of them c) no easy way to figure out which label to use
Due to these problems they are used very inconsistently in the project. I do agree with Arvid's observation that they are less and less often used in new commits. Given this, we could think about adjusting our guidelines to better reflect reality and make them "optional"/"nice-to-have" for example. Cheers, Till On Wed, May 19, 2021 at 10:52 AM Chesnay Schepler <[email protected]> wrote: > 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 > > > >
