This is the mail archive of the
mailing list for the glibc project.
Re: How to upstream glibc patch?
- From: Hongbo Zhang <hongbo dot zhang at linaro dot org>
- To: Arjun Shankar <arjun dot is at lostca dot se>
- Cc: libc-help at sourceware dot org
- Date: Mon, 11 Jun 2018 15:18:06 +0800
- Subject: Re: How to upstream glibc patch?
- References: <CAHmQWvBkcvMBTktFstGUB7vO8QTxeecO0x2oK=_PSEto-Or=oA@mail.gmail.com> <20180608121521.GA46220@aloka.lostca.se>
Thank you very much for spending time on typing the explanation, it is
great, get it.
On 8 June 2018 at 20:15, Arjun Shankar <firstname.lastname@example.org> wrote:
> > but something is still unclear for me, especially the changelog.
> > for example I do like this:
> > git format-patch -1
> > ../gcc/contrib/mklog my-patch-file
> > then I get:
> > Unknown ChangeLog:
> > 2018-06-08 Hongbo Zhang <email@example.com>
> > * sysdeps/aarch64/multiarch/memcpy.c (libc_ifunc):
> > * sysdeps/aarch64/multiarch/memmove.c (libc_ifunc):
> > * sysdeps/aarch64/multiarch/memset.c (libc_ifunc):
> > * sysdeps/unix/sysv/linux/aarch64/cpu-features.c:
> > * sysdeps/unix/sysv/linux/aarch64/cpu-features.h (IS_PHECDA):
> > I copy these texts into my patch file as a part of commit message?
> The ChangeLog isn't supposed to become part of the commit message. Good
> emails sent to the list look something like this:
> Subject: [PATCH] This becomes the first line of the commit [BZ #BUGNUMBER]
> Here, the submitter explains the change in detail. They may use one or more
> paragraphs to explain the change. This content becomes the remaining body
> the commit message.
> Next the submitter may make a claim about test results when relevant. The
> maintainer checking in your patch will often not add this to the commit
> YYYY-MM-DD John Doe <emailaddress>
> [BZ #BUGNUMBER]
> * foo/bar.c (foobar): New function.
> * foo/zoo.c (fizzbuzz): Check for error before returning.
> Potentially more notes may follow. e.g. sometimes, when I re-submit a patch
> after incorporating review comments, I put a link to discussions around the
> older version of the patch here.
> <patch content goes here>
> The bug numbers in the subject line and ChangeLog are only needed when the
> change corresponds to a reported bug or is big enough to be assigned a bug.
> Note the TAB characters in the ChangeLog.
> What a maintainer does is (either by hand or perhaps with tooling): they
> copy the ChangeLog entry to the top of the "ChangeLog" file maintained in
> the glibc source tree, and commit it along with the rest of the patch
> > I see it is blank after each colon in the changlog generated above,
> > I add some message manually? or leaving them blank is acceptable?
> You should use the space to explain what actually was changed, in short.
> Typical entries are new functions, variables, files, or their deletions,
> really small summary of how a function was changed, etc. The ChangeLog file
> is for users who don't obtain glibc via git, but download a tarball. In the
> absence of source control, it becomes their primary tool for knowing what
> (in detail) changed in a particular glibc release.
> I expect that what I wrote above is in general, good advice. Not all
> show up in this form, but the above format of email is the one I use, and I
> don't recall any reviewer disliking the formatting or asking for it to be
> changed. Here's the last patch I sent to this list. It should show the
> skeleton I laid out above reproduced in a real example (but literally any
> email from the regular maintainers is a good example):