This is the mail archive of the
mailing list for the glibc project.
Re: When can we stop writing ChangeLogs?
- From: Florian Weimer <fweimer at redhat dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 02 Oct 2019 11:30:15 +0200
- Subject: Re: When can we stop writing ChangeLogs?
- 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> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
* Florian Weimer:
> * Joseph Myers:
>> On Mon, 30 Sep 2019, Florian Weimer wrote:
>>> 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.
>> I suggest that should be "git am", as an existing known format for email
>> patch submissions, for any case except where the patch has already been
>> committed (and really "git am" format could probably be used there as
>> well), the patch would be excessively large (whether because of large
>> generated files or otherwise) or the patch contains mixed character sets
>> which require it to be attached in compressed form to avoid it being
>> mangled. We can discuss details regarding e.g. scissors lines, but I
>> think we should still aim for patch submissions that are valid for "git
>> am" in some form - and in particular, that use "git am" markings to
>> separate the commit message from other remarks (e.g. differences between
>> revisions of the patch) that are not intended as part of the commit
> I'm fine with “git am” input, as long as there is a reliable way to
> extract the commit, as it would be committed if you had a matching tree.
> I do not want to go hunting for the matching in every case, particularly
> for a series of patches.
> Do you think that the attached script might work?
It does not work. We need an actual patch parser because people put
random stuff before the actual patch, as suggested by the git am format.