Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On 02/11/19 08:54, Kent Fredric wrote:
> On Fri, 1 Nov 2019 19:59:35 +
> Michael 'veremitz' Everitt 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?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, 1 Nov 2019 19:59:35 +
Michael 'veremitz' Everitt 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 )
pgpv94J0xya_W.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, 1 Nov 2019 19:59:35 +
Michael 'veremitz' Everitt 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
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On 01/11/19 21:45, Mike Gilbert wrote: > On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt > wrote: >> On 01/11/19 21:11, Rich Freeman wrote: >>> On Fri, Nov 1, 2019 at 4:36 PM Matt Turner wrote: On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt 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. >>> >>> >> How well does git handle that when the ebuild is deleted from the tree? > It handles it just fine, though you need to add "--" to disambiguate > it from a ref. For example: > > git log --format=oneline --grep=stable -- foo-123.ebuild > Consider me somewhat enlightened .. (!) :] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt wrote: > > > git log --format=oneline glibc-2.29-r2.ebuild | grep stable > > > How well does git handle that when the ebuild is deleted from the tree? > git log --format=oneline -- glibc-2.29-r4.ebuild 23d1c015230d9ff44bcdd7b72e00ca3533815fa4 sys-libs/glibc: drop old f3872a506edc7da0d987bcf0a90d4709945328a7 sys-libs/glibc: restore strip quirk for 'libpthread.so.0' 650d70eb5d91265329e2f730bc1aed0fa5863db6 sys-libs/glibc: disable stripping for cross-glibc e14229b10b513a164f8379ff14cc8c644c071f27 sys-libs/glibc: drop prepallstrip, bug #587296 fb2fe75af62ad29a44aeba1b8e9e41ce5acb3992 sys-libs/glibc: Add 2.29 revision with compile-locales support I was too lazy to find something that had stable keywords, but I'm sure substituting the appropriate filename and grepping would work fine. The trick is to put the "--" in the command line. However, you could hardly be blamed for hitting your head against the wall trying to figure out how to do this. I had to google it as I've run into this myself. As many have said git is an amazing data model with a terrible UI. -- Rich
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt wrote: > > On 01/11/19 21:11, Rich Freeman wrote: > > On Fri, Nov 1, 2019 at 4:36 PM Matt Turner wrote: > >> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt > >> 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. > > > > > How well does git handle that when the ebuild is deleted from the tree? It handles it just fine, though you need to add "--" to disambiguate it from a ref. For example: git log --format=oneline --grep=stable -- foo-123.ebuild
[gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On 01/11/19 21:11, Rich Freeman wrote: > On Fri, Nov 1, 2019 at 4:36 PM Matt Turner wrote: >> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt >> 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. > > How well does git handle that when the ebuild is deleted from the tree? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, Nov 1, 2019 at 4:36 PM Matt Turner wrote:
>
> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
> 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
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt 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. Yes, I agree we should do this. My commit messages look like: sys-apps/systemd-243-r2: ppc64 stable, bug 698766 net-misc/mosh-1.3.2: added ~alpha 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. Honestly, just put the dang version in the title.
[gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
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? Michael / veremitz. signature.asc Description: OpenPGP digital signature
