From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DA059138334 for ; Fri, 1 Nov 2019 21:11:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05F1BE0805; Fri, 1 Nov 2019 21:11:56 +0000 (UTC) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C8A21E041F for ; Fri, 1 Nov 2019 21:11:55 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id t12so4880088plo.6 for ; Fri, 01 Nov 2019 14:11:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=i7mcyVbAPTlooPGwqHUfzyKwj6zYitvc1xxa4pkOIBU=; b=eULntik9+/xL6aW/qsdXOgsK90ANTpjj1UqWHMupBri0wKK2ZvMC9RIphRp7BcOHOC 65iXmA7+3YZos65qWk/yVRfo0S25xaE8qwo6YA74K0U7NI51T9iR2UPxVDonXdqsI3IE gmlc6PPn8OjUsDKGjtj5BpMjl9ReGNcJmvD82XTU4AaTIWFxLZMPEiXnZxA07moqbk6h DJLkMKkzoVjrQXQ3hqAAxvI5NQWq6L1wxEB1grv0X+tEyW5xY4jJhDpsjg5RzhqBNBgv FS8J0Z6RtcEgBKmvrr9dzQ3l9/XdTWc7oWvMckK0Qa0TEXP7Nume6StWKmCLFzu5lVGP 4w7w== X-Gm-Message-State: APjAAAUgal+X3by1NJyTQ8Wbr1Ectiz+zRfnbuBSTV+CAjThnUf4GIRL A/BdrDhVNi/F7tuSvmGM/x2TtcDmJM9jKbAPWy33zhYpBTu7LA== X-Google-Smtp-Source: APXvYqwjYtZSAnWI9u2KdsZy2e8orcDUguu0eydvEJ1SP8Kp/jysn3Z+Lb6haJJaz15EWZ3GoYClyiGhMa7OfkvgN6s= X-Received: by 2002:a17:902:ba94:: with SMTP id k20mr14592919pls.312.1572642714175; Fri, 01 Nov 2019 14:11:54 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <55b42dc1-cbfd-8fa0-8bfd-433e7c92a21f@veremit.xyz> In-Reply-To: From: Rich Freeman Date: Fri, 1 Nov 2019 17:11:43 -0400 Message-ID: Subject: Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 1cfb3041-d1d5-4946-a007-bb0274446af4 X-Archives-Hash: c23cf64326d63844839982cb9caac874 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