Re: [v5][PATCH] busybox: update to 1.28.4

[Peter Kjellerstedt <peter.kjellerstedt@axis.com>]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Marko, Peter
> Sent: den 11 juni 2018 16:58
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [v5][PATCH] busybox: update to 1.28.4
> 
> On 06/11/2018 04:43 PM, akuster808 wrote:
> > On 06/11/2018 01:45 AM, Peter Kjellerstedt wrote:
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> >> Of Armin Kuster
> >> Sent: den 11 juni 2018 06:18
> >> To: akuster808@gmail.com; openembedded-core@lists.openembedded.org
> >> Subject: [OE-core] [v5][PATCH] busybox: update to 1.28.4
> >>
> >> refactored busybox-udhcpc-no_deconfig.patch for this update
> >> updated 1.28.3
> >>
> >> [v1]
> >> removed patches included in update:
> >> busybox/CVE-2011-5325.patch
> >> busybox/CVE-2017-15873.patch
> >> busybox/busybox-CVE-2017-16544.patch
> >>
> >> [v2]
> >> Add back busybox-udhcpc-no_deconfig.patch ti SRC_URI, missed earlier
> >>
> >> [v3]
> >> Update defconfig based on feedback
> >>
> >> [v4]
> >> Decided to update again.
> >> 1.28.4
> >>
> >> [v5]
> >> rebased change do to changes in master
> >> squashed .cfg into defconfig and remove files
> >> Delete busybox-fix-lzma-segfaults.patch which is included in updated.
> >>
> >> Signed-off-by: Armin Kuster <akuster808@gmail.com>
> > 
> > The commit message should be rewritten to document the final commit,
> > without any patch series references. They belong after --- below.
> >
> > Done that before and folks complained so I started included with
> > files got removed. May I suggest updating the process so we can be
> > consistent.
> >
> > - armin

I am not saying you should leave out information from the commit 
message about what the patch changes, it should just be written 
(and rewritten for each patch version if necessary) so that it 
documents the last version of the patch. Any information about 
what changed between patch versions should go below the --- (or 
in the cover letter) as that is only relevant for the patch 
review process. Once the commit is integrated into the target 
branch, the patch versions no longer exist and having references 
to them in the commit message then only leads to confusion.

> Isn't cover letter the place to put these "history" comments?
> Commit message should contain just normal change description.
> 
> Peter

If there is a cover letter, then that is probably preferred, 
otherwise after the --- in the respective patches.

//Peter