Re: KScreen/libkscreen commit message policies
On Wed, Nov 13, 2019 at 12:26 AM Luigi Toscano wrote: > > Roman Gilg ha scritto: > > On Mon, Nov 11, 2019 at 10:58 PM Luigi Toscano > > 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
Re: KScreen/libkscreen commit message policies
Roman Gilg ha scritto: > On Mon, Nov 11, 2019 at 10:58 PM Luigi Toscano > 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
Re: KScreen/libkscreen commit message policies
On Mon, Nov 11, 2019 at 10:58 PM Luigi Toscano 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). Cheers, Roman > > -- > Luigi
Re: KScreen/libkscreen commit message policies
El dilluns, 11 de novembre de 2019, a les 23:25:34 CET, Albert Astals Cid va escriure: > El dilluns, 11 de novembre de 2019, a les 22:41:18 CET, Roman Gilg va > escriure: > > 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). > > That's not how it works, you can't override the manifesto that says we can > all push everywhere :) I think i kind of did a fool of myself by commenting before reading the article. I can't really find stuff openly against the manifesto on it. Sorry for being a bad community member :/ Cheers, Albert > > Cheers, > Albert > > > > > 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. > > > > Thanks, > > Roman > > > > [1] https://github.com/KDE/kscreen/blob/master/CONTRIBUTING.md > > [2] https://github.com/KDE/libkscreen/blob/master/CONTRIBUTING.md > > > > > > >
Re: KScreen/libkscreen commit message policies
El dilluns, 11 de novembre de 2019, a les 22:41:18 CET, Roman Gilg va escriure: > 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). That's not how it works, you can't override the manifesto that says we can all push everywhere :) Cheers, Albert > > 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. > > Thanks, > Roman > > [1] https://github.com/KDE/kscreen/blob/master/CONTRIBUTING.md > [2] https://github.com/KDE/libkscreen/blob/master/CONTRIBUTING.md >
Re: KScreen/libkscreen commit message policies
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? -- Luigi
KScreen/libkscreen commit message policies
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. Thanks, Roman [1] https://github.com/KDE/kscreen/blob/master/CONTRIBUTING.md [2] https://github.com/KDE/libkscreen/blob/master/CONTRIBUTING.md
