Roman Gilg ha scritto: > On Mon, Nov 11, 2019 at 10:58 PM Luigi Toscano <luigi.tosc...@tiscali.it> > wrote: >> >> Roman Gilg ha scritto: >>> Hi, >>> >>> I just pushed commit message policies to KScreen [1] and libkscreen >>> [2] (linked below from GitHub so they can be read with Markdown >>> formatted). >>> >>> I intend to revert in the future all manual commits to KScreen and >>> libkscreen deliberately ignoring the policies. Here "manual" means >>> here that I won't revert commits based on a script that are regularly >>> pushed to many repositories (like release number changes) or >>> automatically named merge commits. >>> >>> If you have questions or other comments you can also reach me on IRC >>> #plasma, romangg. >> >> Does it also mean that any typo fix in user visible strings should go through >> review requests? > > I would classify such changes in general as "trivial changes" in the > sense that they are obvious and do not need to be discussed or > reviewed. If in rare cases this does not hold, the change can get > reverted and need to go through review instead. But I assume this to > be a rare occurrence. > > Note though that in any case the commit message guideline must be > respected. Calling such a commit for example "fix(kcm): spell X > correctly" should be enough. > > A question long term is if there should be a separate type for > i18n-only changes (for example "i18n(kcm): spell X correctly"). What's > your opinion on that? This could help down the line setting up > automatic tooling (as said only long term relevant).
Uhm, I don't really have a strong opinion. Looking at the original spec, there does not seem to be a specific type for i18n changes. I don't know if it was not considered, or simply not too relevant for a type. In any case, fix should be fine. What about a fix(i18n), if it helps to easily identify a commit? -- Luigi
