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 CDFD7138334 for ; Mon, 24 Sep 2018 02:27:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7EEC6E0903; Mon, 24 Sep 2018 02:27:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 1A060E08F6 for ; Mon, 24 Sep 2018 02:27:01 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id A3DFC335D2C for ; Mon, 24 Sep 2018 02:26:59 +0000 (UTC) Date: Mon, 24 Sep 2018 14:26:29 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: What means bup? Message-ID: <20180924142629.5483118a@katipo2.lan> In-Reply-To: <20180923224527.y622ftpldrm7td2x@gentoo.org> References: <2118089b-4d6d-0a89-ce78-8d5597fb0141@gentoo.org> <20180718072657.fnz45gc44v3m4n6v@gentoo.org> <20180922203623.5ls6dcc73rifhuo5@gentoo.org> <20180924092757.5c714f9d@katipo2.lan> <20180923224527.y622ftpldrm7td2x@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/ZBt81zh9RC0l0sDwBRwA9=4"; protocol="application/pgp-signature" X-Archives-Salt: 617bd1b9-2828-4ca0-b7d8-b61b6563c1f6 X-Archives-Hash: fb647cac1ca3b0639f30f7320e7524dd --Sig_/ZBt81zh9RC0l0sDwBRwA9=4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 23 Sep 2018 17:45:27 -0500 Matthew Thode wrote: > On 18-09-24 09:27:57, Kent Fredric wrote: > > On Sat, 22 Sep 2018 15:36:23 -0500 > > Matthew Thode wrote: =20 > > > My hand slipped. What ever happened to assuming the best :( Are you > > > going to ping the list every time my hand slips up and I mistype > > > something? Not sure you'll have time for it :P =20 > >=20 > > Personally, I would love it if more people tried harder to provide > > meaningful commit messages. > >=20 > > "bup" vs "bump" isn't really achieving much, just one of the two are > > substantially more egregious. > >=20 > > Perhaps, if the commit messages were crafted with clarity as their > > intent, the consequence of accidental typos would be much more > > inconsequential. > >=20 > > ( I seriously think we could do with a *little* more chiding here than > > we generally see, but like, I'm typically just biting my tongue every > > time somebody doesn't invest any more effort than to write the word > > "bump" in their text editor when committing with repoman, cos I really > > don't want to be a dick about it. There's room for more than 4 > > characters and a space in the subject, and infinitely more space in the > > body, why do we have to choose the least clear of all options? ) > >=20 > > Occasional accidents are still gonna happen, but it would be nice if we > > didn't define accidents and siblings of accidents as the status quo. > > =20 >=20 > What would you rather see for when a package is bumped (that is, simply > copying the ebuild and editing the keywords)? >=20 I personally try to use something of the form: "Bump version to 12.234.1567" Mostly, because it gives some vaguely useful context when reading a commit summary log, that doesn't necessitate you running "git log -p" or "git diff" to find out what actually changed. This lends itself to good user-feedback mechanisms when the log is relayed via IRC on #gentoo-commits, and allows one to determine what's going on at-a-glance via gitweb. If the version bump is in response to a bug request, I'll try to mention that in the subject too. If I made changes in the ebuild in the bump itself, I'll attempt to describe the nature of those changes (from the perspective of the consumer)' And where possible, I attempt to summarize the nature of the changes between our largest in-tree version and the new version, as far as upstream changes are concerned. Eg: if version went from 1.0 to 1.3, but 1.1-1.2 existed, I'll attempt a summary for the imagined user upgrading from 1.0 to 1.3. If for instance something is added in 1.1 and then redacted in 1.2, there's no need to mention that in 1.0 -> 1.3. I Try to think of it as "a list of reasons why a user might want to upgrade, or might want to avoid upgrading" from a context of "xxx changed, if you were using this your code might break" or "xxx is new, if you need this, you need to upgrade" All of this is "nice to have" stuff I'd try to gently nudge others into the direction of, in effort to provide useful information to not only our users, but to other developers, and our future selves looking back in the history trying to ascertain the importance of a given version. Achieving all of the above is of course not always possible, sometimes there are too many changes to summarize, or upstream is made of too much insane for you to assess the differences, that's life. But you can imagine how I get *just* a little bit frustrated when this is the sort of direction I'm trying to aspire towards, but what I'm seeing on the list is debates about "bup" vs "bump" :) --Sig_/ZBt81zh9RC0l0sDwBRwA9=4 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAluoS2IACgkQda6SGagV g7WLQw//W3J6gDc4l13zGrDilFAX18QjW2HzkcmoMerl9Ko6LrpZl/pBWXslomnD NyrQkLTiMQ0c0pa2PORz2KtaP5LFmedUI004qE9OJ0TGNAqYB8pqlR0dtcur4IPY FP370FTb6d3jTGzBsJucDR6AajvbiLpJyowIlNMXpBMk4cfF2rvzSMaq52NFUKvZ eSWeLFQEtUwwkd6mP6MyKwOEYQVXhCqM6JQMJ8XY2k6c6z5F8FJm6vPHioXCALGq s0NHpU5KGp92OUKiNyjJSIR3q77E10sACaKqjzgICg4k7MEGdsrEbLTISYbISa9P VDD06Lq2tTV3ZZ+LWpM+pPrihPbP1lxM2mRCjT58HbjlzMaUTaeJ7OxtTiVF7NhK pmzUJqhD35AeCnB1ScG87djaoAzGQ/L+BVWxlo31soyP5MiazdSibly15escMgWW 3odx2DWmfqc9mIKp3JtXjRoFYahL4BvUY/h7Twtj1+IG+xzM5DrwO5u3uZI40J6A rrzHl6sjF1lZibTZ9gFS8pj3IefttS12NTuYeSNZcFX2DytH/29+IfVOoiEjlifl 2xaTjiSZsmcBBQeIA/8HJJOQSNSYdsi9FZb5lB42Dy6R3SP3eDXldqzjvhLKPUoU 2YHZhbrxcEu+KZuhHhicYil+62BcsWGfjbRVyO1USXTfLXvmwTc= =HaKO -----END PGP SIGNATURE----- --Sig_/ZBt81zh9RC0l0sDwBRwA9=4--