Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

[Michael 'veremitz' Everitt]

On 02/11/19 08:54, Kent Fredric wrote:
> On Fri, 1 Nov 2019 19:59:35 +0000
> Michael 'veremitz' Everitt <gentoo@×××××××.xyz> wrote:
>
>> Thoughts from outside peanut gallery?
>>
>> Michael / veremitz.
> I have an alternative that might be more pleasant:
>
> 1. Change repoman so that when its clear that:
>    - There is at least one ebuild being changed
>    - There is only one ebuild being changed
>   Then the templated summary line is full ${P}
>
> 2. Otherwise, retain the current semantics of using a simpler
>    ${P} in other cases.
>
> 3. Make no *requirements* that ${P} be used instead of ${PN},
>    and that way people who think they have a good reason to use ${PN}
>    instead of ${P} can do just that (if for instance, they need to lop
>    off context so they can have a longer commit message )
>
> This IMO improves things by default, given that the majority of changes
> get run through repoman, and a majority of changes have very terse
> requirements for extra data.
>
> It also means that by default, when people just make the commit message
> something silly like "bump", or "version bump", despite the fact they
> didn't put in much effort, the log defaults to being useful, and the
> commit messages relayed to #gentoo-commits improves in usefulness.
>
> Partly, because for me, one of my prime vectors where I become aware
> changes are occuring is in #gentoo commits, particularly because
> something in there highlights me.
>
> I don't want to *have* to:
> - Resync my git repo
> - Dig into git wizardry
>
> *just* to ascertain what version was involved, and to then ascertain if
> I need to investigate further.
>
> ( Because once I've already synced and started using git wizardry, I'm
> already starting to pay investigation taxes )
>
>
This sounds like a good compromise, and one I'm content to work on. Anyone
else able/willing to pitch in?