From: Daniel Turull <daniel.turull@ericsson.com>
To: "richard.purdie@linuxfoundation.org"
<richard.purdie@linuxfoundation.org>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Cc: "ross.burton@arm.com" <ross.burton@arm.com>,
"mathieu.dubois-briand@bootlin.com"
<mathieu.dubois-briand@bootlin.com>
Subject: Re: A walkthrough of some of the challenges with auto generated changelogs
Date: Mon, 7 Sep 2026 13:04:20 +0000 [thread overview]
Message-ID: <67f2d11a4b024b10670005248f48e3e94a879f92.camel@ericsson.com> (raw)
In-Reply-To: <122ee46d60d45c5a014a8cd40158a008ecd29744.camel@linuxfoundation.org>
On Fri, 2026-09-04 at 18:07 +0100, Richard Purdie wrote:
> On Thu, 2026-09-03 at 07:55 +0000, Daniel Turull wrote:
> > Thanks for the input.
> >
> > On Wed, 2026-09-02 at 12:47 +0100, Richard Purdie wrote:
> > > Everyone keeps telling me how great these auto generated change logs
> > > are and yes, they can be helpful but they are also piling pressure on
> > > me as everyone has their own preferences and personal "triggers" for
> > > issues. I keep getting told how XXX shouldn't have merged without YYY
> > > being tweaked but the tweaks/triggers vary per person. I also get told
> > > a changelog is better than none and that we shouldn't be spending time
> > > on it. I can't win.
> >
> > Maybe I should write a proposal on what to include in the commit messages
> > regarding the changelog changes?
> >
> > My opinion is also the latter. A changelog is better than none and that we
> > shouldn't be spending time on it. There is always the original changelog if
> > people is interested in all changes.
> >
> > The original intent was for the stable releases, where is more important to
> > know
> > what has changed.
>
> Agreed, it definitely is useful but I did want to make sure people
> could see the other side of this too. None of this was meant as
> critisism, more just open feedback on how it 'feels' having used it for
> a while. Some of the implications are not quite what I'd foreseen.
>
No worries. I took it at as open feedback, not criticism.
Cheers,
Daniel
> >
prev parent reply other threads:[~2026-09-07 13:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 11:47 A walkthrough of some of the challenges with auto generated changelogs Richard Purdie
2026-09-03 7:55 ` Daniel Turull
2026-09-04 17:07 ` Richard Purdie
2026-09-07 13:04 ` Daniel Turull [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67f2d11a4b024b10670005248f48e3e94a879f92.camel@ericsson.com \
--to=daniel.turull@ericsson.com \
--cc=mathieu.dubois-briand@bootlin.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=ross.burton@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.