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