This is the mail archive of the
mailing list for the glibc project.
Re: When can we stop writing ChangeLogs?
- From: "Maciej W. Rozycki" <macro at wdc dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at gotplt dot org>, Carlos O'Donell <carlos at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Mon, 30 Sep 2019 20:52:24 +0100 (BST)
- Subject: Re: When can we stop writing ChangeLogs?
- Ironport-sdr: 0PC33sUmXDL8FVPnMIJGPpFHw3+GzsEH/VqX4E1jM78utpYVQ3F2s2ONXm3fVkWWRHrz8W9b7m jPg1FnNJd/I2aIev3XGz6a20l+Qlx4OShdegRhfP/kkw0kuz3gizvHM6FdRqWVORTYI6cw5ITC IPfEBv4zhKDOTPBEIB7Kg4qz4huI2L6NNxT00Frp17n/Hlx93oRGOE1j9PM1b/SL9RuZO8sPqk 4QUwc9PM0CVW+ZPy1o0WYPQf2ixqIFmqaSVNpRUELdZjKlxQ1hFOAooUgE45hkiHowWfncUv5f QE8=
- Ironport-sdr: pPTeyMUQVgPLaSImMExCAEXZLDOPhWvJZ/CBaJStlF1Qyft4XYl4gTNbL7j4mdsPOMkd9ygvAh iwz19NNBkst/r/qLScMlC4C8TD8A1/UD27xmplmvgPPTPuESgXbY7zdfuaj8uSRYVsSSKxux6r PTp/nZTxIijJSYhT7KNqrNXVP5nhHJzeqBejbd5dKyL1Hk3lE8I8T/rKr5Zm03/jbtJJOO2TF8 AkKlkY2AOjwKr52wFYDmi8ZR3eJOWqFZkD1MRWCGsZy2MBcbOMse0d4pL5ElofaA6QerDecFi9 XwKO0psZHpWiMElI/cASDCJX
- Ironport-sdr: bVnLr/iqSr+ohBlvMydWRpoT1qMVcjc/Qs7RMhrUdHAWYjCptHbcZkj1tQ3ro9KfpwN2xhxLFB VUY1JlCLituWtY6Plna/LoCvZ+lKiPXWyNwrZNcyywoMVNSKtkUVzyk/AJ6Sj95O6XJaNObofp ogTV0c1PXHc5oIlNkWeltL66RLYXF0EQNCXbN4mza6DTZ2K6o50mbH9563fUqccHh45w0O/daI 8U0AEAGv2rctX1XnYe/IG0C0Cjl/fHoQ7u0MCN0uisv5soJ+JhjFjmdZcE/XDRInwrH788b2f2 jgU=
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
- Wdcironportexception: Internal
On Mon, 30 Sep 2019, Florian Weimer wrote:
> > We have git commit messages documented as one of the things that a
> > contributor needs to pay attention to in the Contributor Checklist, but
> > enforcement of review has been sketchy. I can't think of a better
> > solution at the moment than a review tool that requires reviewers to
> > flag the commit message as being OK.
> I'm looking for something far simpler here?a script that submitters and
> reviewers can run to see what's going to be committed, and some level of
> project consensus that this is how patches should be posted.
Hmm, isn't it the GIT format that we've been using? I.e. the `Subject:'
header is the commit heading, anything in the e-mail body up to the first
`---' marker is the commit description (including any `From:' authorship
override in the first line), an optional section with further comments
follows (e.g. notes on the test procedure that was used, etc.) that is not
going to be committed and ends with a second `---' marker, and anything
that follows is a patch.
This can be easily prepared with `git format-patch'; of course any
additional comments have to be filled in. Once reviewed an e-mail that
has been so formatted can be commited with `git am' then.
> Hopefully we can get to this point while still using email for patch
> submission and review.
With the GIT format in use `git send-email' can of course be used
directly for submissions.