archive mirror
 help / color / mirror / Atom feed
From: Zack Brown <>
To: Linus Torvalds <>
Cc: John Bradford <>,
	Marcelo Tosatti <>,
	Linux Kernel Mailing List <>
Subject: Re: ChangeLog suggestion
Date: Sat, 26 Apr 2003 10:07:36 -0700	[thread overview]
Message-ID: <20030426170736.GC1960@renegade> (raw)
In-Reply-To: <>

Hi Linus,

On Sat, Apr 26, 2003 at 09:34:25AM -0700, Linus Torvalds wrote:
> On Sat, 26 Apr 2003, John Bradford wrote:
> > 
> > The changelogs are generated by BitKeeper - couldn't we simply include
> > a link that will let anybody[1] access the relevant changesets?
> Well, yes, the changelogs are generated by BitKeeper, but what gets fed 
> into bitkeeper is controlled by some scripts I wrote, which are the ones 
> that take the email and munge it into a readable format etc. So by the 
> time the thing hits my BK repository, the email headers will all have been 
> thrown away, except for "From: " and "Subject: ". So BK never sees the 
> full email.
> (Even my scripts don't see the full email a large percentage of the time:  
> I end up prettifying the emails for actual application by first removing
> things like "Hi Linus, please apply this" etc which are pointless in the 
> changelog).

I think John's idea was that the email is not really important, as long as
the diffs themselves could be made available via URLs. That sounds good. I
only asked for the Message-ID because it didn't occur to me there might be
a straighter path to the diff.

I'm trying to deal with cases where the only changelog comment is
something like:

"kbuild: Hand merge link order change form driverfs update."

I know who did it. I know when it was accepted into the tree. I can spend
awhile grepping megabytes of lmkl archives (and come up empty, in this case),
but after that I have to give up. The patch is pretty much simply unavailable
at that point.

A URL to the diff itself would make it trivial to delve deeper into the
meaning behind changelog entries. Currently, investigating each entry just
takes way too much time, and often leads nowhere. If you can automate it
easily at your end, it would make a big difference to anyone studying
kernel development.

Be well,

> 		Linus

Zack Brown

  parent reply	other threads:[~2003-04-26 16:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-26  6:21 ChangeLog suggestion Zack Brown
2003-04-26  6:52 ` John Bradford
2003-04-26 15:12   ` Zack Brown
2003-04-26 17:28     ` Arjan van de Ven
2003-04-26 16:34   ` Linus Torvalds
2003-04-26 16:50     ` Larry McVoy
2003-04-26 16:50     ` John Bradford
2003-04-26 16:53       ` John Bradford
2003-04-26 17:07     ` Zack Brown [this message]
2003-04-26 16:29 ` Linus Torvalds
2003-04-26 17:44   ` Shachar Shemesh
2003-04-26 18:06     ` Linus Torvalds
2003-04-26 18:17       ` Shachar Shemesh
2003-04-26 18:23         ` Larry McVoy
2003-04-26 18:29       ` Jörn Engel
2003-04-26 20:08 b_adlakha

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030426170736.GC1960@renegade \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).