[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: What means bup?
From:       Kent Fredric <kentnl () gentoo ! org>
Date:       2018-09-27 13:43:23
Message-ID: 20180928014323.2cd33680 () katipo2 ! lan
[Download RAW message or body]


On Mon, 24 Sep 2018 10:59:40 -0400
Alec Warner <antarus@gentoo.org> wrote:

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

Well, yes, there's a limit to the summary length anyway that repoman
enforces ;)

But the point being to *maximise* the use of this "summary" message,
and make good use of the "body" section of the "commit message".

And there's already annotations for this in the body section,

   Bug: https://bugs.gentoo.org/123456

( This references but does not close )

   Closes: https://bugs.gentoo.org/123456

( This closes )

In the summary line, you don't really need to clarify if it closes or not.

Much of the benefit is knowing wilikins will see that message in
#gentoo-commits, and then cite the entire bug summary in response.
( Including its current status of closed/open )

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

See above.

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

Generated changelogs are something that we were supposed to have, but
they got culled from rsync tree for a host of reasons. ( One being they
weren't generated in reverse-chronological order, which made them a
boon to read )

But I still find having it documented useful even without this feature
( In the long term, we may find our users collectively start to prefer
git to rsync, and having good change notes makes that even better for
them )



[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]