KScreen/libkscreen commit message policies

[Luigi Toscano]

Roman Gilg ha scritto:
> On Mon, Nov 11, 2019 at 10:58 PM Luigi Toscano <luigi.toscano at 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