This just got into BitKeeper, about 10 hours ago:
> [PATCH] x86-64 update
>
> Make everything compile and boot again.
>
> The earlier third party ioport.c changes unfortunately
> didn't even compile, fix that too.
>
> - Update defconfig
> - Some minor cleanup
> - Introduce physid_t for APIC masks (fixes UP kernels)
> - Finish ioport.c merge and fix compilation
Several days ago, I mailed Andi Kleen a build log which
showed that ioport.c builds perfectly well on x86-64.
The whole 2.6.0-test4 kernel does in fact, as downloaded
from kernel.org. Andi Kleen agreed...
...and now this comment gets submitted to Linus, ending
up in BitKeeper. I'd like this changed. I realize that
it may be a rather difficult thing to change at this point,
but it is clearly wrong.
On Mon, Sep 01, 2003 at 12:15:30AM -0400, Albert Cahalan wrote:
> This just got into BitKeeper, about 10 hours ago:
>
> > [PATCH] x86-64 update
> >
> > Make everything compile and boot again.
> >
> > The earlier third party ioport.c changes unfortunately
> > didn't even compile, fix that too.
> >
> > - Update defconfig
> > - Some minor cleanup
> > - Introduce physid_t for APIC masks (fixes UP kernels)
> > - Finish ioport.c merge and fix compilation
>
> Several days ago, I mailed Andi Kleen a build log which
> showed that ioport.c builds perfectly well on x86-64.
> The whole 2.6.0-test4 kernel does in fact, as downloaded
> from kernel.org. Andi Kleen agreed...
>
> ...and now this comment gets submitted to Linus, ending
> up in BitKeeper. I'd like this changed. I realize that
> it may be a rather difficult thing to change at this point,
> but it is clearly wrong.
If you want the comments changed I can do that on bkbits.net and anyone
who grabs the update from there will get the new comments. If you want
the patch gone out of BK anyone can do that with a cset -x.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 2003-09-01 at 10:07, Larry McVoy wrote:
> On Mon, Sep 01, 2003 at 12:15:30AM -0400, Albert Cahalan wrote:
> > This just got into BitKeeper, about 10 hours ago:
> >
> > > [PATCH] x86-64 update
> > >
> > > Make everything compile and boot again.
> > >
> > > The earlier third party ioport.c changes unfortunately
> > > didn't even compile, fix that too.
> > >
> > > - Update defconfig
> > > - Some minor cleanup
> > > - Introduce physid_t for APIC masks (fixes UP kernels)
> > > - Finish ioport.c merge and fix compilation
> >
> > Several days ago, I mailed Andi Kleen a build log which
> > showed that ioport.c builds perfectly well on x86-64.
> > The whole 2.6.0-test4 kernel does in fact, as downloaded
> > from kernel.org. Andi Kleen agreed...
> >
> > ...and now this comment gets submitted to Linus, ending
> > up in BitKeeper. I'd like this changed. I realize that
> > it may be a rather difficult thing to change at this point,
> > but it is clearly wrong.
>
> If you want the comments changed I can do that on bkbits.net and anyone
> who grabs the update from there will get the new comments. If you want
> the patch gone out of BK anyone can do that with a cset -x.
The code itself is OK I guess; the physid_t changes
may well be important, although they could be redone.
It's the comment that bugs me, specifically:
"Make everything compile and boot again."
"The earlier third party ioport.c changes unfortunately
didn't even compile, fix that too."
"Finish ioport.c merge and fix compilation"
(BTW, there's a bit more beyond the end of what I quoted)
I'm OK with whatever ensures that somebody looking back
through the BitKeeper logs isn't going to come to the
conclusion that I broke something.
Um, not everybody will grab updates from bkbits.net,
right? Pardon me for being clueless about BitKeeper,
but is there some command Andi or Linus could run?
On Mon, Sep 01, 2003 at 11:26:55AM -0400, Albert Cahalan wrote:
> I'm OK with whatever ensures that somebody looking back
> through the BitKeeper logs isn't going to come to the
> conclusion that I broke something.
>
> Um, not everybody will grab updates from bkbits.net,
> right? Pardon me for being clueless about BitKeeper,
> but is there some command Andi or Linus could run?
Unfortunately the checkin comments themselves are not revision controlled.
You have to run a command on each repository that needs to be fixed,
if you send me the desired comments I'll post the command. Then if
Linus or Marcelo says do it I'll do it on bkbits.net. That should be good
enough, the logs there are what people tend to browse.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, Sep 01, 2003 at 08:46:46AM -0700, Larry McVoy wrote:
> Unfortunately the checkin comments themselves are not revision controlled.
> You have to run a command on each repository that needs to be fixed,
> if you send me the desired comments I'll post the command. Then if
> Linus or Marcelo says do it I'll do it on bkbits.net. That should be good
> enough, the logs there are what people tend to browse.
WTF? Andi probably had a reason to put this in. If Albert feels pissed
of he should shred his repo instead of doing stupid censorship crap.
On Mon, Sep 01, 2003 at 04:56:58PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 08:46:46AM -0700, Larry McVoy wrote:
> > Unfortunately the checkin comments themselves are not revision controlled.
> > You have to run a command on each repository that needs to be fixed,
> > if you send me the desired comments I'll post the command. Then if
> > Linus or Marcelo says do it I'll do it on bkbits.net. That should be good
> > enough, the logs there are what people tend to browse.
>
> WTF? Andi probably had a reason to put this in. If Albert feels pissed
> of he should shred his repo instead of doing stupid censorship crap.
Hey, I'm not in the middle of this because I don't understand who is right
and it's not my place to make that call. I said "if Linus or Marcelo says
do it" specifically for the case that there is some hanky panky going on.
On the other hand, it's perfectly possible that the wrong comment got
stuck in there and if that's the case why shouldn't it get fixed?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> Hey, I'm not in the middle of this because I don't understand who is right
> and it's not my place to make that call.
I doesn't matter who's actually right. If Andi was wrong Albert can
demand a apology from him or sue him or whater (not that his name is
actually mentioned in the message).
But we're not going to retroactively censor commit messages.
On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> > Hey, I'm not in the middle of this because I don't understand who is right
> > and it's not my place to make that call.
>
> I doesn't matter who's actually right. If Andi was wrong Albert can
> demand a apology from him or sue him or whater (not that his name is
> actually mentioned in the message).
I was wrong in this case, although I partly blame Albert because he sneaked
in x86-64 patches behind my back directly to Linus, which caused
merging problems and resulted in this comment.
-Andi
On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> > Hey, I'm not in the middle of this because I don't understand who is right
> > and it's not my place to make that call.
>
> I doesn't matter who's actually right. If Andi was wrong Albert can
> demand a apology from him or sue him or whater (not that his name is
> actually mentioned in the message).
>
> But we're not going to retroactively censor commit messages.
I'm confused, I thought Linus/Marcelo/Andrew were the tree maintainers.
As long as they are they get to make the call, not you (or me or whoever).
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Llu, 2003-09-01 at 16:59, Larry McVoy wrote:
> Hey, I'm not in the middle of this because I don't understand who is right
> and it's not my place to make that call. I said "if Linus or Marcelo says
> do it" specifically for the case that there is some hanky panky going on.
> On the other hand, it's perfectly possible that the wrong comment got
> stuck in there and if that's the case why shouldn't it get fixed?
Presumably in the abstract "if you care" case you can generate this
change globally by excluding that changeset and all after, then
reapplying it with a different comment then reapplying all that follow ?
On Mon, 1 Sep 2003, Larry McVoy wrote:
> On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote:
> > On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> > > Hey, I'm not in the middle of this because I don't understand who is right
> > > and it's not my place to make that call.
> >
> > I doesn't matter who's actually right. If Andi was wrong Albert can
> > demand a apology from him or sue him or whater (not that his name is
> > actually mentioned in the message).
> >
> > But we're not going to retroactively censor commit messages.
>
> I'm confused, I thought Linus/Marcelo/Andrew were the tree maintainers.
> As long as they are they get to make the call, not you (or me or whoever).
Retroactively changing a commit message may be a dangerous precedent. While
there may be legitimate reasons (E.g. plain wrong comments or `actually this
part was not written by x but by y'), one day The Evil Empire may claim we
changed the evidence of who did what.
Putting comments under revision control is another option, but may be too
deep-involving...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Sep 01, 2003 at 05:33:40PM +0100, Alan Cox wrote:
> On Llu, 2003-09-01 at 16:59, Larry McVoy wrote:
> > Hey, I'm not in the middle of this because I don't understand who is right
> > and it's not my place to make that call. I said "if Linus or Marcelo says
> > do it" specifically for the case that there is some hanky panky going on.
> > On the other hand, it's perfectly possible that the wrong comment got
> > stuck in there and if that's the case why shouldn't it get fixed?
>
> Presumably in the abstract "if you care" case you can generate this
> change globally by excluding that changeset and all after, then
> reapplying it with a different comment then reapplying all that follow ?
Yup, that would work just fine. Anyone can do this.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 1 Sep 2003, Christoph Hellwig wrote:
>
> But we're not going to retroactively censor commit messages.
Actually, I do that all the time. In fact, it was I who asked Larry to add
the "bk comment" command in to make it easy to do so.
The thing is, it's hard to do after the message has already gone out into
the public - but I fix up peoples email commentary by hand both in the
email and often later after it has hit my BK tree too. I try to fix
obvious typos, and just generally make the things more readable.
And if the comment was wrong, then it should be fixed. Not because of any
"censorship", but because it's misleading if the comment says it fixes
something it doesn't fix - and that might make people overlook the _real_
thing the change does.
Linus
On Mon, Sep 01, 2003 at 07:23:34PM +0200, Jakob Oestergaard wrote:
> There is an important difference.
>
> If I send you a mail saying "X" and you change it to say "Y" and put "Y"
> in the source tree, fine. It was a mail between us, noone except you
> and me will know. If I think it's wrong, maybe I can make you submit
> "X" to the source tree instead, with an explanation.
>
> Everything that was ever publicly visible, stays publicly visible, even
> with the the revised comments, thanks to the revision history.
>
> But changing the source tree revision history retroactively, that's bad.
> It defies the purpose of revision control itself.
>
> The source tree is a public record. People will remember "this said 'Y'
> I'm sure, but now it says 'X', why is that?" - and noone can answer.
> History forgotten.
Yupp, that's what I meant. I certainly don't want a thought police
on my source trees.
On Mon, Sep 01, 2003 at 09:59:58AM -0700, Linus Torvalds wrote:
>
> On Mon, 1 Sep 2003, Christoph Hellwig wrote:
> >
> > But we're not going to retroactively censor commit messages.
>
> Actually, I do that all the time. In fact, it was I who asked Larry to add
> the "bk comment" command in to make it easy to do so.
>
> The thing is, it's hard to do after the message has already gone out into
> the public - but I fix up peoples email commentary by hand both in the
> email and often later after it has hit my BK tree too. I try to fix
> obvious typos, and just generally make the things more readable.
>
> And if the comment was wrong, then it should be fixed. Not because of any
> "censorship", but because it's misleading if the comment says it fixes
> something it doesn't fix - and that might make people overlook the _real_
> thing the change does.
There is an important difference.
If I send you a mail saying "X" and you change it to say "Y" and put "Y"
in the source tree, fine. It was a mail between us, noone except you
and me will know. If I think it's wrong, maybe I can make you submit
"X" to the source tree instead, with an explanation.
Everything that was ever publicly visible, stays publicly visible, even
with the the revised comments, thanks to the revision history.
But changing the source tree revision history retroactively, that's bad.
It defies the purpose of revision control itself.
The source tree is a public record. People will remember "this said 'Y'
I'm sure, but now it says 'X', why is that?" - and noone can answer.
History forgotten.
It's your call, but I can certainly see why some feel bad about this.
After all, we wouldn't want to edit the e-mail archives to remove all
trace of what happened, either, would we? ;)
Cheers,
--
................................................................
: [email protected] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob ?stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
On Mon, Sep 01, 2003 at 06:28:27PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 07:23:34PM +0200, Jakob Oestergaard wrote:
> > There is an important difference.
> >
> > If I send you a mail saying "X" and you change it to say "Y" and put "Y"
> > in the source tree, fine. It was a mail between us, noone except you
> > and me will know. If I think it's wrong, maybe I can make you submit
> > "X" to the source tree instead, with an explanation.
> >
> > Everything that was ever publicly visible, stays publicly visible, even
> > with the the revised comments, thanks to the revision history.
> >
> > But changing the source tree revision history retroactively, that's bad.
> > It defies the purpose of revision control itself.
> >
> > The source tree is a public record. People will remember "this said 'Y'
> > I'm sure, but now it says 'X', why is that?" - and noone can answer.
> > History forgotten.
>
> Yupp, that's what I meant. I certainly don't want a thought police
> on my source trees.
Trivial w/ the current BK because the comments aren't versioned. Just have
someone be elected as the archiver and have them have a cron job which pulls
bkbits.net every 20 minutes or so. Then if the comments are ever changed
your archive will have the originals.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 2003-09-01 at 11:46, Larry McVoy wrote:
> On Mon, Sep 01, 2003 at 11:26:55AM -0400, Albert Cahalan wrote:
> > I'm OK with whatever ensures that somebody looking back
> > through the BitKeeper logs isn't going to come to the
> > conclusion that I broke something.
> >
> > Um, not everybody will grab updates from bkbits.net,
> > right? Pardon me for being clueless about BitKeeper,
> > but is there some command Andi or Linus could run?
>
> Unfortunately the checkin comments themselves are not revision controlled.
> You have to run a command on each repository that needs to be fixed,
> if you send me the desired comments I'll post the command. Then if
> Linus or Marcelo says do it I'll do it on bkbits.net. That should be good
> enough, the logs there are what people tend to browse.
============ as a patch =============
--- old 2003-09-01 14:04:46.000000000 -0400
+++ new 2003-09-01 14:05:18.000000000 -0400
@@ -2,13 +2,9 @@
Make everything compile and boot again.
-The earlier third party ioport.c changes unfortunately didn't even
-compile, fix that too.
-
- Update defconfig
- Some minor cleanup
- Introduce physid_t for APIC masks (fixes UP kernels)
- - Finish ioport.c merge and fix compilation
- Add bandaid for CardBus bridges and broken BIOS (Vojtech)
- Add bandaid for unsynchronized TSCs (Vojtech)
- Fix ffs(0) return value (fixes XFS)
=========== old content ============
[PATCH] x86-64 update
Make everything compile and boot again.
The earlier third party ioport.c changes unfortunately didn't even
compile, fix that too.
- Update defconfig
- Some minor cleanup
- Introduce physid_t for APIC masks (fixes UP kernels)
- Finish ioport.c merge and fix compilation
- Add bandaid for CardBus bridges and broken BIOS (Vojtech)
- Add bandaid for unsynchronized TSCs (Vojtech)
- Fix ffs(0) return value (fixes XFS)
- Fix compilation with software suspend
=========== new content ============
[PATCH] x86-64 update
Make everything compile and boot again.
- Update defconfig
- Some minor cleanup
- Introduce physid_t for APIC masks (fixes UP kernels)
- Add bandaid for CardBus bridges and broken BIOS (Vojtech)
- Add bandaid for unsynchronized TSCs (Vojtech)
- Fix ffs(0) return value (fixes XFS)
- Fix compilation with software suspend