ChangeLog suggestion
Hi Linus, Marcelo,
In each changelog entry, it would be really useful to include the Message-ID of that email in a regex-parsable location. This way, if the email was cced to lkml it would be possible for folks to track down the actual patch.
I'm not familiar with your scripts, but I'd be surprised if this were very difficult to implement. At the same time, there are many cases of changelog entries that read only 'USB' or something equally unhelpful, where there is little chance that anyone could track down the corresponding patch. Having the Message-ID in those cases would make all the difference in the world.
Be well,
Zack
Signature · 1 line
Zack Brown
Quoted 10 lines
In each changelog entry, it would be really useful to include the Message-ID of that email in a regex-parsable location. This way, if the email was cced to lkml it would be possible for folks to track down the actual patch.
I'm not familiar with your scripts, but I'd be surprised if this were very difficult to implement. At the same time, there are many cases of changelog entries that read only 'USB' or something equally unhelpful, where there is little chance that anyone could track down the corresponding patch. Having the Message-ID in those cases would make all the difference in the world.
The changelogs are generated by BitKeeper - couldn't we simply include a link that will let anybody[1] access the relevant changesets?
[1] This can be via HTTP, and _doesn't_ require anybody to use BitKeeper in any way.
John.
Hi John,
Quoted 11 lines · John Bradford
Quoted 10 lines
In each changelog entry, it would be really useful to include the Message-ID of that email in a regex-parsable location. This way, if the email was cced to lkml it would be possible for folks to track down the actual patch.
I'm not familiar with your scripts, but I'd be surprised if this were very difficult to implement. At the same time, there are many cases of changelog entries that read only 'USB' or something equally unhelpful, where there is little chance that anyone could track down the corresponding patch. Having the Message-ID in those cases would make all the difference in the world.
Quoted 5 lines
The changelogs are generated by BitKeeper - couldn't we simply include a link that will let anybody[1] access the relevant changesets?
[1] This can be via HTTP, and _doesn't_ require anybody to use BitKeeper in any way.
That would be ideal.
Be well,
Zack
Quoted 7 lines
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 1 line
Zack Brown
Quoted 14 lines · Zack Brown
Hi John,
Quoted 11 lines · John Bradford
Quoted 10 lines
In each changelog entry, it would be really useful to include the Message-ID of that email in a regex-parsable location. This way, if the email was cced to lkml it would be possible for folks to track down the actual patch.
I'm not familiar with your scripts, but I'd be surprised if this were very difficult to implement. At the same time, there are many cases of changelog entries that read only 'USB' or something equally unhelpful, where there is little chance that anyone could track down the corresponding patch. Having the Message-ID in those cases would make all the difference in the world.
Quoted 7 lines
Quoted 5 lines
The changelogs are generated by BitKeeper - couldn't we simply include a link that will let anybody[1] access the relevant changesets?
[1] This can be via HTTP, and _doesn't_ require anybody to use BitKeeper in any way.
That would be ideal.
short of that there's the bk commit mailinglist that has all of them anyway; it's 3 clicks in evolution to find one given the author ;)
Quoted 3 lines · John Bradford
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).
Linus
Quoted 10 lines
Quoted 2 lines
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.
Quoted 4 lines
(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).
Oh, I wasn't suggesting trying to preserve a link to the E-Mail via the scripts->BK chain.
What I was thinking of was each time you import a patchset from a [mail | set of mails], BK makes that in to a changeset, which can't be referenced directy in the changelog, because the changeset's id can change in the future. Is there no way that BK can generate a reference to the HTTP interface to bkbits that will remain constant, and can therefore be included in the changelog, (as an URL to retrieve a patch from). Even if the patch can't be applied to any particular tree, it's still something that can be refered to in a mail to LKML, or similar.
John.
Quoted 18 lines
Quoted 10 lines
Quoted 2 lines
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.
Quoted 4 lines
(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).Oh, I wasn't suggesting trying to preserve a link to the E-Mail via the
scripts->BKchain.
Quoted 9 lines
What I was thinking of was each time you import a patchset from a [mail | set of mails], BK makes that in to a changeset, which can't be referenced directy in the changelog, because the changeset's id can change in the future. Is there no way that BK can generate a reference to the HTTP interface to bkbits that will remain constant, and can therefore be included in the changelog, (as an URL to retrieve a patch from). Even if the patch can't be applied to any particular tree, it's still something that can be refered to in a mail to LKML, or similar.
Ignore this suggestion, I missed your other mail in this thread - I see now that there isn't a sensible way to do it :-).
John.
Quoted 4 lines · Linus Torvalds
(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 really wish Marcelo would do this or someone would volunteer to clean up the change log comments. BitKeeper doesn't have an easy way to propogate changes to the checkin comments (they are not currently revision controlled). However, you can change them and someone could clean up all the crud in the 2.4 tree and we could replace the one on bkbits with a cleaned up one.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi Linus,
Quoted 13 lines · Linus Torvalds
Quoted 3 lines · John Bradford
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.
Quoted 4 lines
(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,
Zack
Quoted 3 lines
Linus
Signature · 1 line
Zack Brown
Quoted 3 lines · Zack Brown
I'm not familiar with your scripts, but I'd be surprised if this were very difficult to implement.
Well, the scripts can take it, but quite frankly I'd rather not clutter the changelogs up with crud that really doesn't matter.
The thing is, the stuff that already _is_ in the changelog is certainly enough to identify the email if you just have a reasonable search engine. You have author, comments and diff, and if that isn't enough to identify the thing then something is wrong.
Also, _most_ of the patches by far end up coming as personal emails, and while they have often shown up on linux-kernel in _some_ way, it won't be the same email that got sent to me. The email that showed up on the mailing list will often have been of the type "please test this out and if it works for you I'll send it to Linus", or it will have been posted by the original author and then the actual patch made it to me either through somebody elses BK tree _or_ through a person like Andrew Morton or Alan Cox.
In other words, what you ask for is ugly (yes, I actually look at the output of "bk changes") _and_ not very useful.
Linus
Quoted 3 lines · Linus Torvalds
The thing is, the stuff that already _is_ in the changelog is certainly enough to identify the email if you just have a reasonable search engine. You have author, comments and diff, and if that isn't enough to identify the thing then something is wrong.
Slightly OT:
Note that the "author" info is only semi readable from CVS. It contains just the user part of the email address (in my case - "lkml" for spam reasons - hardly a unique identifier). I'm told that under BK it has the full email, so I'm not sure where that stands there.
This does mean that under CVS, this info is not searchable, nor even guarenteed unique.
Shachar
Signature · 3 lines
Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Quoted 5 lines · Shachar Shemesh
Note that the "author" info is only semi readable from CVS. It contains just the user part of the email address (in my case - "lkml" for spam reasons - hardly a unique identifier). I'm told that under BK it has the full email, so I'm not sure where that stands there.
People have indeed asked me to do that even for the BK tree - to avoid spammers picking up the address. I don't want to do it.
Personally, I want to have some address that I can reach the author at, and if that means that spammers can pick it up too (open source means that everybody has the same stuff _I_ have) I guess people who want to talk to me need to live with spam filters or send patches to me from special accounts.
But both the short-format changelog (the ones posted to linux-kernel) and the CVS tree do hide the addresses somewhat.
Linus
Quoted 5 lines · Linus Torvalds
But both the short-format changelog (the ones posted to linux-kernel) and the CVS tree do hide the addresses somewhat.
Linus
I'm afraid I did not explain myself clearly. I fear that the format is both too short, and not descriptive enough. I think taking only the real name from the email would server both the purpose of searching the list, and the purpose of understanding who submitted the patch simpler.
The anti spam part was the fact that my email (for the purpose of this list) is [email protected], which leaves an awfully undescriptive "lkml" in CVS. This allows neither searching nor accounting. As I'm sure other people use the exact same technique when posting to a mailing list, searching for someone who's email is lkml@* will not even be unique.
I hope my intention was clearer this time.
Shachar
Signature · 3 lines
Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Quoted 3 lines
The anti spam part was the fact that my email (for the purpose of this list) is [email protected], which leaves an awfully undescriptive "lkml" in CVS.
So fix your email, this is your problem, not the SCM's problem. How hard is it to change your email to shemesh-lkml or something reasonable?
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · Linus Torvalds
Personally, I want to have some address that I can reach the author at, and if that means that spammers can pick it up too (open source means that everybody has the same stuff _I_ have) I guess people who want to talk to me need to live with spam filters or send patches to me from special accounts.
It's not that bad. Since I started posting to lkml, my daily spam dosis has risen from one to three, roughly. Annoying, but not a big problem, even without filters.
Jörn
Signature · 2 lines
Victory in war is not repetitious. -- Sun Tzu