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 C6B64138239 for ; Mon, 24 Sep 2018 14:59:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 846A3E098A; Mon, 24 Sep 2018 14:59:55 +0000 (UTC) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 F1742E0923 for ; Mon, 24 Sep 2018 14:59:54 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id j62-v6so16546493edd.7 for ; Mon, 24 Sep 2018 07:59:54 -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=OWGyuADOezAF5cfNH/RbOyhEiwjK8wnf0GJxra3QFss=; b=kkCkiMmHwd9HCd3gPqAD5FBjg4RSFkmyYFnFHNaILezPAhzgCWWC3cHfOAylbNk/Zk OKzxQupTOm8qv6UYl7n3FpvGpP0oymmK6TG1bb7Q+Tn9F9qXfKdvnMFIjyg+IC5Wk4kv UvvKdr0XYawOpILHU2EfSKYTlLK7Z3cHbp/YDDnBne8SOUCYO+G9NgRR1w8fEplYsLEZ 8gSIumlye84jpievvQfPg4fjW5b4nf8AuabO1dg8PoZ9yQfXtvqYiOK+KZSJrnvN1+L/ fsUWJiRZKPw/2iS4Ka3HFStinPxDvgDkmuDn79lIPm2aPzeKHLsiAEsF2CxRMYfCFCLc M7Nw== X-Gm-Message-State: ABuFfojDVjNASIrkVwyj/qMq+SgDMd4uSSLbjcth5PDBl3M6BlMKW2iu Gwc5jMLFNRrePfNsfBzK2u6LmE3fTV6TyAkD7oHhB8is X-Google-Smtp-Source: ACcGV61thHNQooNCV3g2Dqkyx0jKPZ3qRYH9laxBKaLZi11UxlYw/qwbwG0raZN5/mxnGN74JPsdrwZ9tLrSbRGYDsU= X-Received: by 2002:a50:8f05:: with SMTP id 5-v6mr17538946edy.192.1537801192823; Mon, 24 Sep 2018 07:59:52 -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 MIME-Version: 1.0 References: <2118089b-4d6d-0a89-ce78-8d5597fb0141@gentoo.org> <20180718072657.fnz45gc44v3m4n6v@gentoo.org> <20180922203623.5ls6dcc73rifhuo5@gentoo.org> <20180924092757.5c714f9d@katipo2.lan> <20180923224527.y622ftpldrm7td2x@gentoo.org> <20180924142629.5483118a@katipo2.lan> In-Reply-To: <20180924142629.5483118a@katipo2.lan> From: Alec Warner Date: Mon, 24 Sep 2018 10:59:40 -0400 Message-ID: Subject: Re: [gentoo-dev] Re: What means bup? To: Gentoo Dev Content-Type: multipart/alternative; boundary="000000000000d5749d05769f3d78" X-Archives-Salt: 99f65a84-1158-4dee-b3d8-2b4cc64eccf7 X-Archives-Hash: c317abcb6c89ee53cac74cbebe423288 --000000000000d5749d05769f3d78 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 23, 2018 at 10:27 PM Kent Fredric wrote: > 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: > > > > 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 > > > > > > Personally, I would love it if more people tried harder to provide > > > meaningful commit messages. > > > > > > "bup" vs "bump" isn't really achieving much, just one of the two are > > > substantially more egregious. > > > > > > Perhaps, if the commit messages were crafted with clarity as their > > > intent, the consequence of accidental typos would be much more > > > inconsequential. > > > > > > ( 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? ) > > > > > > 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. > > > > > > > What would you rather see for when a package is bumped (that is, simply > > copying the ebuild and editing the keywords)? > > > > 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. > So e.g.: "Bump to x.y.z for bug 12345"? Is there an annotation for "this commit is relevant to bug X, but does not close bug X?" I'm less sure we need the metadata all in the summary (because its supposed to be a summary.) If the commits are annotated (Closes: bugX, BugRef: bugX...) we can amend the tools to look at the annotatoins and not hand parse the summary. It also helps for linkification. > > 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)' > You don't do that in the shortlog though..right? There is very little room. > > 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. > Just for clarity, this all sounds like "changelog" stuff; are we still generating changelogs from git commit descriptions? If so, this all seems on the up and up to me. > > 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" :) > > --000000000000d5749d05769f3d78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Sep 23, 2018 at 10:27 PM Kent Fredric <kentnl@gentoo.org> wrote:
On Sun, 23 Sep 2018 17:45:27 -0500
Matthew Thode <prometheanfire@gentoo.org> wrote:

> On 18-09-24 09:27:57, Kent Fredric wrote:
> > On Sat, 22 Sep 2018 15:36:23 -0500
> > Matthew Thode <prometheanfire@gentoo.org> wrote:=C2=A0
> > > My hand slipped.=C2=A0 What ever happened to assuming the be= st :(=C2=A0 Are you
> > > going to ping the list every time my hand slips up and I mis= type
> > > something?=C2=A0 Not sure you'll have time for it :P=C2= =A0
> >
> > Personally, I would love it if more people tried harder to provid= e
> > meaningful commit messages.
> >
> > "bup" vs "bump" isn't really achieving mu= ch, just one of the two are
> > substantially more egregious.
> >
> > Perhaps, if the commit messages were crafted with clarity as thei= r
> > intent, the consequence of accidental typos would be much more > > inconsequential.
> >
> > ( I seriously think we could do with a *little* more chiding here= than
> > we generally see, but like, I'm typically just biting my tong= ue every
> > time somebody doesn't invest any more effort than to write th= e word
> > "bump" in their text editor when committing with repoma= n, cos I really
> > don't want to be a dick about it. There's room for more t= han 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? )<= br> > >
> > Occasional accidents are still gonna happen, but it would be nice= if we
> > didn't define accidents and siblings of accidents as the stat= us quo.
> >=C2=A0 =C2=A0
>
> What would you rather see for when a package is bumped (that is, simpl= y
> copying the ebuild and editing the keywords)?
>

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<= br> 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.

So e.g= .:

"Bump to x.y.z for bug 12345"?
<= div>
Is there an annotation for "this commit is relevant= to bug X, but does not close bug X?"

I'm= less sure we need the metadata all in the summary (because its supposed to= be a summary.)
If the commits are annotated (Closes: bugX, BugRe= f: bugX...) we can amend the tools to look at the annotatoins and not hand = parse the summary.
It also helps for linkification.
=C2= =A0

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)'

You don't do that in= the shortlog though..right? There is very little room.
=C2=A0

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 o= thers 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.

Just for clarity, this all sounds like "chang= elog" stuff; are we still generating changelogs from git commit descri= ptions? If so, this all seems on the up and up to me.
=C2=A0
<= /div>

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" :)<= br>
--000000000000d5749d05769f3d78--