KScreen/libkscreen commit message policies

[Roman Gilg]

On Wed, Nov 13, 2019 at 12:26 AM Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>
> 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?

Yeah, both would be possible. When it becomes relevant (for tooling,
etc.) we should also ask upstream about it. For now "fix: ..." or
"fix(scope): ..." can be used.

> --
> Luigi