From: Simon Marchi <simark@simark.ca>
To: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFA] Have 'thread|frame apply' style their output.
Date: Sun, 28 Apr 2019 14:59:00 -0000 [thread overview]
Message-ID: <047cf071238a47631379c72a2ee170b5@simark.ca> (raw)
In-Reply-To: <1556428722.1511.1.camel@skynet.be>
On 2019-04-28 01:18, Philippe Waroquiers wrote:
> Hello Simon,
> I have just pushed a follow-up to fix the above.
Thanks!
> At the same time, I saw that I forgot to copy/paste the ChangeLog
> from the commit message to the ChangeLog file.
> I fixed this also.
>
> Sorry for the breakage, I have now added --with-guile as default.
>
> Philippe
>
> NB: this ChangeLog is a nightmare to produce (and maintain
> for each version of a patch). And then still a final copy-paste
> from commit log to the real file to not forget.
> (to avoid merge conflicts).
>
> The only good point of ChangeLog is that this is reminding me of
> the 80s, when I was young, and there was no good source control system,
> and we were all proudly indicating in each source file what we changed
> at what date :).
>
> This ChangeLog is just slowing down the free software development
> by moving away resources to useless painful administrative activities.
> This must have been invented by an evil person that hates free software
> :).
This is my personal opinion too.
There was a push to make them not mandatory for GNU projects. If you
have too much free time on your hand, you can read what lead up to and
the follow-up to this thread:
http://lists.gnu.org/archive/html/bug-standards/2017-11/msg00005.html
In short, some people claim that the git history is not sufficient to
fill the gap that would be left by removing ChangeLogs. So the
compromise is that if someone writes a good enough program to
automatically generate the ChangeLog entries, we can use that and not
have to write them by hand... I am not sure if such a program will
really ever be "good enough" so that we can use it, so we are kind of
stuck there.
> I think I will now type it directly (but at the end of
> the file), and move it at the beginning of the file just before
> pushing. At least, it reduces the nr of operations
> (and I have a script I am running to automatically do some checks
> before pushing, that I will make detect I forgot to move it).
prev parent reply other threads:[~2019-04-28 14:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-09 22:59 Philippe Waroquiers
2019-03-22 5:31 ` PING " Philippe Waroquiers
2019-03-29 8:01 ` PING^2 " Philippe Waroquiers
2019-04-18 4:12 ` PING^3 " Philippe Waroquiers
2019-04-25 15:46 ` Tom Tromey
2019-04-27 12:42 ` Philippe Waroquiers
2019-04-27 19:19 ` Simon Marchi
2019-04-28 5:19 ` Philippe Waroquiers
2019-04-28 14:59 ` Simon Marchi [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=047cf071238a47631379c72a2ee170b5@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=philippe.waroquiers@skynet.be \
--cc=tom@tromey.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox