On Fri, Nov 1, 2019 at 4:36 PM Matt Turner <matts...@gentoo.org> wrote:
>
> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
> <gen...@veremit.xyz> wrote:
> >
> >
> > 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.
git log --format=oneline glibc-2.29-r2.ebuild | grep stable
9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc
stable, bug 685818
b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable
2.29-r2 for hppa, bug #685818
fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable
wrt bug #685818
0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt
bug #685818
7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable
wrt bug #685818
bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha stable
2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable
wrt bug #685818
e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable
wrt bug #685818
52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable
wrt bug #685818
745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable
wrt bug #685818
332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable
(bug #685818)
9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable
(bug #685818)
b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable
wrt bug #685818
Seems to work fine for me.
>
> In the past people have argued that the version in the title is
> superfluous since you can get the same info from git (log|show) --stat
> but the same (misguided argument) can be used to justify something
> absurd like simply making the bug number the subject.
I don't think these are at all equivalent. The current state just
relies on finding version history in git, which is basically the main
purpose git serves. Your example involves joining two disparate
datasets, neither of which natively offer an SQL-compatible interface.
I think the rationale for not putting more mandatory content in the
commit summary was that its length is limited and the more boilerplate
we cram in there, the less room we have for meaningful description,
when the boilerplate is already easily searched using git (though
admittedly not from changelog extracts). Sure, for stable/keyword
changes there isn't much in the way of description to worry about, but
for other changes I suspect that this could be limiting.
>From GLEP 66: The summary line must not exceed 69 characters, and must
not be wrapped.
In the example I cited the longest summary is already 59 chars:
sys-libs/glibc: Fix handling of ${EPREFIX} when building cross-glibc
If you wanted to stick 7 more chars of PV info in there then we'd be
just 3 chars short of the limit, and this is just a randomly chosen
example. Packages with longer PV certainly exist, along with ones
with longer summaries.
Personally I don't really care that much one way or another as long as
repoman is updated to follow any new standard, but this seems like it
could be impactful to people doing more complex work in the tree. I
get that some people really seem to want to avoid using git, but this
is basically what it was made to do, and IMO seems like a step in the
wrong direction. I think the main purpose of putting PN in there at
all was so that commits that hit multiple packages would be more clear
in logs.
--
Rich
