[PATCH] Remove Bitkeeper documentation from Linux tree
Jeff Garzik
> 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.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
> 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.
Anton Altaparmakov
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
At 16:12 19/04/02, Daniel Phillips wrote:
>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
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Roman Zippel
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
Jeff Garzik
> 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?
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
David Lang
then yes they should be included.
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. 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
Nils Philippsen
> 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.
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
--
Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg //
+49.7152.209647
ni...@wombat.dialup.fht-esslingen.de / ni...@redhat.de /
ni...@fht-esslingen.de
Ever noticed that common sense isn't really all that common?
Linus Torvalds
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
Anton Altaparmakov
>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?
>
>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...
> > 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.
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
Alexander Viro
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > 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.
In that case you are a wanker with religious agenda. Tomahto, tomato...
Jeff Garzik
> On Sat, 2002-04-20 at 17:54, Jeff Garzik wrote:
> > 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.
>
> 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 :)
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> 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
Roman Zippel
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.
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
How?
Linus
Jeff Garzik
> On Saturday 20 April 2002 18:51, you wrote:
> > The fact that some developers use bitkeeper has no effect on other
> > developers.
>
> two classes: the "ins" and the "outs".
I disagree -- Andrew Morton and Al Viro don't sent patches to Linus via
BK, AFAIK, and their patches are getting in.
Another example, Jean Tourrhes (sp?), the wireless and IrDA guy. I have
agreed to become his "patch penguin", which IMHO has already translated
into less resends for Jean through my and Linus's use of BK. He sends
GNU patches, so his process is unchanged, he only sees patches _not_
getting dropped[1].
And a further counter-example (to my shame), Anton A. sent me a BK patch
during Linus's vacation, and I have not yet sent it forward, showing
that BK doesn't necessarily imply auto-approval.
Jeff
[1] of course there is often a Garzik-delay :) but I don't drop patches
Linus Torvalds
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
Roman Zippel
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
Dave Jones
> > 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 every third week.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Linus Torvalds
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
Thunder from the hill
> 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
--
Thunder from the hill.
Not a citizen of any town. Not a citizen of any state.
Not a citizen of any country. Not a citizen of any planet.
Citizen of our universe.
Larry McVoy
a) if it would ease the incredible silent (?) seething anguish of Daniel and
others, I'd be happy to post a copy of Jeff's docs on the bitkeeper.com
website someplace and you could replace the patch with a pointer to that.
Seems silly but if it makes the uproar go away...
b) To all of the "silently seething" folks, build a better answer for
free and the kernel team will switch in a heartbeat. How about you
think of BitKeeper as a stepping stone, a temporary thing until a
better answer appears? It doesn't even have to be better, just good
enough.
We built BK to make the key people more efficient. To some extent, it
is doing that. We'll keep trying to make it help make those people more
efficient. That's *good* for the kernel. Which was always the goal.
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.
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.
A thing to keep in mind is that there are a large number of talkers,
people who spend their time flaming but very little of their time writing
useful code. Those people seem to have the most time to argue about
licenses. There are other people who spend their time writing code,
useful code. The goal is to help the second, smaller, group.
BitKeeper seems to make that second group more productive. And it happily
allows for the license haters to keep on working the way they used to,
at the same speed as they used to. Daniel raised the point that BK has
created the "ins" and the "outs". That's not quite right, it's a question
of "efficient" versus "not quite so efficient". Yeah, it has the effect
of creating an "in" group, but that is because it is easier to work that
way, not because of any evil plan to take over the world with BK.
To repeat: if http://www.bitkeeper.com/kernel-howto.html or something
like that makes you happier, I'll do that immediately.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > > And some have a more difficult one. So it goes.
> >
> > 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.
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
Larry McVoy
> On Saturday 20 April 2002 19:09, Linus Torvalds wrote:
> > On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > >
> > > And some have a more difficult one. So it goes.
> >
> > 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.
>
> 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.
You are sort of right and sort of wrong. The changes are mostly ending
up in some BK tree and Linus pulls from that tree. Most of the trees
are on bkbits.net (there are about 130 different ones at last count).
The problem is that there is not an easy way to get a handle on what is
in Linus' tree and what is not, and it's just insane to ask people to
sit around and diff the trees even if BK does make that process somewhat
easier.
An obvious improvement would be to have an "overview" web page which showed
you the list of changes not present in Linus' tree but present in any of
the other trees. Probably sorted by tree so you could see
linuxusb.bkbits.net/linux-2.5
37 changesets (click here for details)
gkernel.bkbits.net/vm
12 changesets (click here for details)
Etc.
If you dump the licensing discussion and think about how BK could help
you, you can see we are half to an improvement over the "mail to the
list" model. The problem I had with the "mail to the list" model was
that it was easy to miss something and then not realized that you
had missed it. Now a lot of that stuff is ending up on bkbits.net
and if there was a way to say "tell me everything that is there but
not here", that would be a distinct improvement, it means that the
"mail" is archived and you can find it when you want it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Eric W. Biederman
> 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.
Daniel I agree that there are some real dangers to using a proprietary
tool, and have seen it severely affect a project.
The primary problem is that some developers are not able to
participate because they do not have the tool.
Given that bitkeeper is currently freely available, and that people
can still send raw patches I do not see that people are currently
being excluded on basis of the tool they use.
I can see the potential for this to break down. However we should
not be crying wolf until this actually does break down.
There is exactly one point where religious attitudes are important.
Because of them some people will not use a non-free tool. So for a
wide spread project there must be some way for them to participate.
diffs are still being accepted, so these people do have a to
participate.
Eric
Eric W. Biederman
> 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...
Faster? BK has no impact on the fundamentals of code development. Only
on the problem of merging code. Only when the bottle neck is merge speed
does it really come into play.
For Linus this is obviously a very important issue. For some of the
rest of us it is less so.
For myself I find great benefit in reviewing my own patches, and in
having other people look at them and review them. I may be wrong
but I do not see bitkeeper helping in that regard (except reduce
the noise of renames).
Eric
Rik van Riel
> As always, what I do is in the interest of Linux and freedom.
Then why do you want to deny us the freedom to have a very
useful piece of documentation in the kernel tree ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Anton Altaparmakov
>Anton Altaparmakov <ai...@cantab.net> writes:
> > 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...
>
>on the problem of merging code. Only when the bottle neck is merge speed
>does it really come into play.
I would disagree personally. The more I play with the GUI tools provided by
bitkeeper the more interesting things i discover. For example actually
SEEING how patches fit together, being able to see what each patch did,
looking at a file and having each line annotated as to who added it and in
which patch makes it easier for me to understand how the code I am trying
to understand has evolved and why certain things are the way they are. But
that is something very personal to me, others may not find it useful...
>For Linus this is obviously a very important issue. For some of the
>rest of us it is less so.
>
>For myself I find great benefit in reviewing my own patches, and in
>having other people look at them and review them. I may be wrong
>but I do not see bitkeeper helping in that regard (except reduce
>the noise of renames).
I really like the way bk citool works because it makes my changelogs a lot
more useful as I actually see what I have changed when writing them. But
again, that is just me...
Best regards,
Jeff Garzik
> The missing part is watching the mail go by. It's the discourse, where
> has it gone? What happened to the times when patches were actually
> discussed before going into the tree? Can we somehow have that and
> bitkeeper too... and a fairy castle...
The level of discussion of my own patches is exactly the same, pre- and
post-BitKeeper.
What patches do you think are being sneaked into the tree?
Jeff
Russell King
> All of what you said, 100% agreed, and insightful, in particular:
>
> On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > I can see the potential for this to break down. However we should
> > not be crying wolf until this actually does break down.
>
Actually, you yourself have probably sewn the first seeds of the community
breaking down. Lets take a moment to put some thought in at this point
and review what's happened today.
1. The Current Situation
- Linus uses BK
- Linus makes his BK tree available.
- Linus makes GNU patches available.
- Linus accepts requests to pull from BK trees.
- Linus accepts GNU patches to apply to his BK tree.
2. The effect of today
- You've highlighted a problem
- David Woodhouse and Rik van Riel have written a tool to grab Linus'
BK tree and turn it into a patch on a per-hourly basis
Now look back at Linus' actions above. There is now redundancy. Linus
doesn't have to put out GNU patches anymore because someone else is
doing that for him... which means Linus works more efficiently.
So it's highly likely that in the future, we'll have:
- Linus uses BK
- Linus makes his BK tree available
- Linus accepts requests to pull from BK trees.
- Linus accepts GNU patches to apply to his BK tree.
- "Select few" pull his BK tree and create GNU patches for others
to use.
Oops. We've just split the community further, which is *completely* the
opposite of what you wanted to achieve. I wonder what the next stage
will be...
Like I said to you on IRC before you posted the message - you want
to fix the problem at the root (ie, Linus) rather than your apparant
problem with the "two communities." And how do you do that? You
discuss it with the person concerned. (And you can see the results
of that discussion earlier in this thread.)
This way, those that want to use "a distributed source control system
of some type" can do so, and those that want to use the GNU patch/diff
method can also continue to, but with The Latest Tree available.
Which has got to be an advantage for *everyone*.
I'm sorry, I have no cares for people who have been constantly whinging
at the users of BK who don't go out of their way to find out where the
real problem is and attempt to fix that, rather than harp on about how
other people shouldn't be using a non-free tool.
Oh, and before anyone says that I'm another one who uses BK, yes I do
use BK, but only as a method of getting ARM specific changes into Linus.
Any generic kernel changes I have still go to linux-kernel, Linus and
any relevant other people as a GNU patch. The first time these patches
see BK is when they hit Linus' BK tree. They don't come from BK either.
I, therefore, can claim to work in both domains in parallel.
But no, in your eyes, I'm just another stupid BK person who's contributing
to the downfall of Linux, and is in the "in" club.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Eric W. Biederman
> All of what you said, 100% agreed, and insightful, in particular:
>
> On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > I can see the potential for this to break down. However we should
> > not be crying wolf until this actually does break down.
>
> Do we want it to break down first? I don't want that.
The price of freedom is continual vigilance.
So when confronted by changes in practice that we aren't sure about
the appropriate procedure is to ask (publicly?). If this is keeping
developers from participating. Or if it is placing a significant
barrier in the way of developers. If we start the conversation
without condemnation of change, we won't be crying wolf. Only asking
is that a wolf?
Addressing the filter is doing X fun. For me working with near-free
tools is not fun, because I must always be aware of the difference. I
am never quite certain where I stand with the tool vendor. The tool
is not free obviously because money making opportunities are more
important than my ability to use and modify the tool.
At the same time constant vigilance even of free software is required.
A non-free tool that does a sufficiently good job that I don't feel
like fixing it, is usable. It simply becomes a minor background
irritant that I can ignore.
Linus working more efficiently so he can accept more patches is
obviously more fun :)
Eric
Jeff Garzik
> On Saturday 20 April 2002 20:13, you wrote:
> > On Fri, 19 Apr 2002, Daniel Phillips wrote:
> >
> > > As always, what I do is in the interest of Linux and freedom.
> >
> > Then why do you want to deny us the freedom to have a very
> > useful piece of documentation in the kernel tree ?
>
> 'shared source' license, whould you also say I was denying your freedom?
You tried to -remove-, not include something. And, what you tried to
remove was under the GPL license, not any other license. So your
analogy doesn't hold.
You attempted to remove a GPL'd work from a GPL'd work, on the basis of
its content conflicting with your ideology.
Jeff
Jeff Garzik
> 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.
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
Jeff Garzik
> 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.
Concrete examples, please?
Which patches are the stealth patches?
Skip Ford
>
> 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
Rik van Riel
> 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".
http://www.surriel.com/ http://distro.conectiva.com/
-
Jeff Garzik
> 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.
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
Stevie O
Daniel is now bothered by the presence of BK documentation in the Linux kernel tree. Therefore, he submitted a patch to remove this documentation.
Just about everybody else involved in this thread accuses him of censorship, for attempting to restrict the dissemination of ideas. I do not know whether all of these people use BK; all I know is the "censorship" claim, on the basis that he is restricting the dissemination of information.
I ask this: What if, instead of Daniel removing this documentation change, Linus himself did the patch?
2600 asserted that source code is speech, with the DeCSS case. I doubt EVERYONE here agrees with that, but I do agree that source code is a very precise form of communcating ideas...
(1) If I were to write a driver, and submit it for inclusion with the mainline kernel, would Linus be "censoring" me if he did not include my patch?
And here is a better reason:
(2) If I had such a driver included in mainline, and that driver broke in the 2.5 series -- due to, say, BIO changes, VFS changes, procfs changes, DMA changes, PCI subsystem changes, you get the idea -- and as a result, Linus chose to remove it from mainline, he's restricting the dissemination of my ideas (driver). Does that mean he is censoring me?
--
Stevie-O
*This sig was deleted for violating the DMCA.*
Anton Altaparmakov
> From what I can see, this is the situation:
>
>Daniel is now bothered by the presence of BK documentation in the Linux
>kernel tree. Therefore, he submitted a patch to remove this documentation.
>
>Just about everybody else involved in this thread accuses him of
>censorship, for attempting to restrict the dissemination of ideas. I do
>not know whether all of these people use BK; all I know is the
>"censorship" claim, on the basis that he is restricting the dissemination
>of information.
>
>I ask this: What if, instead of Daniel removing this documentation change,
>Linus himself did the patch?
That is completely different. Linus owns the Linux kernel. He is the
dictator on what happens with it. As such he can do with it as he pleases.
If anyone doesn't like his actions, they are free to fork the kernel and do
whatever they want. That is what the GPL is all about!
This thread is getting sillier and sillier...
Best regards,
Anton
>2600 asserted that source code is speech, with the DeCSS case. I doubt
>EVERYONE here agrees with that, but I do agree that source code is a very
>precise form of communcating ideas...
>
>
>(1) If I were to write a driver, and submit it for inclusion with the
>mainline kernel, would Linus be "censoring" me if he did not include my patch?
>
>And here is a better reason:
>
>(2) If I had such a driver included in mainline, and that driver broke in
>the 2.5 series -- due to, say, BIO changes, VFS changes, procfs changes,
>DMA changes, PCI subsystem changes, you get the idea -- and as a result,
>Linus chose to remove it from mainline, he's restricting the dissemination
>of my ideas (driver). Does that mean he is censoring me?
>
>--
>
>Stevie-O
>
>*This sig was deleted for violating the DMCA.*
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
Jeff Garzik
> 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
Stelian Pop
> 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.
Or maybe using a SCM puts more pressure on the developper which
writes better code, which will get accepted with less discussion.
In general, when you seek discussion with a quick and dirty piece
of code, you post a patch, not the BK equivalent, since you know
this will not get accepted anyway...
Stelian.
--
Stelian Pop <steli...@fr.alcove.com>
Alcove - http://www.alcove.com
Jeff Garzik
> (1) If I were to write a driver, and submit it for inclusion with
> the mainline kernel, would Linus be "censoring" me if he did not
> include my patch?
(IMO my answer fits for both these examples)
> (2) If I had such a driver included in mainline, and that driver
> broke in the 2.5 series -- due to, say, BIO changes, VFS changes,
> procfs changes, DMA changes, PCI subsystem changes, you get the
> idea -- and as a result, Linus chose to remove it from mainline,
> he's restricting the dissemination of my ideas (driver). Does that
> mean he is censoring me?
In the strictest sense, yes. But the key difference would be his
reasoning in your example would be technical, whereas Daniel's stated
reason was ideology.
One of the reasons why I like the Linux kernel is the freedom to make
the best technical decision, regardless of conflicting ideologies or
politics.
Jeff
Russell King
> patches that generated discussion. Here's what I found:
Nice work. However, you forgot the other half of the job - finding out
how many BK "patches" got merged into Linus' tree, and how many GNU
patches. Only then can we make a real comparison.
And yes, I've done Linus a favour - I've deleted him from the CC: list
because he's said he's not interested in this discussion.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Jeff Garzik
> On Sunday 21 April 2002 00:20, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> > > 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?
>
> 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.
> > 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.
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?
> > 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.
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.
> > 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.
huh?? "I <think this>. 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.
> > 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.
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