On Feb 23, 2008, Andi Kleen <[EMAIL PROTECTED]> 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 a
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 prob
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 ho
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
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 wrot
On Dec 25, 2007, Tim Josling <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote:
>> ... a good example of compliance with the GPL:
>> 5. Conveying Modified Source Versions.
>>
>> a) The work must carry prominent notices stating that you modified
>> it, and givi
> >> (Minor quibble) As copyright owner of GCC, the FSF is not bound by the
> >> conditions of the licence it grants in the same way as licencees are
> >> bound. So I don't think this provision in itself would mandate that
> >> those who have copyright assignments to the FSF record their changes.
>
Richard Kenner wrote:
(Minor quibble) As copyright owner of GCC, the FSF is not bound by the
conditions of the licence it grants in the same way as licencees are
bound. So I don't think this provision in itself would mandate that
those who have copyright assignments to the FSF record their change
> (Minor quibble) As copyright owner of GCC, the FSF is not bound by the
> conditions of the licence it grants in the same way as licencees are
> bound. So I don't think this provision in itself would mandate that
> those who have copyright assignments to the FSF record their changes.
I was hoping
On Dec 25, 2007 1:57 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote:
> > On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
> >
> > > In my view, ChangeLog is mostly "write-only" from a developer's
> > > perspective. It's a document th
On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote:
> On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
>
> > In my view, ChangeLog is mostly "write-only" from a developer's
> > perspective. It's a document that the GNU project requires us to
> produce
> > for
>
> ... a good examp
On 12/16/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 16, 2007, NightStrike <[EMAIL PROTECTED]> wrote:
>
> > On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> ... a good example of compliance with the GPL:
> >>
> >> 5. Conveying Modified Source Versions.
> >>
> >> a) The work
On Dec 16, 2007, NightStrike <[EMAIL PROTECTED]> wrote:
> On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> ... a good example of compliance with the GPL:
>>
>> 5. Conveying Modified Source Versions.
>>
>> a) The work must carry prominent notices stating that you modified
>> it, and giv
On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
>
> > In my view, ChangeLog is mostly "write-only" from a developer's
> > perspective. It's a document that the GNU project requires us to produce
> > for
>
> ... a good example of
On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
> In my view, ChangeLog is mostly "write-only" from a developer's
> perspective. It's a document that the GNU project requires us to produce
> for
... a good example of compliance with the GPL:
5. Conveying Modified Source Versions.
Ben Elliston <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-05 at 18:35 -0500, Daniel Berlin wrote:
>
>> svn propedit --revision svn:log
>
> OK, well, it used to be a bit trickier in CVS .. :-)
In CVS it's just a cvs admin -m as well.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
Su
Ben Elliston wrote:
Something else that hasn't been raised is that ChangeLogs can be
revised. We often see people making mistakes with their ChangeLog
entries, but since the ChangeLog is versioned, they can revise it. If
you screw up a commit message, it's much harder to fix it (and a purist
m
On Wed, 2007-12-05 at 18:35 -0500, Daniel Berlin wrote:
> svn propedit --revision svn:log
OK, well, it used to be a bit trickier in CVS .. :-)
Ben
On Dec 5, 2007 6:15 PM, Ben Elliston <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
>
> > First, continuing to have good quality messages. Right now at the
> > very least you get a (semi-) accurate record of what was touched.
> > I've seen plenty of ChangeLog-les
On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
> First, continuing to have good quality messages. Right now at the
> very least you get a (semi-) accurate record of what was touched.
> I've seen plenty of ChangeLog-less projects out there than end up with
> commits like "fixed a bug", or ev
On Mon, 2007-12-03 at 08:29 -0500, Richard Kenner wrote:
> > Sorry, but again, this is not a good enough justification to me.
> > We do a lot of things different than "The GNU Project".
> > So do plenty of parts of the "official GNU project".
> > They use different coding standards, bug tracking s
> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes:
Diego> I'm not sure people will want to drop ChangeLogs anytime soon. I
Diego> don't find them all that useful, but I *have* used them extensively
Diego> when doing archeology. It gives you the initial thread to pull when
Diego> finding
> 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
purp
> Nicholas Nethercote <[EMAIL PROTECTED]> 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 th
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
On Mon, 2007-12-03 at 13:58 -0500, Diego Novillo wrote:
> On 12/03/07 13:50, Richard Kenner wrote:
> >> I guess that could work, but that wouldn't give a way into the history
> >> for the change. Several times there is a post-mortem discussion on the
> >> patch, leading to more patches.
> >
> >
On 12/03/07 13:50, Richard Kenner wrote:
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mortem discussion on the
patch, leading to more patches.
How about both?
Sure.
Diego.
> I guess that could work, but that wouldn't give a way into the history
> for the change. Several times there is a post-mortem discussion on the
> patch, leading to more patches.
How about both?
> I'd much prefer the text from the mail message be repeated in the commit
> log. Removes one step of indirection both when writing and reading the log.
I would as well. Especially if you're trying to scan a large part of
the log looking for something.
Bernd Schmidt wrote:
I'd much prefer the text from the mail message be repeated in the commit
log. Removes one step of indirection both when writing and reading the log.
I guess that could work, but that wouldn't give a way into the history
for the change. Several times there is a post-mort
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Diego Novillo wrote:
> > The history is something one finds on the mailing lists. So, my
> > proposal is to add a commit-time check that makes sure that the commit
> > message contains a URL to the message describing the change. IIUC, such
> > check sh
Diego Novillo wrote:
> The history is something one finds on the mailing lists. So, my
> proposal is to add a commit-time check that makes sure that the commit
> message contains a URL to the message describing the change. IIUC, such
> check shouldn't be hard to implement (Dan?)
I'd much prefer
> I'm not sure people will want to drop ChangeLogs anytime soon. I don't
> find them all that useful, but I *have* used them extensively when doing
> archeology. It gives you the initial thread to pull when finding out
> about changes.
>
> What I *do* miss a lot is a an easier way to link fro
On 12/02/07 05:05, Samuel Tardieu wrote:
Maybe we should consider dropping ChangeLogs and using better checkin
messages.
I'm not sure people will want to drop ChangeLogs anytime soon. I don't
find them all that useful, but I *have* used them extensively when doing
archeology. It gives you
Robert Kiesling wrote:
That's because, although the GNU project strictly - and correctly,
experience has shown - monitors its code base, with the propagation
of the Free Software development model, newer Free Software
contributors who maintain their code on sites like sourceforge.net,
are sub
[ Charset ISO-8859-1 unsupported, converting... ]
> On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > Sorry, but again, this is not a good enough justification to me.
> > > We do a lot of things different than "The GNU Project".
> > > So do plenty of parts of the "official GNU project".
>
> 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".
[EMAIL PROTECTED] (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 conventio
> Except they aren't, across large parts of the GNU project.
>
> You may find it the same in the "traditional" parts of the GNU project
> (IE coreutils, emacs, etc).
> It's certainly not the same across any of the newer parts of the GNU project.
Perhaps, but GCC has always been considered, like e
On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Sorry, but again, this is not a good enough justification to me.
> > We do a lot of things different than "The GNU Project".
> > So do plenty of parts of the "official GNU project".
> > They use different coding standards, bug tracking syste
> There are in fact, already programs that will generate GNU format
> changelogs from svn log (see http://ch.tudelft.nl/~arthur/svn2cl/)
> It would be very easy to run these as part of the release process.
Sure, but I think that's bad for this project since I support the idea
that the svn log shou
> Sorry, but again, this is not a good enough justification to me.
> We do a lot of things different than "The GNU Project".
> So do plenty of parts of the "official GNU project".
> They use different coding standards, bug tracking systems, version
> control systems, checkin policies, etc, than eac
Nicholas Nethercote <[EMAIL PROTECTED]> 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. I
Nicholas Nethercote <[EMAIL PROTECTED]> writes:
> On Sun, 2 Dec 2007, Andreas Schwab wrote:
>
>>> | 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
>>> |
>>> | * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
>>> | flag.
>>>
>>> How could a newcomer guess why the gcc_
On Sun, 2 Dec 2007, Andreas Schwab wrote:
| 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
|
| * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
| flag.
How could a newcomer guess why the gcc_force_collect flag needs to be
reset?
That is supposed to be written in
> If you have a better justification, i'd love to hear it.
Justification for what? I only tried to explain to Sam why we do things the
way we do, I didn't write the GNU Coding Standards either.
--
Eric Botcazou
> In the Ada revision histories, we have always given the what-and-the-why
> (and if necessary the why-not), and they have proved very helpful, I
> always found the RH's for gigi (done in the gcc style, much less helpful
> because they omitted the why).
Sorry, that's simply not true, the ChangeLog
On 12/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > If all the changelog entry says is something like
> >
> > (xyz): new function
> >
> > I don't see much point, since a diff can always easily tell
> > you *what* was changed.
>
> The point is that, by just looking at the ChangeLog, you can te
> If all the changelog entry says is something like
>
> (xyz): new function
>
> I don't see much point, since a diff can always easily tell
> you *what* was changed.
The point is that, by just looking at the ChangeLog, you can tell when
xyz was introduced and by whom. I've used that quite a num
> Having said that, I find the lack of rationale for some changes to be a
> bit irritating. I know that this should be done through code comments,
> but those are often made across the changeset and in different files.
And it's often not appropriate to put the reason (or even nature) of the
chang
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. Pointing to them as the if they are The One True
> > Way
> On Sun, 2007-12-02 at 09:26 -0500, Robert Kiesling wrote:
> > > I guess nobody really loves writing ChangeLog entries, but in my opinion
> > > there
> > > are quite effective "executive summaries" for the patches and helpful to
> > > the
> > > reader/reviewer. Please let's not throw the bab
Robert Dewar <[EMAIL PROTECTED]> writes:
> I don't see much point, since a diff can always easily tell
> you *what* was changed.
A changelog does help recreate a change *set* though, since CVS is
lacking such a thing. Thus, the CL helps you determine what files to
diff.
True that SVN solves par
On 12/2/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Right, because surely one size fits all projects and possibilities,
>
> It was supposed to be the Coding Standards for The GNU Project.
Sorry, but again, this is not a good enough justification to me.
We do a lot of things different than "Th
On Mon, Dec 03, 2007 at 10:02:13AM +1100, Ben Elliston wrote:
> Having said that, I find the lack of rationale for some changes to be a
> bit irritating. I know that this should be done through code comments,
> but those are often made across the changeset and in different files.
> There is rarely
Eric Botcazou wrote:
I'd go even further, and say if the GNU coding standards say we
shouldn't be putting descriptions of why we are changing things in the
ChangeLog, than they should be changed and should be ignored on this
point until they do. Pointing to them as the if they are The One True
W
On Sun, 2 Dec 2007, Daniel Berlin wrote:
> I have never, in 7 years of working on and debugging gcc, found the
> ChangeLog to be useful in debugging a problem.
I find they are useful for finding what has changed in function X (or in
functions matching pattern Y) since 4.1, say (given a bug in 4.
Eric Botcazou wrote:
FWIW, I agree completely - I've never found ChangeLogs useful, I hate
writing them, and I think the linux-kernel guys these days generally have
much better checkin messages than we do.
I guess nobody really loves writing ChangeLog entries, but in my opinion there
are quit
Hans-Peter Nilsson wrote:
The comment *in the code* is lacking, other than that I don't
see much point in your rant; it's all been said before, for one.
It usually takes a while for newcomers to understand the
process, in particular the what-not-why of ChangeLogs... ;)
I actually think that of
> This *is* the information I would expect to be present somewhere in
> GCC history. A clear and detailed information on why the change was
> necessary. Sure, in some case the checkin references a PR, but the PR
> often contains information of what didn't work before the change and
> the same infor
> Right, because surely one size fits all projects and possibilities,
It was supposed to be the Coding Standards for The GNU Project.
> and workflow and processes have certainly not changed since then.
In my opinion, it's now easier to work around their perceived deficiencies.
--
Eric Botcazo
On Sun, 2007-12-02 at 21:36 +0100, Eric Botcazou wrote:
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. P
On Sun, 2007-12-02 at 09:26 -0500, Robert Kiesling wrote:
> > I guess nobody really loves writing ChangeLog entries, but in my opinion
> > there
> > are quite effective "executive summaries" for the patches and helpful to
> > the
> > reader/reviewer. Please let's not throw the baby with the b
On 12/2/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. Poin
> I'd go even further, and say if the GNU coding standards say we
> shouldn't be putting descriptions of why we are changing things in the
> ChangeLog, than they should be changed and should be ignored on this
> point until they do. Pointing to them as the if they are The One True
> Way seems very
On 12/2/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Richard Kenner wrote:
> >>> How could a newcomer guess why the gcc_force_collect flag needs to be
> >>> reset?
> >> That is supposed to be written in a comment. The change log entry
> >> should describe _what_ is being changed, so that you can
On 12/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > How could a newcomer guess why the gcc_force_collect flag needs to be
> > > reset?
> >
> > That is supposed to be written in a comment. The change log entry
> > should describe _what_ is being changed, so that you can find out when a
> >
Samuel Tardieu <[EMAIL PROTECTED]> 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 g
[ Charset ISO-8859-1 unsupported, converting... ]
> > FWIW, I agree completely - I've never found ChangeLogs useful, I hate
> > writing them, and I think the linux-kernel guys these days generally have
> > much better checkin messages than we do.
>
> I guess nobody really loves writing ChangeLog
> FWIW, I agree completely - I've never found ChangeLogs useful, I hate
> writing them, and I think the linux-kernel guys these days generally have
> much better checkin messages than we do.
I guess nobody really loves writing ChangeLog entries, but in my opinion there
are quite effective "execu
Richard Kenner wrote:
>>> How could a newcomer guess why the gcc_force_collect flag needs to be
>>> reset?
>> That is supposed to be written in a comment. The change log entry
>> should describe _what_ is being changed, so that you can find out when a
>> particular change was made.
>
> Not quite.
> > How could a newcomer guess why the gcc_force_collect flag needs to be
> > reset?
>
> That is supposed to be written in a comment. The change log entry
> should describe _what_ is being changed, so that you can find out when a
> particular change was made.
Not quite. The comments are suppose
> Sure, but as you explained yourself in the message I cited, the reason
> to do this change was because of a problem in STABS info generation :)
"reason" is not quite appropriate in this case, "occasion" is more accurate.
--
Eric Botcazou
On Sun, 2 Dec 2007, Samuel Tardieu wrote:
> On 2/12, Andreas Schwab wrote:
>
> | That is supposed to be written in a comment. The change log entry
> | should describe _what_ is being changed, so that you can find out when a
> | particular change was made.
>
> This should be the job of the VCS, e.
> "Eric" == Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Without digging in the mailing-list archives to see why you made
>> the change, if something new breaks on a STABS platform I will have
>> no hint that this change was in any way related to STABS.
Eric> But this change has nothing to do
Sam> How could a newcomer guess why the gcc_force_collect flag needs to
Sam> be reset?
Andreas> That is supposed to be written in a comment. The change log
Andreas> entry should describe _what_ is being changed, so that you
Andreas> can find out when a particular change was made.
Out of curiosit
> I'll take an example from one of your recent changes in gcc/ChangeLog:
>
>2007-11-19 Eric Botcazou <[EMAIL PROTECTED]>
>
>* stor-layout.c (lang_adjust_rli): Delete.
>(set_lang_adjust_rli): Likewise.
>(layout_type): Do not call lang_adjust_rli hook.
>
On 2/12, Eric Botcazou wrote:
| > I know this document and I think the part on ChangeLog doesn't achieve
| > its purpose:
| >
| > http://www.gnu.org/prep/standards/standards.html#Change-Logs
| >
| >Keep a change log to describe all the changes made to program source
| >files. The purpose
On 2/12, Andreas Schwab wrote:
| That is supposed to be written in a comment. The change log entry
| should describe _what_ is being changed, so that you can find out when a
| particular change was made.
This should be the job of the VCS, e.g. "svn log" and "svn blame".
Moreover, ChangeLogs are
> I know this document and I think the part on ChangeLog doesn't achieve
> its purpose:
>
> http://www.gnu.org/prep/standards/standards.html#Change-Logs
>
>Keep a change log to describe all the changes made to program source
>files. The purpose of this is so that people investigating bugs i
On 2/12, Eric Botcazou wrote:
| He indeed cannot, but the ChangeLog is not meant to make it possible either.
| See http://gcc.gnu.org/contribute.html, especially the GNU Coding Standards.
I know this document and I think the part on ChangeLog doesn't achieve
its purpose:
http://www.gnu.org/prep
> I tend to find GCC ChangeLog entries useless. For example, the more
>
> recent ChangeLog entry in gcc/ChangeLog is:
> | 2007-11-30 Jan Hubicka <[EMAIL PROTECTED]>
> |
> | * ggc-common.c (dump_ggc_loc_statistics): Reset ggc_force_collect
> | flag.
>
> How could a newcomer guess w
Samuel Tardieu <[EMAIL PROTECTED]> writes:
> As a recent committer to GCC, I am always surprised to see the content
> of ChangeLog entries and commit messages.
>
> I tend to find GCC ChangeLog entries useless. For example, the more
> recent ChangeLog entry in gcc/ChangeLog is:
>
> | 2007-11-30 Ja
83 matches
Mail list logo
