Remove Bitkeeper documentation from Linux tree
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Daniel Phillips
Quoted 6 lines · Jeff Garzik
Quoted 3 lines · Daniel Phillips
Let's pull back a little from the proselytizing, shall we? I'll modify my proposal to 'include just a pointer to the bk documentation in the kernel tree itself'. This should satisfy everybody.
No, it doesn't. It was put into the tree for convenience.
How much less convenient is it to click on a link? So much harder that it's worth pissing off some key developers?
Linus has already explained why he put it into the kernel sources.
And, who are these key developers you are speaking for?
Quoted 5 lines
Quoted 3 lines
It therefore stands to reason that removing it creates inconvenience. Further, the only reason to remove it is ideology. i.e. something other than technical merit. So your proposal is still a no-go.
According to you, yes. I'll leave it on the table.
Linus has already explained he isn't applying your patch.
Jeff
Quoted 7 lines · Jeff Garzik
Quoted 6 lines · Daniel Phillips
Quoted 5 lines · Jeff Garzik
Quoted 3 lines · Daniel Phillips
Let's pull back a little from the proselytizing, shall we? I'll modify my proposal to 'include just a pointer to the bk documentation in the kernel tree itself'. This should satisfy everybody.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
No, it doesn't. It was put into the tree for convenience.
How much less convenient is it to click on a link? So much harder that it's worth pissing off some key developers?
Linus has already explained why he put it into the kernel sources.
So far the only argument I've seen is: it's convenient. Did I miss something?
The convenience argument is bogus. A url is just as convenient, especially as Larry has offered an appropriate home, one which will by definition continue to exist as long as Bitkeeper stays alive. Plus, the url saves download bandwidth. A compelling argument I'd say.
Quoted 1 line
And, who are these key developers you are speaking for?
They can introduce themselves if they wish. Or you can ask around.
Signature · 1 line
Daniel
Quoted 10 lines · Daniel Phillips
Quoted 5 lines · Jeff Garzik
Quoted 2 lines · Daniel Phillips
How much less convenient is it to click on a link? So much harder that it's worth pissing off some key developers?
Linus has already explained why he put it into the kernel sources.
So far the only argument I've seen is: it's convenient. Did I miss something?
The convenience argument is bogus. A url is just as convenient,
If you say this, then you either missed, or are willfully ignoring, what Linus said. Search for the string "helsinki.fi".
Quoted 3 lines
Quoted 1 line
And, who are these key developers you are speaking for?
They can introduce themselves if they wish. Or you can ask around.
I am asking. My previous post was asking. Who are you speaking for?
Jeff
Quoted 1 line
I am asking. My previous post was asking. Who are you speaking for?
"Answer zee question, old man!"
Signature · 1 line
Daniel
Quoted 2 lines · Daniel Phillips
Plus, the url saves download
bandwidth. A compelling argument I'd say.
The docs are all of 12K, I just went and looked. If you care about bandwidth, you'd be arguing in favor of BK, it saves tons of bandwidth compared to diff and patch.
In fact, your path to remove them proves that. If you cared about bandwidth, you would have posted a BK patch to do it. :-)
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 13 lines · Jeff Garzik
Quoted 9 lines · Daniel Phillips
Quoted 5 lines · Jeff Garzik
Quoted 2 lines · Daniel Phillips
How much less convenient is it to click on a link? So much harder that it's worth pissing off some key developers?
Linus has already explained why he put it into the kernel sources.
So far the only argument I've seen is: it's convenient. Did I miss something? The convenience argument is bogus. A url is just as convenient,
If you say this, then you either missed, or are willfully ignoring, what Linus said. Search for the string "helsinki.fi".
Quoted 3 lines · Linus
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),
Larry has offered to host it, so Linus's argument is answered.
Signature · 1 line
Daniel
Quoted 7 lines · Larry McVoy
Quoted 2 lines · Daniel Phillips
Plus, the url saves download
bandwidth. A compelling argument I'd say.The docs are all of 12K, I just went and looked. If you care about bandwidth, you'd be arguing in favor of BK, it saves tons of bandwidth compared to diff and patch.
All you said is 'it doesn't waste *that* much bandwidth'. Remember, this is the place we spend days arguing over a cycle or two.
Signature · 1 line
Daniel
Quoted 3 lines · Daniel Phillips
Riiiiight. I have at least forwarded your demands to those who have expressed their positions to me privately. If you think I'm going to violate their confidence on your whim, you can think again.
so then you're having private discussions in email, and one of your complaints is about other private discussions in email?
Quoted 2 lines · Daniel Phillips
All you said is 'it doesn't waste *that* much bandwidth'. Remember, this is the place we spend days arguing over a cycle or two.
this bk thread alone has so far consumed 597023 bytes just for the message bodies... plus who knows how many bytes for TCP/IP headers, SMTP overhead, and DNS overhead. that's uncompressed, and multiplied by the, hmm, approximately 2000 subscribers to l-k plus the dozen or two web archives of l-k?
what was that you were saying about wasting bandwidth? if you cared at all about bandwidth you might want to consider not replying.
personally i probably wouldn't be so interested in bk if it weren't for all the zealots telling me it's something i shouldn't even consider using. your approach is about as effective as the war on drugs, or minimum alcohol consumption age limits. tell what i can't do and i'm damn well going to go investigate what it is that's supposedly so bad for me.
thanks to all of you for pointing me in the direction of a tool which looks to be a huge step forward in SCM. i believe "paradigm shift" would be an apt term for bk.
-dean
Quoted 9 lines · dean gaudet
personally i probably wouldn't be so interested in bk if it weren't for all the zealots telling me it's something i shouldn't even consider using. your approach is about as effective as the war on drugs, or minimum alcohol consumption age limits. tell what i can't do and i'm damn well going to go investigate what it is that's supposedly so bad for me.
thanks to all of you for pointing me in the direction of a tool which looks to be a huge step forward in SCM. i believe "paradigm shift" would be an apt term for bk.
You seem to think I'm against Bitkeeper, or its use, or that I think Bitkeeper isn't helping linux. You're wrong. I am against carrying what *appears* to be a big advertisement for Bitkeeper itself in the Linux source tree. This I see as akin to putting up a commercial billboard in a public park. Would you be comfortable with that?
If my comments have caused increased interest in Bitkeeper and spiked up Larry's downloads, I am glad. Now everybody is happy except a number of those whose involvement with Linux is based on some kind of philosophical belief in the freeness of software (or at least in the freeness of Linux) and who have been on the butt end of numerous insults in this thread, your insult above ("zealots") being a good example.
I have suggested carrying a URL instead. Is it reasonable? Who is being extreme here?
Furthermore, who is making the vicious attacks, and why?
Signature · 1 line
Daniel
double-standard? (Re: [PATCH] Remove Bitkeeper documentation from Linux tree)
Quoted 5 lines · Daniel Phillips
You seem to think I'm against Bitkeeper, or its use, or that I think Bitkeeper isn't helping linux. You're wrong. I am against carrying what *appears* to be a big advertisement for Bitkeeper itself in the Linux source tree. This I see as akin to putting up a commercial billboard in a public park. Would you be comfortable with that?
part of what i'm reacting to in this debate is what i perceive as a different set of standards which people apply to software versus, say, hardware.
linux-kernel (and the kernel itself, and the zillions of websites out there with supporting documentation) are chock full of "advertisements" for hardware. pro and con. i've made many hardware purchase decisions based on stuff i read here, and stuff i find when searching for linux documentation.
maybe someday we'll get scifi technology such as nanotech or replicators (and "limitless" fusion energy) which can move us into a new economy in which even open hardware is possible... but that's not the case today -- and i doubt many of you are using anything that could be considered open hardware... almost certainly nobody is able to build an open hardware platform with the same performance and quality standards as proprietary hardware can achieve.
isn't there a bit of a double standard in place here?
i happen to put food on my table working at a hardware company; larry puts food on his working at a software company. i happen to work at the same hardware company as linus does: transmeta. every kernel for the past, uh, 6 or 7 years, has included an advertisement for transmeta. could we possibly conceive of removing all references to transmeta from the kernel, mailing lists and archives? (oh i know if i go back that far in the archives there was probably a big uproar when linus changed his email address :)
-dean
Re: double-standard? (Re: [PATCH] Remove Bitkeeper documentation from Linux tree)
Quoted 6 lines · dean gaudet
i happen to put food on my table working at a hardware company; larry puts food on his working at a software company. i happen to work at the same hardware company as linus does: transmeta. every kernel for the past, uh, 6 or 7 years, has included an advertisement for transmeta. could we possibly conceive of removing all references to transmeta from the kernel, mailing lists and archives?
How big is the Transmeta ad? Does it have its own file? Would you be satisfied if Bitkeeper had the same size advertisement as Transmeta?
Signature · 1 line
Daniel
Quoted 5 lines · Daniel Phillips
You seem to think I'm against Bitkeeper, or its use, or that I think Bitkeeper isn't helping linux. You're wrong. I am against carrying what *appears* to be a big advertisement for Bitkeeper itself in the Linux source tree. This I see as akin to putting up a commercial billboard in a public park. Would you be comfortable with that?
No, poor analogy -- the doc has proven useful time and time to kernel developers. It's in the kernel source because of that.
Let us separate that fact from the notion that it is a BK advertisement, and discuss that part, since that seems to be the important issue. As the author of the doc, I state the doc was not written as an advertisement, and was not paid for, directly or indirectly.
That said, it certainly can been seen as an advertisement. I like BK, and like to encourage others to use it.
So let us term the BK doc as, "not intended as an advertisement, but can easily be considered such." I hope we agree so far? :)
Now that we have that...
Q. What is the justification for removing an admittedly-useful
advertisement?
A. Some people disagree with the author's point of view
(that POV being, "it's ok to use BK in the open source Linux project")
There is no dispute that the doc is useful, only dispute with certain beliefs. Disagreement is fine... encouraged, even. But that's a poor justification to remove the doc from the tree.
I hear your point, I really do. I just feel very strongly that removing the BK docs from the tree is the worst way to go about supporting this point of view.
Jeff
Quoted 7 lines · Jeff Garzik
Let us separate that fact from the notion that it is a BK advertisement, and discuss that part, since that seems to be the important issue. As the author of the doc, I state the doc was not written as an advertisement, and was not paid for, directly or indirectly.
That said, it certainly can been seen as an advertisement.
OK, we've established that then.
Quoted 9 lines
I like BK, and like to encourage others to use it.
So let us term the BK doc as, "not intended as an advertisement, but can easily be considered such." I hope we agree so far? :)
Now that we have that...
Q. What is the justification for removing an admittedly-useful
advertisement?
1) It would be equally as useful as a URL
2) It would not consume download bandwidth
3) It would show some sensitivity to the concerns of those who are uncomfortable with the license.
Quoted 7 lines
There is no dispute that the doc is useful, only dispute with certain beliefs. Disagreement is fine... encouraged, even. But that's a poor justification to remove the doc from the tree.
I hear your point, I really do. I just feel very strongly that removing the BK docs from the tree is the worst way to go about supporting this point of view.
I really don't see how changing out the files for a url qualifies as the "worst way" of addressing the issue. If Larry unretracts his offer to host the files - and I fully expect he will do that after some period of indulging in his wounded bird act - then by definition the documentation will always be available exactly when and where needed. Is there *anybody* here who'd have further license-related complaints about Bitkeeper if that were done? (Speak or forever hold your peace.)
Signature · 1 line
Daniel
Quoted 3 lines · Daniel Phillips
Is there *anybody*
here who'd have further license-related complaints about Bitkeeper if that were done? (Speak or forever hold your peace.)
Oh boy oh boy oh boy, if you can deliver a commitment that this is the last time we have a BK license-related complaint from a kernel hacker, I'll be the first to argue vehemently for that patch you want.
I'd like to know how you are going to deliver on that offer you just made.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 1 line · Daniel Phillips
1) It would be equally as useful as a URL
Maybe 5% less useful or so. There are reasons we move other (non-controversial) docs into the kernel source. 100% of these docs can be URLs.
Quoted 1 line
2) It would not consume download bandwidth
This is a silly argument that dean gaudet dismembered. It's 12K compressed and not your main argument at all.
Quoted 2 lines
3) It would show some sensitivity to the concerns of those who are uncomfortable with the license.
I agree.
So, I believe points #1 and #2 are silly, and #3 is your core argument.
And I agree that it would show sensitivity towards those people who dislike the BK license.
That said, I still think removing the doc is a hideously wrong thing to do. I see the action of BK doc removal as encouraging some strict notion of what we can and cannot discuss, inside the kernel sources. _That_ is the free speech aspect.
I see enforcing a strict notion of acceptable speech in the kernel sources as a very bad thing for the Linux project.
I'm not asking you to agree -- but do you even understand my viewpoint here?
Quoted 8 lines
Quoted 7 lines
There is no dispute that the doc is useful, only dispute with certain beliefs. Disagreement is fine... encouraged, even. But that's a poor justification to remove the doc from the tree.
I hear your point, I really do. I just feel very strongly that removing the BK docs from the tree is the worst way to go about supporting this point of view.
Quoted 7 lines
I really don't see how changing out the files for a url qualifies as the "worst way" of addressing the issue. If Larry unretracts his offer to host the files - and I fully expect he will do that after some period of indulging in his wounded bird act - then by definition the documentation will always be available exactly when and where needed. Is there *anybody* here who'd have further license-related complaints about Bitkeeper if that were done? (Speak or forever hold your peace.)
First, I can host the doc. And will, if there is justification. I do not see a justification. Larry is irrelevant.
Second, I guarantee that license-related complaints about BitKeeper will continue to exist, regardless of the doc's location. Moving the doc does absolutely nothing to assauge bad feelings about the BK license.
Jeff
Quoted 10 lines · Larry McVoy
Quoted 3 lines · Daniel Phillips
Is there *anybody*
here who'd have further license-related complaints about Bitkeeper if that were done? (Speak or forever hold your peace.)Oh boy oh boy oh boy, if you can deliver a commitment that this is the last time we have a BK license-related complaint from a kernel hacker, I'll be the first to argue vehemently for that patch you want.
I'd like to know how you are going to deliver on that offer you just made.
Clearly I'm not going to shut anyone up. However, only somebody with a very limited perception of the situation could fail to note that you're being tested, and what you do next is going to help form attitudes for some time to come.
Signature · 1 line
Daniel
Quoted 13 lines · Jeff Garzik
Quoted 1 line · Daniel Phillips
1) It would be equally as useful as a URL
Maybe 5% less useful or so. There are reasons we move other (non-controversial) docs into the kernel source. 100% of these docs can be URLs.
Quoted 1 line
2) It would not consume download bandwidth
This is a silly argument that dean gaudet dismembered. It's 12K compressed and not your main argument at all.
Quoted 6 lines
Quoted 2 lines
3) It would show some sensitivity to the concerns of those who are uncomfortable with the license.
I agree.
So, I believe points #1 and #2 are silly, and #3 is your core argument.
I think you stated that #1 is only 5% silly, by implication, 95% unsilly. Two out of three ain't bad.
Quoted 5 lines
And I agree that it would show sensitivity towards those people who dislike the BK license.
That said, I still think removing the doc is a hideously wrong thing to do.
I agree. (/me listens for sound of garzik hitting floor) The doc was never to be removed, it was to be moved. Read the original mail please. I repeat:
I *like* your docs, in fact I think they are excellent docs. I just don't like to see them sitting in Documentation, for reasons we've been over in some detail.
Quoted 8 lines
I see the action of BK doc removal as encouraging some strict notion of what we can and cannot discuss, inside the kernel sources. _That_ is the free speech aspect.
I see enforcing a strict notion of acceptable speech in the kernel sources as a very bad thing for the Linux project.
I'm not asking you to agree -- but do you even understand my viewpoint here?
I do. I don't agree with you that any of this has something to do with free speech, but I'm willing to accept that you view the kernel source as a kind of podium.
Quoted 10 lines
Quoted 7 lines
I really don't see how changing out the files for a url qualifies as the "worst way" of addressing the issue. If Larry unretracts his offer to host the files - and I fully expect he will do that after some period of indulging in his wounded bird act - then by definition the documentation will always be available exactly when and where needed. Is there *anybody* here who'd have further license-related complaints about Bitkeeper if that were done? (Speak or forever hold your peace.)
First, I can host the doc. And will, if there is justification. I do not see a justification. Larry is irrelevant.
To this discussion? Debatable. I'll go with you on that for now though, and see where it leads.
Quoted 3 lines
Second, I guarantee that license-related complaints about BitKeeper will continue to exist, regardless of the doc's location. Moving the doc does absolutely nothing to assauge bad feelings about the BK license.
It would for me, others mileage may vary.
Signature · 1 line
Daniel
Quoted 17 lines · Daniel Phillips
Quoted 16 lines · Jeff Garzik
Quoted 1 line · Daniel Phillips
1) It would be equally as useful as a URL
Maybe 5% less useful or so. There are reasons we move other (non-controversial) docs into the kernel source. 100% of these docs can be URLs.
Quoted 1 line
2) It would not consume download bandwidth
This is a silly argument that dean gaudet dismembered. It's 12K compressed and not your main argument at all.
Quoted 2 lines
3) It would show some sensitivity to the concerns of those who are uncomfortable with the license.
Quoted 6 lines
Quoted 3 lines
I agree.
So, I believe points #1 and #2 are silly, and #3 is your core argument.
I think you stated that #1 is only 5% silly, by implication, 95% unsilly. Two out of three ain't bad.
I will grant you that :) but clarify:
Making is a URL is no big deal and shouldn't be a point of discussion, as I think #2 is no big deal and shouldn't be a point of discussion.
The real question, as I understand it, is whether or not the kernel doc should be in the kernel source or not. If the answer is 'no', then I fully support making it a URL, or printing it out the back of phonebooks, or whatever means of distribution :)
But I am arguing that the answer 'no' has not been justified yet...
Quoted 11 lines
Quoted 5 lines
And I agree that it would show sensitivity towards those people who dislike the BK license.
That said, I still think removing the doc is a hideously wrong thing to do.
I agree. (/me listens for sound of garzik hitting floor) The doc was never to be removed, it was to be moved. Read the original mail please. I repeat:
I *like* your docs, in fact I think they are excellent docs. I just don't like to see them sitting in Documentation, for reasons we've been over in some detail.
This is really a semantic argument... I shorten "removing from kernel sources" as "removing", because (correct me here) we are discussing what we want to see in the kernel sources, and what we do not want to see in the kernel sources.
Even without an official web site, the BK doc would live on in kernel archives if nowhere else.
If it makes things more clear, I can use my same arguments, and do a search-n-replace of "remove from kernel sources" to "move from kernel sources to elsewhere." To me, it's the same thing.
Quoted 4 lines
Quoted 4 lines
I see the action of BK doc removal as encouraging some strict notion of what we can and cannot discuss, inside the kernel sources. _That_ is the free speech aspect.
Quoted 8 lines
Quoted 4 lines
I see enforcing a strict notion of acceptable speech in the kernel sources as a very bad thing for the Linux project.
I'm not asking you to agree -- but do you even understand my viewpoint here?
I do. I don't agree with you that any of this has something to do with free speech, but I'm willing to accept that you view the kernel source as a kind of podium.
I conjecture, then, that moving the BK doc to satisfy sensitivies is also acknowledge of the kernel sources as a podium :)
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
I really don't see how changing out the files for a url qualifies as the "worst way" of addressing the issue. If Larry unretracts his offer to host the files - and I fully expect he will do that after some period of indulging in his wounded bird act - then by definition the documentation will always be available exactly when and where needed. Is there *anybody* here who'd have further license-related complaints about Bitkeeper if that were done? (Speak or forever hold your peace.)
Quoted 5 lines
Quoted 2 lines
First, I can host the doc. And will, if there is justification. I do not see a justification. Larry is irrelevant.
To this discussion? Debatable. I'll go with you on that for now though, and see where it leads.
hehe
Quoted 5 lines
Quoted 3 lines
Second, I guarantee that license-related complaints about BitKeeper will continue to exist, regardless of the doc's location. Moving the doc does absolutely nothing to assauge bad feelings about the BK license.
It would for me, others mileage may vary.
Interesting. And I will claim up-front that I don't understand this one bit. BitKeeper would still be in use with its odious license, and people will still say the "BitKeeper mafia" exists, even if the document is moved.
Jeff
Quoted 4 lines · Jeff Garzik
The real question, as I understand it, is whether or not the kernel doc should be in the kernel source or not. If the answer is 'no', then I fully support making it a URL, or printing it out the back of phonebooks, or whatever means of distribution :)
i really tried to remain out of this. in theory, like Linus said, we should not even know that he's using bk. it should be completely hidden. the only method described inside the kernel tarbal should be the old diff+patch one. main maintainers ( i mean the group of at most 10 that are handling huge number of patches and that are highly interacting with Linus ) will very likely get benefits from using bk instead of diff+patch, but for these one no doc is necessary. either they know or Larry can provide them with all the docs they need. for all the remaining crew, bk adoption is simply a trend followup.
- Davide
There is no cabal (was: the BK flamewar)
In reply to Jeff GarzikQuoted 7 lines · Davide Libenzi
Quoted 4 lines · Jeff Garzik
The real question, as I understand it, is whether or not the kernel doc should be in the kernel source or not. If the answer is 'no', then I fully support making it a URL, or printing it out the back of phonebooks, or whatever means of distribution :)
Quoted 9 lines
i really tried to remain out of this. in theory, like Linus said, we should not even know that he's using bk. it should be completely hidden. the only method described inside the kernel tarbal should be the old diff+patch one. main maintainers ( i mean the group of at most 10 that are handling huge number of patches and that are highly interacting with Linus ) will very likely get benefits from using bk instead of diff+patch, but for these one no doc is necessary. either they know or Larry can provide them with all the docs they need. for all the remaining crew, bk adoption is simply a trend followup.
Nope, the kernel doc was created precisely for the kernel maintainers, cuz most of them (like me) had no clue about how to use BK nicely for the kernel. Honestly, we were all lazy (except the PPC guys and GregKH, I guess :)) and let Linus figure out kernel development under BK.
If we attempt to pretend that BK is not widely usage, you do a dissservice to other kernel developers, sysadmins, and power users -- and possibly _increase_ the barrier to entry of the "group of at most 10" you describe above.
That "10" does not need do, and should never be, an exclusive club... it just sorta evolved over time as the people who work best with Linus. I want to spread knowledge about working well with Linus as far and as wide as possible -- that benefits all Linux users, and open source overall.
I think I have proven that I am working towards that goal, of publishing "Linus knowledge" -- I wrote not only the BK version of Doc/SubmittingPatches, but also Doc/SubmittingPatches itself.
Let the knowledge out there, and let people make their own decisions...
Jeff
Re: There is no cabal (was: the BK flamewar)
Quoted 29 lines · Jeff Garzik
Quoted 7 lines · Davide Libenzi
Quoted 4 lines · Jeff Garzik
The real question, as I understand it, is whether or not the kernel doc should be in the kernel source or not. If the answer is 'no', then I fully support making it a URL, or printing it out the back of phonebooks, or whatever means of distribution :)
Quoted 9 lines
i really tried to remain out of this. in theory, like Linus said, we should not even know that he's using bk. it should be completely hidden. the only method described inside the kernel tarbal should be the old diff+patch one. main maintainers ( i mean the group of at most 10 that are handling huge number of patches and that are highly interacting with Linus ) will very likely get benefits from using bk instead of diff+patch, but for these one no doc is necessary. either they know or Larry can provide them with all the docs they need. for all the remaining crew, bk adoption is simply a trend followup.
Nope, the kernel doc was created precisely for the kernel maintainers, cuz most of them (like me) had no clue about how to use BK nicely for the kernel. Honestly, we were all lazy (except the PPC guys and GregKH, I guess :)) and let Linus figure out kernel development under BK.
If we attempt to pretend that BK is not widely usage, you do a dissservice to other kernel developers, sysadmins, and power users -- and possibly _increase_ the barrier to entry of the "group of at most 10" you describe above.
Quoted 5 lines
That "10" does not need do, and should never be, an exclusive club... it just sorta evolved over time as the people who work best with Linus. I want to spread knowledge about working well with Linus as far and as wide as possible -- that benefits all Linux users, and open source overall.
Jeff, did you really mean this ?
"If we attempt to pretend that BK is not widely usage ..."
It did not seem to me that Linus required BK to interact with him. So to be or not to be inside the above group does not depend at all from BK usage. BK can make life a lot easier for guys handling huge number of patches with complex hierarchies, but forcing the one working with 1-5 patches to use it, it reflects the "trend followup" i was talking about.
- Davide
Re: There is no cabal (was: the BK flamewar)
In reply to Jeff GarzikQuoted 39 lines · Davide Libenzi
Quoted 29 lines · Jeff Garzik
Quoted 7 lines · Davide Libenzi
Quoted 4 lines · Jeff Garzik
The real question, as I understand it, is whether or not the kernel doc should be in the kernel source or not. If the answer is 'no', then I fully support making it a URL, or printing it out the back of phonebooks, or whatever means of distribution :)
Quoted 9 lines
i really tried to remain out of this. in theory, like Linus said, we should not even know that he's using bk. it should be completely hidden. the only method described inside the kernel tarbal should be the old diff+patch one. main maintainers ( i mean the group of at most 10 that are handling huge number of patches and that are highly interacting with Linus ) will very likely get benefits from using bk instead of diff+patch, but for these one no doc is necessary. either they know or Larry can provide them with all the docs they need. for all the remaining crew, bk adoption is simply a trend followup.
Nope, the kernel doc was created precisely for the kernel maintainers, cuz most of them (like me) had no clue about how to use BK nicely for the kernel. Honestly, we were all lazy (except the PPC guys and GregKH, I guess :)) and let Linus figure out kernel development under BK.
If we attempt to pretend that BK is not widely usage, you do a dissservice to other kernel developers, sysadmins, and power users -- and possibly _increase_ the barrier to entry of the "group of at most 10" you describe above.
Quoted 5 lines
That "10" does not need do, and should never be, an exclusive club... it just sorta evolved over time as the people who work best with Linus. I want to spread knowledge about working well with Linus as far and as wide as possible -- that benefits all Linux users, and open source overall.
Jeff, did you really mean this ?
Quoted 7 lines
"If we attempt to pretend that BK is not widely usage ..."
It did not seem to me that Linus required BK to interact with him. So to be or not to be inside the above group does not depend at all from BK usage. BK can make life a lot easier for guys handling huge number of patches with complex hierarchies, but forcing the one working with 1-5 patches to use it, it reflects the "trend followup" i was talking about.
If you read that from what I wrote, you are mistaken...
I'm saying that removing the BK doc from the kernel sources removes description of one, _optional_ avenue to Linus. That is denying people information.
Which is completely contrary to one of my goals, spreading knowledge about working with Linus to decrease the barrier of entry.
BK is not a requirement, even for regular submittors. Optional.
Jeff
Quoted 7 lines · Jeff Garzik
Quoted 3 lines · Daniel Phillips
I do. I don't agree with you that any of this has something to do with free speech, but I'm willing to accept that you view the kernel source as a kind of podium.
I conjecture, then, that moving the BK doc to satisfy sensitivies is also acknowledge of the kernel sources as a podium :)
More like a monument. Currently, with a billboard on it.
Signature · 1 line
Daniel
Quoted 10 lines · dean gaudet
Quoted 3 lines · Daniel Phillips
Riiiiight. I have at least forwarded your demands to those who have expressed their positions to me privately. If you think I'm going to violate their confidence on your whim, you can think again.
so then you're having private discussions in email, and one of your complaints is about other private discussions in email?
The reason why people do not express their disquiet is very plain - any time anyone dares comes out, they promptly get their head kicked in.
Guys, this problem is permanent, and it's not going away.
Larry has stated that kernel's use of bitkeeper is not providing collateral sales, and nor was it intended for that. Fair enough. But it's inevitable that, in some people's eyes, kernel's very public use of bitkeeper be viewed as promotion of bitmover's product, and as endorsement of bitmover's licensing innovations.
Some people don't like this, and never will. I'm tempted here to say "get over it". This disagreement is a permanent part of the kernel landscape.
Linus took the work of others and used it in a way which they did not expect, without their permission, and contrary to their wishes. He knew what he was doing, and he knew that some wouldn't like it. If he had chosen any other path, he'd be juggling ascii diffs until the end of time.
My take on Daniel's patch is that it is addressing the symptoms, not the problem. And the problem is unsolveable. The differences of opinion are irreconcilable. Both sides are populated by perfectly sensible people with perfectly legitimate points of view.
So. Life goes on. We will have regular bitkeeper flamewars, and that's a good thing - it reminds everyone that there are different opinions and different work practices which need to be accommodated.
Oh. And the problem of stealth patches is a human one, not a tool one. Tree owners should prefer to drop unreviewed patches. Not just because said patches may have bugs which they miss. Not just because having others check the work lightens their workload. Not just because others may have other, different implementations in the works. But also because it keeps everyone informed as to what's going on, and generally makes for a better development team.
It would help to avoid, say, the situation where random fs maintainer "A" is amazed to discover one day that a patch from random VFS maintainer "B" had caused said filesystem to be doing a surprise "up" on a non-downed semaphore. Not that this could ever happen.
-
Quoted 2 lines · Andrew Morton
The reason why people do not express their disquiet is very plain - any time anyone dares comes out, they promptly get their head kicked in.
In the "let's be fair" department, it's obvious that there is enough head kicking to go around on all sides, right? No answer needed...
Quoted 3 lines
So. Life goes on. We will have regular bitkeeper flamewars, and that's a good thing - it reminds everyone that there are different opinions and different work practices which need to be accommodated.
If Daniel had started out this thread with
Hey, I've noticed that the BK patches aren't getting as much review or notification on the lk list, is there something we can do about that?
He would have gotten a useful answer in a few minutes, and we would have moved on.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 4 lines · Andrew Morton
The reason why people do not express their disquiet is very plain - any time anyone dares comes out, they promptly get their head kicked in.
Guys, this problem is permanent, and it's not going away.
Yeah, it's a problem with religious perspectives at this point, things can occasionally get ugly :)
I'm really glad you are speaking up, though...
Quoted 5 lines
Larry has stated that kernel's use of bitkeeper is not providing collateral sales, and nor was it intended for that. Fair enough. But it's inevitable that, in some people's eyes, kernel's very public use of bitkeeper be viewed as promotion of bitmover's product, and as endorsement of bitmover's licensing innovations.
Agreed -- but one can also see it just as real life, a compromise with proven open source productivity gains. Linus, myself, and others have repeatedly been saying that we would use a superior free software tool...
At the end of the day, I think the open source cause is advanced by this non-open-source tool, because Linux kernel development (or at least the rate of patch application) is by all measures "faster."
By extension, discouraging use of BitKeeper when it is clearly useful potentially harms the cause of open source.
Quoted 3 lines
Linus took the work of others and used it in a way which they did not expect, without their permission, and contrary to their wishes. He knew what he was doing, and he knew that some wouldn't like it.
I think that's a bit unfair :( All Linus did was add an additional method of patch transport... the source code is still the same bitrotten hunk of poo we all know, love, and work on :)
Quoted 4 lines
My take on Daniel's patch is that it is addressing the symptoms, not the problem. And the problem is unsolveable. The differences of opinion are irreconcilable. Both sides are populated by perfectly sensible people with perfectly legitimate points of view.
Pretty much my conclusion...
Jeff
Quoted 15 lines · Daniel Phillips
Quoted 6 lines · Jeff Garzik
Quoted 4 lines · Daniel Phillips
Quoted 3 lines · Jeff Garzik
Quoted 2 lines · Daniel Phillips
How much less convenient is it to click on a link? So much harder that it's worth pissing off some key developers?
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Linus has already explained why he put it into the kernel sources.
So far the only argument I've seen is: it's convenient. Did I miss something? The convenience argument is bogus. A url is just as convenient,
If you say this, then you either missed, or are willfully ignoring, what Linus said. Search for the string "helsinki.fi".
Quoted 7 lines
Quoted 3 lines · Linus
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),Larry has offered to host it, so Linus's argument is answered.
These are docs-about-Linus, not docs-about-Larry.
Do you propose to move SubmittingPatches and all info related to CVS, to Larry's web site?
If not... (see the last line of Linus's first response in this thread)
Jeff
Quoted 5 lines
Quoted 3 lines
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
If you think I'm going to aid in your silliness, think again.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 22 lines · Jeff Garzik
Quoted 21 lines · Daniel Phillips
Quoted 13 lines · Jeff Garzik
Quoted 9 lines · Daniel Phillips
Quoted 5 lines · Jeff Garzik
Quoted 2 lines · Daniel Phillips
How much less convenient is it to click on a link? So much harder that it's worth pissing off some key developers?
Linus has already explained why he put it into the kernel sources.
So far the only argument I've seen is: it's convenient. Did I miss something? The convenience argument is bogus. A url is just as convenient,
If you say this, then you either missed, or are willfully ignoring, what Linus said. Search for the string "helsinki.fi".
Quoted 3 lines · Linus
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),
Quoted 6 lines
Quoted 1 line
Larry has offered to host it, so Linus's argument is answered.
These are docs-about-Linus, not docs-about-Larry.
Do you propose to move SubmittingPatches and all info related to CVS, to Larry's web site?
Which part of 'Larry offered to host it' was not completely clear?
CVS does not have the license issues. Red herring.
Signature · 1 line
Daniel
Quoted 10 lines · Larry McVoy
Quoted 5 lines
Quoted 3 lines
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
So the offer was not in good faith.
Signature · 1 line
Daniel
Quoted 5 lines · Daniel Phillips
Quoted 4 lines · Larry McVoy
Quoted 4 lines
Quoted 3 lines
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
So the offer was not in good faith.
Like I said, Daniel, put up or shut up. Would you like me to go through the thread and come up with a list of claims you have made, been challenged on, and refuse to substantiate?
We can discuss the good-faith issue *after* you answer the questions.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 6 lines · Daniel Phillips
Quoted 4 lines
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
So the offer was not in good faith.
Daniel: I thought better of you.
Signature · 4 lines
--------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com
Quoted 10 lines · Daniel Phillips
Quoted 9 lines · Jeff Garzik
Quoted 7 lines · Daniel Phillips
Quoted 3 lines · Linus
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),Larry has offered to host it, so Linus's argument is answered.
Quoted 8 lines
Quoted 4 lines
These are docs-about-Linus, not docs-about-Larry.
Do you propose to move SubmittingPatches and all info related to CVS, to Larry's web site?
Which part of 'Larry offered to host it' was not completely clear?
CVS does not have the license issues. Red herring.
No, this is, to me, _the_ issue. And something you keep ignoring. And proving that you ignored the point of Linus's first post in this thread.
We have docs describing how kernel developers should merge with Linus. In your opinion, if those docs describe closed source software, they should be treated differently than other docs. Regardless of relevance.
They _are_ relevant, everyone admits that. Therefore treating them differently only introduces additional barriers and violates the Principle of Least Surprise.
You are, in effect, trying to disallow politically incorrect speech from the kernel sources.
Jeff
Quoted 13 lines · Larry McVoy
Quoted 12 lines · Daniel Phillips
Quoted 10 lines · Larry McVoy
Quoted 5 lines
Quoted 3 lines
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
Quoted 5 lines
Quoted 1 line
So the offer was not in good faith.
Like I said, Daniel, put up or shut up. Would you like me to go through the thread and come up with a list of claims you have made, been challenged on, and refuse to substantiate?
Larry, you just lathered on a bunch of new conditions of dubious merit. I understand by this that you had no real intention of following through on your offer because you thought that it would never get close to becoming reality.
Quoted 1 line
We can discuss the good-faith issue *after* you answer the questions.
Riiiiight. I have at least forwarded your demands to those who have expressed their positions to me privately. If you think I'm going to violate their confidence on your whim, you can think again.
Signature · 1 line
Daniel
Quoted 9 lines · Daniel Phillips
Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
So the offer was not in good faith.
Quoted 8 lines
Quoted 3 lines
Like I said, Daniel, put up or shut up. Would you like me to go through the thread and come up with a list of claims you have made, been challenged on, and refuse to substantiate?
Larry, you just lathered on a bunch of new conditions of dubious merit. I understand by this that you had no real intention of following through on your offer because you thought that it would never get close to becoming reality.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
(follow up again, get the same response, cut and paste is easy).
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 13 lines · Larry McVoy
Quoted 12 lines · Daniel Phillips
Quoted 10 lines · Larry McVoy
Quoted 5 lines
Quoted 3 lines
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long since forgotten the password to my old helsinki.fi account ;),Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer the questions you have been asked. You've made one unsubstantiated claim after another and when challenged, you tell the challenger to do the legwork to support your unsubstantiated claim.
Quoted 5 lines
Quoted 1 line
So the offer was not in good faith.
Like I said, Daniel, put up or shut up. Would you like me to go through the thread and come up with a list of claims you have made, been challenged on, and refuse to substantiate?
Yes.
Signature · 1 line
Daniel