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" :)
>
>
