On Fri, 1 Nov 2019 19:59:35 +0000
Michael 'veremitz' Everitt <[email protected]> wrote:
> Hello,
>
> I've noticed a lot of stabilisation commit messages (and a few keywording
> ones too) simply state the package atom and not the relevant
> release/version. I find this a little meaningless, as unless this is the
> first time the package has ever been either stabilised or keyworded, it is
> reasonable to expect that there is/was some transition point for a package
> from when it first entered the Gentoo Repository.
>
> Therefore, it would be much /more/ useful to have the package-version
> tagged in the commit message, so that you could easily grep logs for when a
> given version of a package was stabilised, and/or keyworded. Granted, this
> is more of-use in a historical context compared to a present (future?!)
> one, but I would argue that it conveys more meaning -with- the version than
> without.
>
> Thoughts from outside peanut gallery?
A few points:
1. Given that you can't rely on that information today it won't be of much use
in
future if it's already not precise.
If you want consistent keywording/stabilizing behaviour you might want to
propose/implement a tool that generates commits in a form everybody agrees.
Say, a specific form of repoman commit.
Today even keywording itself in not exactly fully automated process:
https://bugs.gentoo.org/639724
2. repoman was changed to disallow long enough subject lines from being
committed.
As a result sometimes you can't just fit both package name and package version
into the fist line. Let alone full arch list and bug number.
Thus requiring ${P} is technically infeasible.
It would probably help to describe original problem in more detail being solved
before
discussing of a solution.
If you need a precise solution for "when foo was stabilized" you have to look
at the
ebuild's metadata as an authoritative source.
--
Sergei
