From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Eli Zaretskii , drow@mvista.com Cc: gdb-patches@sources.redhat.com Subject: Re: What is on the 5.1 branch; Was: [rfc] Re: read_register_bytes() bug; was my Regcache revamp Date: Tue, 21 Aug 2001 06:52:00 -0000 Message-id: <3B815B50.6070603@cygnus.com> References: <3B7EAF09.4010801@cygnus.com> <3B7ED838.70607@cygnus.com> <9743-Sun19Aug2001093055+0300-eliz@is.elta.co.il> <3B80A35B.3060504@cygnus.com> <7263-Mon20Aug2001090940+0300-eliz@is.elta.co.il> <20010819231747.A15746@nevyn.them.org> <8011-Mon20Aug2001120810+0300-eliz@is.elta.co.il> X-SW-Source: 2001-08/msg00239.html > Date: Sun, 19 Aug 2001 23:17:47 -0700 >> From: Daniel Jacobowitz > >> > >> > Why aren't the entries there in chronological order? > >> >> I tend to date ChangeLog entries with the day the patch was last >> modified, not the day it was committed. > > > I think this is wrong: the logs should reflect the commit time, and if > they aren't chronologically increasing, it's hard to find a specific > entry and even harder to figure out which change came after which, > without resorting to CVS. Yes, Eli's correct. Allowing for timezones and approval latency a few days here or there is ok. Anyway, this is why I personally adopted the convention: 2001-07-28 Andrew Cagney Fix some PID/TPID fallout for HP/UX. From 2001-07-22 Rodney Brown : * infttrace.c (ptrace_wait): Match external declaration, and match target_post_wait declaration. so that the original date and the time of commit are retained. This isn't a GNU standard. Andrew