| 1 |
On Fri, Nov 1, 2019 at 4:36 PM Matt Turner <mattst88@g.o> wrote: |
| 2 |
> |
| 3 |
> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt |
| 4 |
> <gentoo@×××××××.xyz> wrote: |
| 5 |
> > |
| 6 |
> > |
| 7 |
> > Therefore, it would be much /more/ useful to have the package-version |
| 8 |
> > tagged in the commit message, so that you could easily grep logs for when a |
| 9 |
> > given version of a package was stabilised, and/or keyworded. |
| 10 |
|
| 11 |
git log --format=oneline glibc-2.29-r2.ebuild | grep stable |
| 12 |
9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc |
| 13 |
stable, bug 685818 |
| 14 |
b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable |
| 15 |
2.29-r2 for hppa, bug #685818 |
| 16 |
fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable |
| 17 |
wrt bug #685818 |
| 18 |
0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt |
| 19 |
bug #685818 |
| 20 |
7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable |
| 21 |
wrt bug #685818 |
| 22 |
bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha stable |
| 23 |
2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable |
| 24 |
wrt bug #685818 |
| 25 |
e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable |
| 26 |
wrt bug #685818 |
| 27 |
52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable |
| 28 |
wrt bug #685818 |
| 29 |
745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable |
| 30 |
wrt bug #685818 |
| 31 |
332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable |
| 32 |
(bug #685818) |
| 33 |
9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable |
| 34 |
(bug #685818) |
| 35 |
b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable |
| 36 |
wrt bug #685818 |
| 37 |
|
| 38 |
Seems to work fine for me. |
| 39 |
|
| 40 |
> |
| 41 |
> In the past people have argued that the version in the title is |
| 42 |
> superfluous since you can get the same info from git (log|show) --stat |
| 43 |
> but the same (misguided argument) can be used to justify something |
| 44 |
> absurd like simply making the bug number the subject. |
| 45 |
|
| 46 |
I don't think these are at all equivalent. The current state just |
| 47 |
relies on finding version history in git, which is basically the main |
| 48 |
purpose git serves. Your example involves joining two disparate |
| 49 |
datasets, neither of which natively offer an SQL-compatible interface. |
| 50 |
|
| 51 |
I think the rationale for not putting more mandatory content in the |
| 52 |
commit summary was that its length is limited and the more boilerplate |
| 53 |
we cram in there, the less room we have for meaningful description, |
| 54 |
when the boilerplate is already easily searched using git (though |
| 55 |
admittedly not from changelog extracts). Sure, for stable/keyword |
| 56 |
changes there isn't much in the way of description to worry about, but |
| 57 |
for other changes I suspect that this could be limiting. |
| 58 |
|
| 59 |
From GLEP 66: The summary line must not exceed 69 characters, and must |
| 60 |
not be wrapped. |
| 61 |
|
| 62 |
In the example I cited the longest summary is already 59 chars: |
| 63 |
sys-libs/glibc: Fix handling of ${EPREFIX} when building cross-glibc |
| 64 |
|
| 65 |
If you wanted to stick 7 more chars of PV info in there then we'd be |
| 66 |
just 3 chars short of the limit, and this is just a randomly chosen |
| 67 |
example. Packages with longer PV certainly exist, along with ones |
| 68 |
with longer summaries. |
| 69 |
|
| 70 |
Personally I don't really care that much one way or another as long as |
| 71 |
repoman is updated to follow any new standard, but this seems like it |
| 72 |
could be impactful to people doing more complex work in the tree. I |
| 73 |
get that some people really seem to want to avoid using git, but this |
| 74 |
is basically what it was made to do, and IMO seems like a step in the |
| 75 |
wrong direction. I think the main purpose of putting PN in there at |
| 76 |
all was so that commits that hit multiple packages would be more clear |
| 77 |
in logs. |
| 78 |
|
| 79 |
-- |
| 80 |
Rich |
Archives