* Re: Rant about ChangeLog entries and commit messages [not found] <2007-12-02-11-05-39+trackit+sam@rfc1149.net.suse.lists.egcs> @ 2007-12-02 18:33 ` Andi Kleen [not found] ` <jeodd9l7j1.fsf@sykes.suse.de.suse.lists.egcs> [not found] ` <200712022136.57819.ebotcazou@libertysurf.fr.suse.lists.egcs> 2 siblings, 0 replies; 12+ messages in thread From: Andi Kleen @ 2007-12-02 18:33 UTC (permalink / raw) To: Samuel Tardieu; +Cc: gcc Samuel Tardieu <sam@rfc1149.net> writes: > recent ChangeLog entry in gcc/ChangeLog is: From my understanding the gcc changelogs serve two purposes these days: - Force the submitter to read (or rather speed read) the patch again before sending it out. - Serve as a "hash key" to search the gcc-patches archives for the real changelog. The second could be solved far better in many obvious ways, but it's unclear how to replace the first. Linux kernel doesn't have a solution for it. -Andi ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <jeodd9l7j1.fsf@sykes.suse.de.suse.lists.egcs>]
[parent not found: <Pine.GSO.4.61.0712031739500.10932@mulga.csse.unimelb.edu.au.suse.lists.egcs>]
* Re: Rant about ChangeLog entries and commit messages [not found] ` <Pine.GSO.4.61.0712031739500.10932@mulga.csse.unimelb.edu.au.suse.lists.egcs> @ 2007-12-03 12:20 ` Andi Kleen 2007-12-04 4:03 ` Nicholas Nethercote 2007-12-04 10:19 ` Rant about ChangeLog entries and commit messages Robert Kiesling 0 siblings, 2 replies; 12+ messages in thread From: Andi Kleen @ 2007-12-03 12:20 UTC (permalink / raw) To: Nicholas Nethercote; +Cc: gcc Nicholas Nethercote <njn@csse.unimelb.edu.au> writes: > Commit logs are basically invisible; That's just a (fixable) problem in your coding setup. In other projects it is very common to use tools like cvs annotate / cvsps / git blame / git log / etc. to find the reasons for why code is the way it is. In fact in several editors these can be functions on hot keys. Programming is hard enough as is without ignoring such valuable information sources. Don't do it. -Andi ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages 2007-12-03 12:20 ` Andi Kleen @ 2007-12-04 4:03 ` Nicholas Nethercote 2007-12-04 13:05 ` Richard Kenner 2007-12-04 10:19 ` Rant about ChangeLog entries and commit messages Robert Kiesling 1 sibling, 1 reply; 12+ messages in thread From: Nicholas Nethercote @ 2007-12-04 4:03 UTC (permalink / raw) To: Andi Kleen; +Cc: gcc On Mon, 3 Dec 2007, Andi Kleen wrote: >> Commit logs are basically invisible; > > That's just a (fixable) problem in your coding setup. In other > projects it is very common to use tools like cvs annotate / cvsps / > git blame / git log / etc. to find the reasons for why code is the way > it is. In fact in several editors these can be functions on hot > keys. Programming is hard enough as is without ignoring such valuable > information sources. Don't do it. I didn't say you cannot or should not use these tools. But a good comment on a piece of code sure beats a good commit message, which must be looked at separately, and can be fragmented over multiple commits, etc. Nick ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages 2007-12-04 4:03 ` Nicholas Nethercote @ 2007-12-04 13:05 ` Richard Kenner 2008-02-23 9:53 ` Rant about ChangeLog entries and commit messages - better to do something than just complain Tim Josling 0 siblings, 1 reply; 12+ messages in thread From: Richard Kenner @ 2007-12-04 13:05 UTC (permalink / raw) To: njn; +Cc: andi, gcc > I didn't say you cannot or should not use these tools. But a good comment > on a piece of code sure beats a good commit message, which must be looked at > separately, and can be fragmented over multiple commits, etc. I don't see one as "beating" the other because they have very different purposes. Sometimes you need one and sometimes you need the other. The purpose of COMMENTS is to help somebody understand the code as it stands at some point in time. In most cases, that means saying WHAT the code does and WHY (at some level) it does what it does. Once in a while, it also means saying why it DOESN'T do something, for example, if it might appear that there's a simpler way of doing what the code is doing now but it doesn't work for some subtle reason. But it's NOT appropriate to put into comments the historical remark that this code used to have a typo which caused a miscompilation at some specific place. However, the commit log IS the place for that sort of note. My view is that, in general, the comments are usually the most appropriate place to put information about how the code currently works and the commit log is generally the best place for information that contrasts how the code currently works with how it used to work and provides the motivation for making the change. But there are exceptions to both of those generalizations. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages - better to do something than just complain 2007-12-04 13:05 ` Richard Kenner @ 2008-02-23 9:53 ` Tim Josling 2008-02-23 15:17 ` Laurent GUERBY 2008-02-23 15:54 ` Daniel Jacobowitz 0 siblings, 2 replies; 12+ messages in thread From: Tim Josling @ 2008-02-23 9:53 UTC (permalink / raw) To: Richard Kenner; +Cc: njn, andi, gcc On the principle that it's better to do something than just complain... I monitored the time I spent looking for the emails associated with a given patch and I found it takes high single digit minutes to find them. Sometimes you can't find them (which takes a lot longer). I do this a lot. I wrote a little proof-of-concept script to take the mailing list archives and the ChangeLog files and annotate the ChangeLog files with the URLs of the probable email containing the patch. Sample output is here (annotation of the current ChangeLog file). http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcc/gcb/gcc_ChangeLog.txt?revision=1.1&view=markup Or http://tinyurl.com/2v824o Or http://preview.tinyurl.com/2v824o The program is here (not much internal documentation at all). Testing has been limited - in any case, with processing of text written by people, perfection is not possible. http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcc/gcb/gcc_mailscan.rb?revision=1.1&view=markup Or http://tinyurl.com/2yem2u Or http://preview.tinyurl.com/2yem2u It runs in about 25 minutes on my system and uses a few hundred MB of storage. Things I learned: 1. There is a lot of data. It's a good thing Ruby 1.9 is a lot faster than Ruby 1.8. There are over 100 ChangeLog files in the GCC source, with over 600,000 lines in total. The gcc patches mailing list archives are over 2 GB in size, and take a considerable time to download. 2. Most patches to ChangeLog have an identifiable email in the archive. Things get spotty with branches in some cases, also as you go back in time, and also there is a large gap in the email archives from a while back. 3. I think this may be a useful thing. If a place could be found to put the 30MB of files I would be happy to maintain them on a weekly basis or so. Alternatively I could update the ChangeLog files themselves but I have reason to suspect that may not be popular. If nothing else happens I will keep it up-to-date for my own use. Tim Josling On Tue, 2007-12-04 at 08:05 -0500, Richard Kenner wrote: > > I didn't say you cannot or should not use these tools. But a good comment > > on a piece of code sure beats a good commit message, which must be looked at > > separately, and can be fragmented over multiple commits, etc. > > I don't see one as "beating" the other because they have very different > purposes. Sometimes you need one and sometimes you need the other. > > The purpose of COMMENTS is to help somebody understand the code as it > stands at some point in time. In most cases, that means saying WHAT the > code does and WHY (at some level) it does what it does. Once in a while, > it also means saying why it DOESN'T do something, for example, if it might > appear that there's a simpler way of doing what the code is doing now but > it doesn't work for some subtle reason. But it's NOT appropriate to put > into comments the historical remark that this code used to have a typo > which caused a miscompilation at some specific place. However, the commit > log IS the place for that sort of note. > > My view is that, in general, the comments are usually the most appropriate > place to put information about how the code currently works and the commit > log is generally the best place for information that contrasts how the code > currently works with how it used to work and provides the motivation for > making the change. But there are exceptions to both of those generalizations. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages - better to do something than just complain 2008-02-23 9:53 ` Rant about ChangeLog entries and commit messages - better to do something than just complain Tim Josling @ 2008-02-23 15:17 ` Laurent GUERBY 2008-02-23 15:54 ` Daniel Jacobowitz 1 sibling, 0 replies; 12+ messages in thread From: Laurent GUERBY @ 2008-02-23 15:17 UTC (permalink / raw) To: tejgcc; +Cc: Richard Kenner, njn, andi, gcc On Sat, 2008-02-23 at 20:52 +1100, Tim Josling wrote: > 3. I think this may be a useful thing. If a place could be found to put > the 30MB of files I would be happy to maintain them on a weekly basis or > so. Alternatively I could update the ChangeLog files themselves but I > have reason to suspect that may not be popular. > > If nothing else happens I will keep it up-to-date for my own use. Hi, The GCC Compile Farm can host your scripts, download/processing crontab and publish the results on a web site. Instructions on how to apply for a ssh account and misc information about the current farm status are here: http://gcc.gnu.org/wiki/CompileFarm I installed ruby from debian etch on gcc12: guerby@gcc12:~$ ruby --version ruby 1.8.5 (2006-08-25) [x86_64-linux] If you need something else (missing packages, web page, etc...), the ticket tracker is on gna.org: https://gna.org/projects/gcc-cfarm/ Hope this helps, Laurent ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages - better to do something than just complain 2008-02-23 9:53 ` Rant about ChangeLog entries and commit messages - better to do something than just complain Tim Josling 2008-02-23 15:17 ` Laurent GUERBY @ 2008-02-23 15:54 ` Daniel Jacobowitz 2008-02-23 16:00 ` Andi Kleen 1 sibling, 1 reply; 12+ messages in thread From: Daniel Jacobowitz @ 2008-02-23 15:54 UTC (permalink / raw) To: Tim Josling; +Cc: Richard Kenner, njn, andi, gcc On Sat, Feb 23, 2008 at 08:52:41PM +1100, Tim Josling wrote: > I wrote a little proof-of-concept script to take the mailing list > archives and the ChangeLog files and annotate the ChangeLog files with > the URLs of the probable email containing the patch. This is really awesome. Thank you! I hope we can get these hosted and maybe hyperlinked somewhere on a permanent basis. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages - better to do something than just complain 2008-02-23 15:54 ` Daniel Jacobowitz @ 2008-02-23 16:00 ` Andi Kleen 2008-02-28 5:16 ` Alexandre Oliva 0 siblings, 1 reply; 12+ messages in thread From: Andi Kleen @ 2008-02-23 16:00 UTC (permalink / raw) To: Tim Josling, Richard Kenner, njn, andi, gcc On Sat, Feb 23, 2008 at 10:53:53AM -0500, Daniel Jacobowitz wrote: > On Sat, Feb 23, 2008 at 08:52:41PM +1100, Tim Josling wrote: > > I wrote a little proof-of-concept script to take the mailing list > > archives and the ChangeLog files and annotate the ChangeLog files with > > the URLs of the probable email containing the patch. > > This is really awesome. Thank you! I hope we can get these hosted > and maybe hyperlinked somewhere on a permanent basis. Agreed. Even nicer would be if the ChangeLogs in the repository were just updated with this. -Andi ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages - better to do something than just complain 2008-02-23 16:00 ` Andi Kleen @ 2008-02-28 5:16 ` Alexandre Oliva 0 siblings, 0 replies; 12+ messages in thread From: Alexandre Oliva @ 2008-02-28 5:16 UTC (permalink / raw) To: Andi Kleen; +Cc: Tim Josling, Richard Kenner, njn, gcc On Feb 23, 2008, Andi Kleen <andi@firstfloor.org> wrote: > On Sat, Feb 23, 2008 at 10:53:53AM -0500, Daniel Jacobowitz wrote: >> On Sat, Feb 23, 2008 at 08:52:41PM +1100, Tim Josling wrote: >> > I wrote a little proof-of-concept script to take the mailing list >> > archives and the ChangeLog files and annotate the ChangeLog files with >> > the URLs of the probable email containing the patch. >> >> This is really awesome. Thank you! I hope we can get these hosted >> and maybe hyperlinked somewhere on a permanent basis. > Agreed. Even nicer would be if the ChangeLogs in the repository > were just updated with this. +1 Thanks, Tim! Great stuff! -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages 2007-12-03 12:20 ` Andi Kleen 2007-12-04 4:03 ` Nicholas Nethercote @ 2007-12-04 10:19 ` Robert Kiesling 1 sibling, 0 replies; 12+ messages in thread From: Robert Kiesling @ 2007-12-04 10:19 UTC (permalink / raw) To: gcc > Nicholas Nethercote <njn@csse.unimelb.edu.au> writes: > > > Commit logs are basically invisible; > > That's just a (fixable) problem in your coding setup. In other > projects it is very common to use tools like cvs annotate / cvsps / > git blame / git log / etc. to find the reasons for why code is the way > it is. In fact in several editors these can be functions on hot > keys. Programming is hard enough as is without ignoring such valuable > information sources. Don't do it. Unless there's a good reason _not_ to derive from a source, and there are several, most of which require a clean-room approach, or a simulation of it. I'm just now starting to move over to Subversion, and I'm sure it has the same ability, to publish CVS logs, though not via CVS itself. C-x v u :) -- Ctalk Home Page: http://www.ctalklang.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <200712022136.57819.ebotcazou@libertysurf.fr.suse.lists.egcs>]
[parent not found: <4aca3dc20712021240k19f3eae5j66453276179c401a@mail.gmail.com.suse.lists.egcs>]
[parent not found: <200712022355.23871.ebotcazou@libertysurf.fr.suse.lists.egcs>]
[parent not found: <4aca3dc20712021621n39a036d2u21f471f231dfffe@mail.gmail.com.suse.lists.egcs>]
[parent not found: <10712031329.AA20246@vlsi1.ultra.nyu.edu.suse.lists.egcs>]
* Re: Rant about ChangeLog entries and commit messages [not found] ` <10712031329.AA20246@vlsi1.ultra.nyu.edu.suse.lists.egcs> @ 2007-12-03 16:34 ` Andi Kleen 2007-12-03 16:38 ` Richard Kenner 0 siblings, 1 reply; 12+ messages in thread From: Andi Kleen @ 2007-12-03 16:34 UTC (permalink / raw) To: Richard Kenner; +Cc: gcc kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > Yes, but none of those are visible other than to the development community. > People who obtain the source distributions of projects don't get to see > those things. They DO see things like the ChangeLog format and coding > and documentation conventions and THOSE are the things that need to be > common among GNU projects. It would be probably reasonable these days to require of someone who wants to do serious development to just download a SVN checkout for that [or they can use svnweb on http://gcc.gnu.org] -Andi ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rant about ChangeLog entries and commit messages 2007-12-03 16:34 ` Andi Kleen @ 2007-12-03 16:38 ` Richard Kenner 0 siblings, 0 replies; 12+ messages in thread From: Richard Kenner @ 2007-12-03 16:38 UTC (permalink / raw) To: andi; +Cc: gcc > It would be probably reasonable these days to require of someone who > wants to do serious development to just download a SVN checkout > for that [or they can use svnweb on http://gcc.gnu.org] I agree. But I think the idea of the ChangeLog is for somewhere just short of "serious development". I'm not too far from being willing to agree that ChangeLog is now hopelessly anachronistic (though I'm not there yet), but feel that this is really an FSF issue, not a GCC one. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-02-28 5:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <2007-12-02-11-05-39+trackit+sam@rfc1149.net.suse.lists.egcs> 2007-12-02 18:33 ` Rant about ChangeLog entries and commit messages Andi Kleen [not found] ` <jeodd9l7j1.fsf@sykes.suse.de.suse.lists.egcs> [not found] ` <Pine.GSO.4.61.0712031739500.10932@mulga.csse.unimelb.edu.au.suse.lists.egcs> 2007-12-03 12:20 ` Andi Kleen 2007-12-04 4:03 ` Nicholas Nethercote 2007-12-04 13:05 ` Richard Kenner 2008-02-23 9:53 ` Rant about ChangeLog entries and commit messages - better to do something than just complain Tim Josling 2008-02-23 15:17 ` Laurent GUERBY 2008-02-23 15:54 ` Daniel Jacobowitz 2008-02-23 16:00 ` Andi Kleen 2008-02-28 5:16 ` Alexandre Oliva 2007-12-04 10:19 ` Rant about ChangeLog entries and commit messages Robert Kiesling [not found] ` <200712022136.57819.ebotcazou@libertysurf.fr.suse.lists.egcs> [not found] ` <4aca3dc20712021240k19f3eae5j66453276179c401a@mail.gmail.com.suse.lists.egcs> [not found] ` <200712022355.23871.ebotcazou@libertysurf.fr.suse.lists.egcs> [not found] ` <4aca3dc20712021621n39a036d2u21f471f231dfffe@mail.gmail.com.suse.lists.egcs> [not found] ` <10712031329.AA20246@vlsi1.ultra.nyu.edu.suse.lists.egcs> 2007-12-03 16:34 ` Andi Kleen 2007-12-03 16:38 ` Richard Kenner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).