On Fri, 1 Nov 2019 19:59:35 +0000
Michael 'veremitz' Everitt <gen...@veremit.xyz> 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

Reply via email to