Earlier this year, Linus agreed to test out BitKeeper, Larry McVoy's source management tool. Its non-open-source licensing has lead to a fury of protest and discussion. In the latest saga detailed below, Linus explains, "Quite frankly, I don't _want_ people using Linux for ideological reasons. I think ideology sucks. This world would be a much better place if people had less ideology, and a whole lot more 'I do this because it's FUN and because others might find it useful, not because I got religion'."
This was in reply to when Daniel Phillips recently noticed that Jeff Garzik's BitKeeper HOWTO, "Doing the BK Thing, Penguin-Style", is included in the base Linux kernel distribution. "I see that Bitkeeper documentation has quietly been inserted ino the Linux Documentation directory, and that without any apparent discussion on lkml." He submitted a patch to remove the HOWTO, "I do not support the infusion of documentation for proprietary software products into the Linux tree. The message is that we have gone beyond optional usage of Bitkeeper here, and it is now an absolute requirement, or it is on the way there."
As expected, a furious discussion followed. Jeff Garzik, the HOWTO's author, suggested, "You are taking away freedoms by restricting speech, making documents less available than they previously were. Take your closed mind elsewhere." And in a seperate email, he adds more abruptly, "Rot in hell, closed mind."
Linus' specifically talked about the BitKeeper license, adding, "Would I prefer to use a tool that didn't have any restrictions on it for kernel maintenance? Yes. But since no such tool exists, and since I'm personally not very interested in writing one, _and_ since I don't have any hangups about using the right tool for the job, I use BitKeeper.
BitKeeper author, Larry McVoy, explained that the BitKeeper licensing was a financial necessity. "I'm terribly sorry that this product space doesn't generate enough consulting business that it can support itself in a politically correct way, but it doesn't. Get over it. You either get crap tools or you get tools that have a business model. In this space, the GPL doesn't work, you need some other way to pay for the work." He went on to challenge anyone to write a better tool, saying, "If you don't agree, by all means, feel free to *prove* me wrong by designing, implementing, and supporting a better (or as good) answer. That is what Linus has said, and I agree, and the "silently seething" folks need to either put up or go back to being silent."
Later in the thread, Rob Landley offered additional perspective, saying, "Proprietary software sucks when you derive work from it in an exclusive and dependent way. Then they own your derived work. (Like a microsoft word file you wrote, which microsoft can charge you to access because they own word and your file is useless without it.) When it's something you can use but don't have to, it's basically a service. Not owning a service is unsuprising." And specifically tieing the argument to BitKeeper, he continued, "In this case, none of the Linux kernel's end product is derived from bitkeeper. It's just using bitkeeper as an optional tool in the process of producing that work. It's analogous to using a proprietary bios to boot your Linux kernel: if it causes a problem, it can be replaced without changing the kernel being booted in any way."
One postitive change to come about from this thread are two online archives. David Woodhouse was first, saying, "For the benefit of the BK haters, or more to the point for my benefit to shut up the occasional whinging I've heard about needing to use BK to get at the very latest patches from Linus' tree...". He offers an up-to-the hour GNU-style patch set complete with lengthy comments for the 2.5 development tree as well as the 2.4 stable tree. These patches are automatically created every hour from the main BK trees. In other words, even a non-BK user now has easy access to both trees.
Rik van Riel also has made available a simialar GNU-style patch archive for 2.4 and 2.5.
For the benefit of the BK haters, or more to the point for my benefit to
shut up the occasional whinging I've heard about needing to use BK to get
at the very latest patches from Linus' tree...
http://www.kernel.org/~dwmw2/bk-2.5/
It should be updated every hour on the hour, and has the last week's worth
of changesets exported as patches.
--
dwmw2
From: Daniel Phillips
To: Linus Torvalds, linux-kernel Mailing List
Subject: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 17:12:33 +0200
Hi Linus,
I have up to this point been open to the use of Bitkeeper as a development
aid for Linux, and, again up to this point, have intended to make use of
Bitkeeper myself, taking a pragmatic attitude towards the concept of using
the best tool for the job. However, now I see that Bitkeeper documentation
has quietly been inserted ino the Linux Documentation directory, and that
without any apparent discussion on lkml. I fear that this demonstrates that
those who have called the use of Bitkeeper a slippery slope do have a point
after all.
I respectfully request that you consider applying the attached patch, which
reverses these proprietary additions to the Documentation directory. Perhaps
a better place for this documentation would be on kernel.org if Peter Anvin
agrees, or the submitter's own site if he does not. Or perhaps bitkeeper.com
would be willing to host these files.
Please do not misinterpret my position: I count Larry as something more than
a personal acquaintance. I strongly support his efforts to build a business
for himself out of his Bitkeeper creation. I even like Jeff Garzik's
documentation, the subject of this patch. I do not support the infusion of
documentation for proprietary software products into the Linux tree. The
message is that we have gone beyond optional usage of Bitkeeper here, and it
is now an absolute requirement, or it is on the way there.
I hope that this proposed patch will receive more discussion than the
original additions to Documentation did.
Thankyou,
Daniel
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 11:52:33 -0400
Guess what? You have the freedom to ignore these docs.
Guess what else? You are taking away freedoms by restricting speech,
making documents less available than they previously were.
Take your closed mind elsewhere. I'm pretty sure Linus has more sense
than to apply this patch.
Jeff
From: Roman Zippel
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 18:16:48 +0200
Hi,
Jeff Garzik wrote:
> Guess what else? You are taking away freedoms by restricting speech,
> making documents less available than they previously were.
So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
information as well?
You certainly don't want to restrict the freedoms of other users?
bye, Roman
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 12:25:41 -0400
Two issues here:
1) Daniel was attempting a 'remove' operation, you are describing an
'add'. The operations do the exact opposite in terms of information
dissemination.
2) If someone writes a good guide to using Arch with the Linux kernel,
or subversion, I don't have an objection to putting it into
Documentation.
Daniel disagrees with the content of the speech in
Documentation/BK-usage, based on his ideology. And he attempted to
restrict the dissemination of that speech. What is the definition
of censorship again?
People may think I'm just pissed because it's my doc he wanted to
remove, but that's only partially true. I see this as a clear cut
case of Daniel's ideology pushing him to attempt to restrict speech.
That is anti-freedom, no matter how you look at it, regardless of
whether we are talking about BitKeeper or anything else.
Maybe we should have warning labels on software, indicating that
a product does not conform completely to some idealist notion of
free software.
Jeff
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 18:33:41 +0200
On Saturday 20 April 2002 18:25, Jeff Garzik wrote:
> Two issues here:
> 1) Daniel was attempting a 'remove' operation, you are describing an
> 'add'. The operations do the exact opposite in terms of information
> dissemination.
No I do not. Read the post. I suggested placing the documentation on
kernel.org, on your site, or on bitmover.com where it belongs. This
documentation for a proprietary software product does not belong in the
Linux kernel tree itself. It is nothing less than an advertisement.
Was it paid for?
(And there you may have an argument that would satisfy me. However, it
is not me I'm worried about. It is the other kernel developers who are
silently seething at this situation. Yes they are, use your ears.)
--
Daniel
From: Linus Torvalds
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 09:56:21 -0700 (PDT)
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> No I do not. Read the post. I suggested placing the documentation on
> kernel.org, on your site, or on bitmover.com where it belongs.
That was not what your patch did.
> (And there you may have an argument that would satisfy me. However, it
> is not me I'm worried about. It is the other kernel developers who are
> silently seething at this situation. Yes they are, use your ears.)
I would suggest that if you are silently seething about the fact that a
commercial product can do something better than a free one, how about
_doing_ something about it?
Quite frankly, I don't _want_ people using Linux for ideological reasons.
I think ideology sucks. This world would be a much better place if people
had less ideology, and a whole lot more "I do this because it's FUN and
because others might find it useful, not because I got religion".
Would I prefer to use a tool that didn't have any restrictions on it for
kernel maintenance? Yes. But since no such tool exists, and since I'm
personally not very interested in writing one, _and_ since I don't have
any hangups about using the right tool for the job, I use BitKeeper.
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 ;), and I have
absolutely no interest in web page design. So when I got tired of
explaining how to use BK, I asked Jeff to just send me a patch so that I
could point people to the only thing I _do_ care about, ie the kernel
sources.
Linus
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 19:17:34 +0200
On Saturday 20 April 2002 18:56, Linus Torvalds wrote:
> That was not what your patch did.
Oh, please show me how and I will do it gladly. I just don't know how to
make diff+patch do that.
> I would suggest that if you are silently seething about the fact that a
> commercial product can do something better than a free one,
You got that right.
> how about _doing_ something about it?
However, first I personally do not want to start that project. Firstly, I
do personally like Larry and do not want to be part of a horde bent on
tearing down his business. There are after all, plenty of genuinely nasty
things out there to attack, attacking Larry as *way* down my list. More
importantly, my time is better spent improving Linux.
> Quite frankly, I don't _want_ people using Linux for ideological reasons.
> I think ideology sucks. This world would be a much better place if people
> had less ideology, and a whole lot more "I do this because it's FUN and
> because others might find it useful, not because I got religion".
That's the point. It is not fun to see the whole thing start tearing itself
apart. Fun is being on the winning side. Fun is not dealing with a lot of
stressed out people with agendas.
> Would I prefer to use a tool that didn't have any restrictions on it for
> kernel maintenance? Yes. But since no such tool exists, and since I'm
> personally not very interested in writing one, _and_ since I don't have
> any hangups about using the right tool for the job, I use BitKeeper.
I use it too. I do not think it belongs in the tree, especially not with its
own directory. My point, pure and simple.
> 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 ;), and I have
> absolutely no interest in web page design. So when I got tired of
> explaining how to use BK, I asked Jeff to just send me a patch so that I
> could point people to the only thing I _do_ care about, ie the kernel
> sources.
But did you think it might be controversial?
--
Daniel
From: Linus Torvalds
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 10:35:43 -0700 (PDT)
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> But did you think it might be controversial?
Ehh, the documentaion? Nope, I didn't really think _that_ part would be
controversial.
The change to BK? I sure as hell knew that was going to be "interesting",
yes absolutely. After all, it had been discussed at places like the kernel
summit etc.
But hey - I've never really cared about what other people think about what
I do. If I had, I'd have given up on Linux when Tanenbaum ridiculed it. Or
I wouldn't have done the big dentry change (which was a total disaster in
some peoples minds) in 2.1.x. Or the VM changeover in the middle of 2.4.x.
Or a million other things.
I do what _I_ think is right for the kernel, and while I tend to poll
people and listen to them, when the sh*t hits the fan it is _my_ decision.
You can't please everybody. And usually if you _try_ to please everybody,
the end result is one big mess.
Linus
Hi,
> Quite frankly, I don't _want_ people using Linux for ideological reasons.
> I think ideology sucks. This world would be a much better place if people
> had less ideology, and a whole lot more "I do this because it's FUN and
> because others might find it useful, not because I got religion".
Several guys (mis-)use Linux as war against Windows, which is really
childish. But it seems they're an important amount, on both sides (There
are even users who use Windows as a protest against Linux). That does,
however, not help you to get an non-propietary tool.
As long as there is nothing I could use instead, it's a good idea to use
BitKeeper instead, and as long as there is a way to use it, users will
actually look it up in the Documentation dir. If users don't find an
answer there, they'll certainly massively bother the LKML.
Documentation also contains information on how to use existing tools
with Linux Kernel. If we exclude BitKeeper just because it's propietary
tool, we'll get into trouble.
BTW, why then do we include processor support into the kernel tree? I
can't find any way to download them from the Internet!
Regards,
Thunder
Linus Torvalds Awoke this dragon, who will now respond:
> "I do this because it's FUN and
> because others might find it useful, not because I got religion".
Dude, I agree, but that is your /IDEOLOGY/, is it not?
Hi,
Jeff Garzik wrote:
> Daniel disagrees with the content of the speech in
> Documentation/BK-usage, based on his ideology. And he attempted to
> restrict the dissemination of that speech. What is the definition
> of censorship again?
Maybe I was to subtle, but your censorship argument is simply bullshit.
A link to the information is completely sufficient. The only question
is, whether the information is relevant for kernel development and most
of it is only bk documentation.
bye, Roman
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 17:03:48 -0400
On Sat, Apr 20, 2002 at 07:19:23PM +0200, Roman Zippel wrote:
> Maybe I was to subtle, but your censorship argument is simply bullshit.
> A link to the information is completely sufficient.
What was Daniel's action? Remove the text. Nothing else. Sure, he
suggested other options, but he did attempt to implement them? No.
He just implied that people need to step up and do this work for him.
Daniel attempted to remove speech he disgreed with from wide
distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
it is plainly obvious that removing a doc from one of the mostly
widely distributed open source projects reduces the doc's distribution
dramatically. _That_ is a form of censorship, just like buying out
printing presses, to silence them, in the old days. It's still
around... just progressively harder to obtain.
> The only question
> is, whether the information is relevant for kernel development and most
> of it is only bk documentation.
And the answer is, it is BK documentation written for kernel developers
by kernel developers, with the intention of being a SubmittingPatches
document for BK users. Very relevant to kernel devel. This relevance
was proved by its origin -- emails bouncing back and forth, generally
originating by Linus, CC'ing me, asking me for the emails I had
already sent to other hackers, describing kernel development under BK.
After the info had been separately requested multiple times, it
got turned into a document -- the BK version of SubmittingPatches.
After that doc was requested multiple times, it went to the same
place where SubmittingPatches is stored.
Jeff
From: Skip Ford
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 17:36:45 -0400
Jeff Garzik wrote:
> And the answer is, it is BK documentation written for kernel developers
> by kernel developers, with the intention of being a SubmittingPatches
> document for BK users. Very relevant to kernel devel. This relevance
> was proved by its origin -- emails bouncing back and forth, generally
> originating by Linus, CC'ing me, asking me for the emails I had
> already sent to other hackers, describing kernel development under BK.
That's not true. Section 1 of 'SubmittingPatches' is entitled
"Creating and Sending Your Change" while section 1 of your
bk bullshit is called "Bitkeeper Concepts."
All of section 1 is an advertisement for using bk...including
directions on how to setup your own clone. Those are _clearly_
bitkeeper directions and have nothing to do with how to submit
patches.
Delete sections 1 & 2 and make section 3 the gist of the document
and _then_ you'll have the bk equivalent of 'SubmittingPatches.'
--
Skip
From: Rik van Riel
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 18:40:11 -0300 (BRT)
On Sat, 20 Apr 2002, Skip Ford wrote:
> All of section 1 is an advertisement for using bk...including
> directions on how to setup your own clone. Those are _clearly_
> bitkeeper directions and have nothing to do with how to submit
> patches.
I'm sure Jeff would be more than happy to include an
advertisement for a free bitkeeper alternative, once
one exists. ;)
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
From: Larry McVoy
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 16:14:34 -0700
> On Sat, 20 Apr 2002, Skip Ford wrote:
> I'm sure Jeff would be more than happy to include an
> advertisement for a free bitkeeper alternative, once
> one exists. ;)
And the sooner the better. I just read this entire thread and I'm disgusted.
I've seen some lame threads in my day, but this takes the cake.
On Sat, Apr 20, 2002 at 05:36:45PM -0400, Skip Ford wrote:
> That's not true. Section 1 of 'SubmittingPatches' is entitled
> "Creating and Sending Your Change" while section 1 of your
> bk bullshit is called "Bitkeeper Concepts."
>
> All of section 1 is an advertisement for using bk...including
> directions on how to setup your own clone. Those are _clearly_
> bitkeeper directions and have nothing to do with how to submit
> patches.
What you call an ad is the result of evolution of several resendings
of similar emails, and answering FAQs. This is the stuff that has
proven useful over time.
To call that an advertisement is to insult the kernel developers
that asked these questions, which are answered in the doc. They were
not requesting endorsements, they were asking honest questions about
ways to optimize their kernel development, and merging with Linus.
Responding with an intro on how BK clones work has proven to be a
good first step to that.
Jeff
Hi,
Jeff Garzik wrote:
> What was Daniel's action? Remove the text. Nothing else. Sure, he
> suggested other options, but he did attempt to implement them? No.
> He just implied that people need to step up and do this work for him.
He made his intention very clear, you are interpreting something in his
action, that simply isn't there.
> Daniel attempted to remove speech he disgreed with from wide
> distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
> it is plainly obvious that removing a doc from one of the mostly
> widely distributed open source projects reduces the doc's distribution
> dramatically. _That_ is a form of censorship, just like buying out
> printing presses, to silence them, in the old days. It's still
> around... just progressively harder to obtain.
Censorship requires the means to enforce it and has Daniel this ability?
Could we please stop these "censorship" and "ideology" arguments? In
this context they are simply nonsense.
> And the answer is, it is BK documentation written for kernel developers
> by kernel developers, with the intention of being a SubmittingPatches
> document for BK users. Very relevant to kernel devel. This relevance
> was proved by its origin -- emails bouncing back and forth, generally
> originating by Linus, CC'ing me, asking me for the emails I had
> already sent to other hackers, describing kernel development under BK.
kernel development with bk requires net access and so it's sufficient,
when it's available over the net. On the other hand SubmittingPatches
describes the lowest common denominator, which works with any SCM and
doesn't favour any of them.
Personally I don't care what tools people use, but I'm getting
concerned, when a nonfree tool is advertised as tool of choice for
kernel for development as if there would be no choice. bk has advantages
for distributed development, but beside of this they are alternatives
and we should rather encourage users to try them and to help with the
development of them. But there isn't anything like that, so Joe Hacker
has to think he should use bk as SCM to get his patch into the kernel,
because Linus is using it.
bye, Roman
From: Larry McVoy
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 17:17:14 -0700
On Sun, Apr 21, 2002 at 02:04:07AM +0200, Roman Zippel wrote:
> kernel development with bk requires net access and so it's sufficient,
> when it's available over the net. On the other hand SubmittingPatches
> describes the lowest common denominator, which works with any SCM and
> doesn't favour any of them.
Huh? BK requires no more net access than you require when submitting
a regular patch. You need to be connected to move the bits. Working
disconnected is one of the things BK does best, compare it to any other
tool and you can do far more with BK unconnected, simply because BK
takes the history with you.
If they start to be tools that are used to submit changes to the kernel
then yes they should be included.
remember that the reason for the bitkeeper documentation is to help people
setup a tree that Linus (and others) can pull from, not to help people
setup their own tree just for them to hack on. Currently none of the tree
maintainers use cvs/rcs/sccs/arch/subversion/aegis/prcs in such a way that
there is anything that someone hacking the kernel needs to do to be
compatable (other then following the existing documentation for sending
patches) but for bitkeeper there is so this documentation is needed.
David Lang
From: Roman Zippel
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 19:05:29 +0200
Hi,
David Lang wrote:
> If they start to be tools that are used to submit changes to the kernel
> then yes they should be included.
"start"? People used other source management system already before bk.
> remember that the reason for the bitkeeper documentation is to help people
> setup a tree that linux (and others) can pull from, not to help people
> setup their own tree just for them to hack on.
The problem is that this suggest, bk would be the choice for kernel
development or even usage. They are lots of kernel projects, which use
cvs, but noone before considered submitting extensive cvs documentation
into the kernel.
bye, Roman
From: Linus Torvalds
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 10:16:43 -0700 (PDT)
On Sat, 20 Apr 2002, Roman Zippel wrote:
> They are lots of kernel projects, which use cvs, but noone before
> considered submitting extensive cvs documentation into the kernel.
More importantly, there was no way in hell I would synchronize with a CVS
tree, so CVS was a non-entity as far as patch submittal was concerned.
The BK documentation is _nothing_ more than a alternative to
"SubmittingPatches".
Anyway, I'm not going to discuss this any more. If somebody has actual
construcive ideas about trying to improve other tools or putting the BK
docs in some place that is equally obvious and easily available for all
parties but somehow "less disturbing" to people with a weak stomach, go
for it. But I'm not interested in yet another religious whine-war.
Linus
On Sat, 20 Apr 2002, Jeff Garzik wrote:
> Take your closed mind elsewhere. I'm pretty sure Linus has more sense
> than to apply this patch.
Absolutely.
Like it or not, I personally use BK. I don't use CVS, and I don't use
subversion.
If anybody wants to maintain his own kernel, feel free to remove the
documentation on how to interact with _me_. In such a kernel, those docs
would obviously be meaningless.
In fact, Daniel, if you had bothered to just even grep for CVS, you would
have noticed that we've had CVS information for some other subprojects
too, because _they_ happen to use CVS. Would you argue for removal of the
CVS information in Documentation/filesystems/jfs.txt file?
And if not, then you're a hypocritical bastard with a religious agenda.
Linus
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 18:45:32 +0200
On Saturday 20 April 2002 18:37, Linus Torvalds wrote:
> In fact, Daniel, if you had bothered to just even grep for CVS, you would
> have noticed that we've had CVS information for some other subprojects
> too, because _they_ happen to use CVS. Would you argue for removal of the
> CVS information in Documentation/filesystems/jfs.txt file?
>
> And if not, then you're a hypocritical bastard with a religious agenda.
Err, and if I to argue for it then I'm not? That's easy I argue for it.
Do you think the jfs team will object?
Anyway, that was not serious, I will not argue for the removal of
information on how to use CVS, and gpl'd tool, from the tree. Even though
I think the tree would be better off without it. This is not an issue.
A steady slide toward proprietary tools and behind-the-scenes development
in cathedral-style is an issue. This is not the Linux I knew, or thought
I knew, it is more like FreeBSD.
--
Daniel
On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> Please do not misinterpret my position: I count Larry as something more than
> a personal acquaintance. I strongly support his efforts to build a business
> for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> documentation, the subject of this patch. I do not support the infusion of
It's also really, really, low class to not even CC me in your attempt
to remove the documentation I wrote from the kernel tree, and placed
into the kernel tree at Linus's request.
Rot in hell, closed mind.
Jeff
From: Nils Philippsen
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: 20 Apr 2002 18:29:11 +0200
On Sat, 2002-04-20 at 17:54, Jeff Garzik wrote:
> It's also really, really, low class to not even CC me in your attempt
> to remove the documentation I wrote from the kernel tree, and placed
> into the kernel tree at Linus's request.
>
> Rot in hell, closed mind.
You seriously have to improve your manners. Dubbing someone low class
while using such phrases is pretty double standards. Is it really so
difficult to calm down before replying? But I guess I'm just restricting
your freedom of speech.
Nils
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 12:56:14 -0400
On Sat, Apr 20, 2002 at 06:29:11PM +0200, Nils Philippsen wrote:
> You seriously have to improve your manners. Dubbing someone low class
> while using such phrases is pretty double standards. Is it really so
> difficult to calm down before replying? But I guess I'm just restricting
> your freedom of speech.
I never claimed I was not low class[1] ;-) And no, you're not
restricting free speech at all... Posts like yours are a celebration of
free speech.
Jeff
[1] I often joke with my friends, "I've got plenty of class... all of it
low." Usually after telling a tasteless joke :)
Daniel,
This is not documentation for bitkeeper but how to use bitkeeper
effectively for kernel development. It happens to be DAMN USEFULL
documentation at that for anyone wanting to use bitkeeper for kernel
development so IMO it fully belongs in the kernel. Just like the
SubmittingPatches document does, too. Or are you going to remove that as well?
If you don't want to use bitkeeper you don't need to read this
documentation. Just ignore it and stick with what is SubmittingPatches
document.
What's your problem?
Best regards,
Anton
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 18:21:55 +0200
On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> Daniel,
> This is not documentation for bitkeeper but how to use bitkeeper
> effectively for kernel development. It happens to be DAMN USEFULL
> documentation at that for anyone wanting to use bitkeeper for kernel
> development so IMO it fully belongs in the kernel. Just like the
> SubmittingPatches document does, too. Or are you going to remove that as well?
By that logic, we should also include the lkml FAQ in the kernel tree. Should
we?
> If you don't want to use bitkeeper you don't need to read this
> documentation. Just ignore it and stick with what is SubmittingPatches
> document.
>
> What's your problem?
I am worried that a creeping takeover of the Linux hitherto-successful
development process is in progress, that concensus on this topic has not been
achieved, and that there is a split coming. That would not be good.
As always, what I do is in the interest of Linux and freedom. That interest
is not served by driving a wedge firmly between two groups of Linux developers.
I hope you understand that I am a *moderate* with respect to this issue.
--
Daniel
From: Anton Altaparmakov
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 17:51:49 +0100
At 17:21 19/04/02, Daniel Phillips wrote:
>By that logic, we should also include the lkml FAQ in the kernel tree. Should
>we?
The lkml FAQ is aimed at users, not developers. The bitkeeper and the
SubmittingPatches document are aimed at developers. I see a fundamental
difference here...
>I am worried that a creeping takeover of the Linux hitherto-successful
>development process is in progress, that concensus on this topic has not been
>achieved, and that there is a split coming. That would not be good.
>
>As always, what I do is in the interest of Linux and freedom. That interest
>is not served by driving a wedge firmly between two groups of Linux
>developers.
>I hope you understand that I am a *moderate* with respect to this issue.
The fact that some developers use bitkeeper has no effect on other
developers. Well ok, it means that the bk using developers can work faster
but that is not at issue here...
I don't see why there should be any kind of split or anything like that.
Everything continues as before. It's just that some developers now have a
much easier life...
Anton
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 19:05:52 +0200
On Saturday 20 April 2002 18:51, you wrote:
> The fact that some developers use bitkeeper has no effect on other
> developers.
On the contrary, I think it has divided the kernel developers firmly into
two classes: the "ins" and the "outs".
> Well ok, it means that the bk using developers can work faster
> but that is not at issue here...
Oh I don't disagree at all. Bitkeeper is a big improvement over what
existed before. But it is proprietary. Which other tool in the tool chain
is proprietary?
Heck, it's not even that proprietary. As far as I know I can still download
the source. But... looking at those files sitting in the Documentation
directory, it looks to me like a big old Marlbourough[TM] ad.
> I don't see why there should be any kind of split or anything like that.
> Everything continues as before. It's just that some developers now have a
> much easier life...
And some have a more difficult one. So it goes.
--
Daniel
From: Linus Torvalds
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 10:09:53 -0700 (PDT)
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> And some have a more difficult one. So it goes.
How?
Linus
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Fri, 19 Apr 2002 19:32:36 +0200
On Saturday 20 April 2002 19:09, Linus Torvalds wrote:
> How?
Those who now chose to carry out their development using the patch+email
method, and prefer to submit everything for discussion on lkml before it
gets included are now largely out of the loop. Things just seem to *appear*
in the tree now, without much fanfare. That's my impression.
Rather than Linux development becoming more open, as I'd hoped with the
advent of Bitkeeper, it seems to be turning more in the direction of
becoming a closed club. This may be fun if you're a member of the club.
Ah well, I'm a 'sorta' club member, why should I complain? All the same,
I feel that something we all seemed to be headed towards with unity of
purpose is somehow becoming more elusive. Being attacked personally for
having this feeling does not help.
--
Daniel
From: Linus Torvalds
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 10:51:15 -0700 (PDT)
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> Those who now chose to carry out their development using the patch+email
> method, and prefer to submit everything for discussion on lkml before it
> gets included are now largely out of the loop. Things just seem to *appear*
> in the tree now, without much fanfare. That's my impression.
I don't buy that - I'm not getting changes from any new magical BK "men in
black". The patches are the same kind they always were, the last few
entries in my changelog are now the x86-64 merge (which was half a meg,
and yes it wasn't posted on linux-kernel, but no, it never was before BK
either), and before that the extensively discussed SSE register content
leak patch.
HOWEVER, the fact that you _feel_ like that is clearly a fact.
Any suggestions on how to make the process _appear_ less intimidating?
Note that one thing that I had hoped BK would do for me, but that hasn't
happened because I'm a lazy bastard and I'm bad at doing automated scripts
is to do dialy snapshots as patches (getting rid of the "-pre" kernels,
since they don't actually add any information except act as update
points), and also send out a changelog daily to the kernel mailing list.
That is something that is one of the big _points_ to using source control,
yet because I don't need it personally I've never gotten around to writing
those scripts.
That would actually make the development process MORE open than it was
before BK, and might make even non-BK people appreciate BK more simply
because there is a real point to it.
Comments? Anybody want to hack up a script to do this?
Linus
From: Andi Kleen
Subject: Re: [PATCH] Remove BK docs ... + x86-64 2.5.8 sync
Date: 20 Apr 2002 20:14:29 +0200
Linus Torvalds writes:
> I don't buy that - I'm not getting changes from any new magical BK "men in
> black". The patches are the same kind they always were, the last few
> entries in my changelog are now the x86-64 merge (which was half a meg,
> and yes it wasn't posted on linux-kernel, but no, it never was before BK
> either), and before that the extensively discussed SSE register content
> leak patch.
I didn't post the huge patch on l-k because the last time I sent large
patches to l-k I got flamed badly by people who still seem to use 9600
baud modems[1] to read mail.
One thing I am a bit concerned about though is that there seem to be
less pre patches since bitkeeper was introduced and in parallel lots of
patches from people working at the bk HEAD, making syncing more difficult.
I don't want to use BitKeeper because I don't like open logging. I hope
I can continue to maintain the x86-64 port even without being part
of the inner bitkeeper circle. It would be good if you did e.g.
a pre patch for every change that could require action from architecture
or other maintainers as sync point (i guess that could be made easy with
the appropiate script)
Back to the x86-64 merge:
If someone wants it it is at
ftp.x86-64.org:/pub/linux/v2.5/2.5.8/*
(split in a big patch for arch/asm and separate bug fixes for other parts)
Comment:
Changes:
- Sync with 2.5.8
- SMP/APIC supported now.
- Module loading works now.
- Time keeping bugs fixed.
- entry.S streamlined and some bugs fixed.
- modify_ldt works now
- mostly rewritten FPU support (including FXRSTOR for initial FPU
initialization based on the initial state)
- 32bit emulation enhanced and bugs fixed.
- rewrote mm initialization and lots of cleanups in the page table handling
__PAGE_OFFSET is now moved to 0x10000000000 and some vmalloc/ioremap
problems have been fixed. They have an own PML4 slot now.
- WCHAN reporting support for RIP (but not RSP)
- Lots of various other bug fixes and cleanups.
-Andi
[1] yes, I'm exaggerating, but it was nearly like that.
From: Linus Torvalds
Subject: Re: [PATCH] Remove BK docs ... + x86-64 2.5.8 sync
Date: Sat, 20 Apr 2002 12:33:26 -0700 (PDT)
On 20 Apr 2002, Andi Kleen wrote:
> I didn't post the huge patch on l-k because the last time I sent large
> patches to l-k I got flamed badly by people who still seem to use 9600
> baud modems[1] to read mail.
Note: I did in no way try to blame Andi on this: quite the reverse. I'm
saying that this was how it worked back before BK too - the bulk of the
patches literally come to me as "private" patches, and they aren't cc'd to
linux-kernel.
(Side note: that doesn't mean that they haven't had comments on the
mailing lists, or that earlier versions or at least parts of them haven't
been sent on the kernel list).
> I don't want to use BitKeeper because I don't like open logging. I hope
> I can continue to maintain the x86-64 port even without being part
> of the inner bitkeeper circle.
Absolutely - as you noticed I accepted the patch, even though there was a
clash (with a released kernel) in there.
> It would be good if you did e.g.
> a pre patch for every change that could require action from architecture
> or other maintainers as sync point (i guess that could be made easy with
> the appropiate script)
This is why I think it might be a good reason to just have a daily script:
not just to create the patches, but also to kind of keep a running
commentary on the kernel list on what I've merged..
Linus
From: Andi Kleen
Subject: Re: [PATCH] Remove BK docs ... + x86-64 2.5.8 sync
Date: Sat, 20 Apr 2002 21:44:20 +0200
On Sat, Apr 20, 2002 at 12:33:26PM -0700, Linus Torvalds wrote:
> Absolutely - as you noticed I accepted the patch, even though there was a
> clash (with a released kernel) in there.
What clash was there? (just curious) I just checked and at least the
kernel.org finger still shows 2.5.8 as the latest released kernel.
> This is why I think it might be a good reason to just have a daily script:
> not just to create the patches, but also to kind of keep a running
> commentary on the kernel list on what I've merged..
Would be fine for me.
-Andi
From: Linus Torvalds
Subject: Re: [PATCH] Remove BK docs ... + x86-64 2.5.8 sync
Date: Sat, 20 Apr 2002 16:14:43 -0700 (PDT)
On Sat, 20 Apr 2002, Andi Kleen wrote:
>
> What clash was there? (just curious) I just checked and at least the
> kernel.org finger still shows 2.5.8 as the latest released kernel.
The x86-64 vmlinux.lds thing got a reject. And yes, I tested against clean
2.5.8..
Linus
On Saturday 20 April 2002 19:51, Linus Torvalds wrote:
> Any suggestions on how to make the process _appear_ less intimidating?
I'm thinking about it. It's still the best project on the planet, but even
so, could it be better?
> Note that one thing that I had hoped BK would do for me, but that hasn't
> happened because I'm a lazy bastard and I'm bad at doing automated scripts
> is to do dialy snapshots as patches (getting rid of the "-pre" kernels,
> since they don't actually add any information except act as update
> points), and also send out a changelog daily to the kernel mailing list.
Eeek. That sounds like a lot of work. Oh I see, this is 100% automated.
> That would actually make the development process MORE open than it was
> before BK, and might make even non-BK people appreciate BK more simply
> because there is a real point to it.
Well, it would be more like working in a fishbowl anyway. The part that's
missing is the discussion. Just looking at the recent traffic... there's
Martin Dalecki's IDE patch, gosh, look at all the fun. It's a non-BK
patch, let's see if there's a pattern. Hmm, the next bushy one is "[PATCH]
zerocopy NFS updated", descending from a traditional patch set. The next
one, "[PATCH] IDE TCQ #4" is also a traditional patch. Hmm, no bitkeeper
patches showing up yet, I don't think I need to go on.
There is a clear inverse relationship between the bk-ness of a patch and
the extent to which it's discussed on lkml. I don't know what to read into
that, but it does seem to lend credence to the idea that the bitkeeper
style of working is not compatible with the idea of community discussion.
Perhaps there are really two kinds of patches, those that are mainly
functional and don't need to be discussed, for which Bitkeeper is an
entirely appropriate medium, and patches-needing-discussion, for which
the Bitkeeper channel is entirely inappropriate. Most of the volume is in
the former, and hence, that is where most of the time savings are. The
corollary of that is, we will not lose a lot of productivity by *not*
using Bitkeeper for the kind of patch that could or should be discussed.
> Comments? Anybody want to hack up a script to do this?
Well, that's a nice thought, but it's not the crux of the problem.
--
Daniel
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 17:07:47 -0400
Concrete examples, please?
Which patches are the stealth patches?
Jeff
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 00:01:35 +0200
On Saturday 20 April 2002 23:07, Jeff Garzik wrote:
> Concrete examples, please?
>
> Which patches are the stealth patches?
Let me turn that around. Which bitkeeper patches have been posted to lkml and
generated significant amounts of discussion on lkml in the last week? Versus
how many lines of bitkeeper patches applied to Linus's tree?
I went through the 1,000 or so most recent postings on lkml, looking for patches
that generated discussion. Here's what I found:
BK patches generating discussion:
[PATCH] for_each_zone / for_each_pgdat
[BK PATCH] USB device support for 2.5.8
[BKPATCH 2.4] meye driver: fix request_irq bug
Non BK patches generating discussion:
[CFT][PATCH] (1/5) sane procfs/dcache interaction
[PATCH] Documenation/vm/numa
[PATCH] fix ips driver compile problems
[PATCH] IDE TCQ #4
[PATCH] migration thread fix
[PATCH] Wrong IRQ for USB on Sony Vaio (dmi_scan.c, pci-irq.c)
[PATCH] x86 boot enhancements, boot bean counting 8/11
[PATCH][2.5-dj] P4 thermal LVT (damage control)
[PATCHSET] Linux 2.4.19-pre7-jam1
[RFC] 2.5.8 sort kernel tables
page_alloc.c comments patch
[PATCH] Re: SSE related security hole
Both BK and non-BK:
[PATCH] i386 arch subdivision into machine types for 2.5.8
The next question you might ask is: are there more BK patches or
more Non-BK, in total, on and off lkml? I don't have statistics at
hand but I'm willing to bet that there are more BK patches, because
that is how the bulk of the grunt tree maintainance is getting
done these days.
My conclusion: though there are more BK patches being applied to Linus's
tree than non-BK, they are generating less discussion on lkml than non-BK
patches do. Or to put it bluntly: BK patches are not being discussed.
--
Daniel
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 18:20:03 -0400
On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> Let me turn that around. Which bitkeeper patches have been posted to lkml and
> generated significant amounts of discussion on lkml in the last week? Versus
> how many lines of bitkeeper patches applied to Linus's tree?
Prior to BK, many people still emailed patches privately to Linus:
me, DaveM, Alan, Al, GregKH, ... You might consider private email
stealth, but usually the changes are either (a) obvious or (b)
previously discussed. With BK, the situation is the same.
So your argument is red herring -- which changes are _newly stealthed_
under BK? Do you have even ONE objectionable example?
BK only changes the medium of transmission of patches to Linus,
and gives us _more_ information about submittors than pre-BK.
> The next question you might ask is: are there more BK patches or
> more Non-BK, in total, on and off lkml? I don't have statistics at
> hand but I'm willing to bet that there are more BK patches, because
> that is how the bulk of the grunt tree maintainance is getting
> done these days.
> My conclusion: though there are more BK patches being applied to Linus's
> tree than non-BK,
So... your conclusion is based on a guess which is based on a guess.
Even if your conclusion is correct (it might be), how do you use
that to support the argument that, less discussion occurs due to BK?
As I mentioned, most merging with Linus occured in private anyway.
If you want to argue against that, go ahead. But don't try to blame
BitKeeper for it.
If there are _specific solutions_ that can be implemented to equalize
things with BK versus non-BK developers, please, chime in. I think the
daily snapshot idea is a good one. Deleting a document, and nothing
else, accomplishes no forward progress (except maybe spawning this
discussion on the evils of BK).
Jeff
From: Daniel Phillips
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 00:34:19 +0200
On Sunday 21 April 2002 00:20, Jeff Garzik wrote:
> So your argument is red herring -- which changes are _newly stealthed_
> under BK? Do you have even ONE objectionable example?
Of course I do: the patch to add the Bk files to Documentation. I will not
call that objectionable - I object to it, but that is not the same thing. I
will call it 'not discussed' when it should have been.
> BK only changes the medium of transmission of patches to Linus,
> and gives us _more_ information about submittors than pre-BK.
I'm not arguing that BK is not a good way to do the grunt maintainance work.
I think it is, and that's great. Heck, I'm not arguing against Bitkeeper *at
all*. I'm arguing against building the bitkeeper documentation into the
kernel tree, giving the impression that Bitkeeper is *required* for
submitting patches.
> So... your conclusion is based on a guess which is based on a guess.
Check it if you think I'm wrong.
> Even if your conclusion is correct (it might be), how do you use
> that to support the argument that, less discussion occurs due to BK?
We haven't established that, we do see a strong correlation. But think.
It's obvious anyway, why discuss anything in public when you don't have
to? Just push it straight to Linus's tree, why bother with formalities?
It's so easy.
> As I mentioned, most merging with Linus occured in private anyway.
> If you want to argue against that, go ahead. But don't try to blame
> BitKeeper for it.
I sense that the discussion of patches on lkml is in decline and I do
blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
> If there are _specific solutions_ that can be implemented to equalize
> things with BK versus non-BK developers, please, chime in. I think the
> daily snapshot idea is a good one.
I think so too, having heard more about the idea.
> Deleting a document, and nothing
> else, accomplishes no forward progress (except maybe spawning this
> discussion on the evils of BK).
Larry already agreed to it, and to provide a new home for it. Linus
said 'don't be silly', but that was a long way back. So that's where
it stands.
--
Daniel
From: Jeff Garzik
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
Date: Sat, 20 Apr 2002 18:54:28 -0400
On Sat, Apr 20, 2002 at 12:34:19AM +0200, Daniel Phillips wrote:
> Of course I do: the patch to add the Bk files to Documentation. I will not
> call that objectionable - I object to it, but that is not the same thing. I
> will call it 'not discussed' when it should have been.
It was requested by Linus to be in the tree as a convenience, because he
and I and others were constantly bouncing it to new people.
I don't see the point of discussing such an obvious patch, outside of
ideological grounds. And when we start making decisions based on
ideology and politics rather than technical merit, we can all go home.
> I'm not arguing that BK is not a good way to do the grunt maintainance work.
> I think it is, and that's great. Heck, I'm not arguing against Bitkeeper *at
> all*. I'm arguing against building the bitkeeper documentation into the
> kernel tree, giving the impression that Bitkeeper is *required* for
> submitting patches.
I think the conclusion that BitKeeper is required, because of the
presence of this documentation, is ludicrous. And I have already stated
many times that I think objecting to the presence of the doc solely on
ideological grounds is also ludicrous.
Linus repeatedly says GNU patches are still acceptable, did you miss that?
> We haven't established that, we do see a strong correlation. But think.
> It's obvious anyway, why discuss anything in public when you don't have
> to? Just push it straight to Linus's tree, why bother with formalities?
> It's so easy.
This "it's easy" argument can easily be applied to the pre-BK days.
Straight-to-Linus-without-discussion is obviously faster, regardless of
whether BK is used or not.
> I sense that the discussion of patches on lkml is in decline and I do
> blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
huh?? "I . Am I wrong? Prove it."
Typically, one is expected to prove their arguments :)
Can you offer any evidence of patches that would have been discussed, in
the pre-BK days, that are no longer discussed? Support your argument,
please.
> Larry already agreed to it, and to provide a new home for it. Linus
> said 'don't be silly', but that was a long way back. So that's where
> it stands.
IOW, it stands at 'don't be silly'.
IMO the acceptance of your patch would indicate that Linus has started
accepting patches based on something other than technical merit.
_There_ is your slippery slope we should avoid at all costs.
Jeff
On Friday 19 April 2002 06:34 pm, Daniel Phillips wrote:
> I'm not arguing that BK is not a good way to do the grunt maintainance
> work. I think it is, and that's great. Heck, I'm not arguing against
> Bitkeeper *at all*. I'm arguing against building the bitkeeper
> documentation into the kernel tree, giving the impression that Bitkeeper is
> *required* for submitting patches.
I'm under the impression that Linus specifically asked for that
documentation, because BK is a tool he used that he was getting flooded with
questions about.
The question isn't really whether BitKeeper is required for kernel
development, it's a question of whether submitting patches to LINUS is
required for kernel development.
It seems like the BitKeeper documentation belongs together with the other
submitting patches documentation, and should be moved to the directory
"Documentation/Linus".
I.E. explicitly, the Kernel is only interested in documenting bitkeeper to
the extent we're documenting how Linus works. (And it IS how Linus works.)
If you're going to argue about Linus being a single point of failure (and
quite possibly a closed and irreproducible system for which we have not seen
source code), that's a can of worms I'm staying well away from this time
'round, thanks. :)
It might be a good idea if there was a Documentation/SubmittingPatches
directory that mentioned where the various active high visibility trees are
and what they're for (Linus's 2.5 tree, Dave Jones's tree, Marcelo's 2.4
tree, and Alan Cox's come to mind.) But that sort of wanders off into
Maintainers land (to get USB patches in, send them to Greg KH, who has this
email address and whose bitkeeper tree can be pulled from...) With all the
maintenance issues that implies...
> > > The next question you might ask is: are there more BK patches or
> > > more Non-BK, in total, on and off lkml? I don't have statistics at
> > > hand but I'm willing to bet that there are more BK patches, because
> > > that is how the bulk of the grunt tree maintainance is getting
> > > done these days.
> > >
> > > My conclusion: though there are more BK patches being applied to
> > > Linus's tree than non-BK,
> >
> > So... your conclusion is based on a guess which is based on a guess.
>
> Check it if you think I'm wrong.
I think he's saying that the burden of proof about there BEING a problem
rests on the one who is complaining about the problem. Complaining and then
expecting other people to prove there ISN'T a problem is kind of impolite...
> > Even if your conclusion is correct (it might be), how do you use
> > that to support the argument that, less discussion occurs due to BK?
>
> We haven't established that, we do see a strong correlation. But think.
> It's obvious anyway, why discuss anything in public when you don't have
> to? Just push it straight to Linus's tree, why bother with formalities?
> It's so easy.
And this differs from emailing him a patch without cc'ing linux-kernel in
what way?
Either you trust Linus's judgement about what patches to accept, or you use
somebody else's tree. Did I miss where voting on linux-kernel ever got a
patch in that Linus didn't want to merge, or kept one out that he did?
And AFTER the merge, you still get to flame all you want. And produce a
better patch to "clean up" the old one the way Martin "cleaned" Andre's name
right out of the maintainers file...
I seem to remember Al Viro taking a clue-by-four to Richard Gooch's head over
devfs on a fairly regular basis, and it was generally about the stuff that
had already made it into the tree, not about pending unmerged stuff.
The ONLY reduction in access I can see to Linus's pending unmerged patch
queue is due to the fact that completed patches don't hang around unmerged
for months at a time anymore. And since Bitkeeper seems to have
significantly contributed to lubricating Linus's in-box, I consider it a net
benefit.
Yes, it's a proprietary tool with "source under glass" licensing, but it's
basically a groupware application. Linus might as well be using proprietary
email software: as long as the email he sends and receives is still ascii
text, I can't say it makes a difference to me.
Think data, not applications. The kernel tarballs produced are completely
independent of bitkeeper. Patches contributed to the kernel tarballs have
been made without bitkeeper for a decade, and can still be made and
contributed without use of bitkeeper. The data being transmitted starts and
ends in the same open format as always (C source code in a filesystem->C
source code in a tarball), and the process in between is well understood and
could be done by hand (even with paper and pencil) if necessary. Bitkeeper
just helps Linus to scale.
Proprietary software sucks when you derive work from it in an exclusive and
dependent way. Then they own your derived work. (Like a microsoft word file
you wrote, which microsoft can charge you to access because they own word and
your file is useless without it.) When it's something you can use but don't
have to, it's basically a service. Not owning a service is unsuprising.
In this case, none of the Linux kernel's end product is derived from
bitkeeper. It's just using bitkeeper as an optional tool in the process of
producing that work. It's analogous to using a proprietary bios to boot your
Linux kernel: if it causes a problem, it can be replaced without changing the
kernel being booted in any way.
> > As I mentioned, most merging with Linus occured in private anyway.
> > If you want to argue against that, go ahead. But don't try to blame
> > BitKeeper for it.
>
> I sense that the discussion of patches on lkml is in decline and I do
> blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
I sense that the chronic memory management problems of early 2.4 have finally
calmed down a bit, that 2.5 has opened so people have an outlet for CODE
rather than just plans for code, and that rather a lot of the intellectual
bandwidth of the list is currently devoted to keeping up with all the changes
in 2.5 that have already been made or are immediately pending, rather than
speculating about a future that hasn't been coded yet. And that the best
flamewar we've managed to come up with recently (before this one) has been
about the IDE subsystem (far too technical for most people to get really
upset about) rather than something juicy like CML2's use of a version of
Python that Red Hat doesn't ship yet. :)
I also sense that it's spring, the weather's nice and the flowers are
blooming, and certain people might be spending some of their time away from a
computer in a way that isn't as much of an option in the winter...
Rob
On Fri, Apr 19, 2002 at 07:05:52PM +0200, Daniel Phillips wrote:
> > The fact that some developers use bitkeeper has no effect on other
> > developers.
> On the contrary, I think it has divided the kernel developers firmly into
> two classes: the "ins" and the "outs".
Care to back that up with numbers ? Take another look at the statistics
Larry posted after the 2.5.8 merge. ISTR pretty much a 50/50 split of
bk merges and regular GNU patches. Whilst a large proportion of the gnu
patches were from the largish sync I did, this ratio seems to be holding
up over every release.
> Oh I don't disagree at all. Bitkeeper is a big improvement over what
> existed before. But it is proprietary. Which other tool in the tool chain
> is proprietary?
Film at 11: proprietory tool used in Linux.
Maybe we should back out all those fixes the Stanford people found with
their checker ? Maybe we should back out the x86-64 port seeing as it
was (partly) done with a commercial simulator?
> > I don't see why there should be any kind of split or anything like that.
> > Everything continues as before. It's just that some developers now have a
> > much easier life...
> And some have a more difficult one. So it goes.
You've not pointed out where this difficulty is yet. Apart from
developers having to wade through this same discussion ev
| Why Windows is better than Linux | 9 minutes ago | Linux general |
| magical mounts | 56 minutes ago | Linux kernel |
| Problem in scim in Fedora 9 | 1 hour ago | Linux general |
| The new Western Digital power saving drives | 1 hour ago | Hardware |
| Battery Maximizer Software | 22 hours ago | Linux kernel |
| windows folder creation surprise | 23 hours ago | Windows |
| Firewall | 1 day ago | OpenBSD |
| IP layer send packet | 2 days ago | Linux kernel |
| dtrace for linux available | 2 days ago | Linux kernel |
| Unable to mount ramdisk image using UBoot while upgrading to 2.6.15 kernel for a MPC8540 based target | 2 days ago | Linux kernel |
Well
This is a really good, high quality, old-fashioned flamewar. It's quite entertaining really :)
But where is the coding...
All this discussion must be taking up energy. If only we could magicially transform flame energy into coding energy :-)
Alex
... flaming energy
I just created the entirely absurd theory that flaming energy is actually coding energy without the necessary genius/creativity/coffein as a catalyst that usually transforms it into code.
bleeding edge
Heh... "Bleeding edge of the stable tree" Ironic, but true.
Gag_Halfront
Ideology
That should be ideology.
re: Ideology
Thanks. Quite a glaring spelling mistake, eh? Thanks for pointing it out. Fixed.