Remove Bitkeeper documentation from Linux tree

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

diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/bk-kernel-howto.txt linux-2.5.8/Documentation/BK-usage/bk-kernel-howto.txt
@@ -1,275 +0,0 @@
-
-		   Doing the BK Thing, Penguin-Style
-
-
-
-
-This set of notes is intended mainly for kernel developers, occasional
-or full-time, but sysadmins and power users may find parts of it useful
-as well.  It assumes at least a basic familiarity with CVS, both at a
-user level (use on the cmd line) and at a higher level (client-server model).
-Due to the author's background, an operation may be described in terms
-of CVS, or in terms of how that operation differs from CVS.
-
-This is -not- intended to be BitKeeper documentation.  Always run
-"bk help <command>" or in X "bk helptool <command>" for reference
-documentation.
-
-
-BitKeeper Concepts
-------------------
-
-In the true nature of the Internet itself, BitKeeper is a distributed
-system.  When applied to revision control, this means doing away with
-client-server, and changing to a parent-child model... essentially
-peer-to-peer.  On the developer's end, this also represents a
-fundamental disruption in the standard workflow of changes, commits,
-and merges.  You will need to take a few minutes to think about
-how to best work under BitKeeper, and re-optimize things a bit.
-In some sense it is a bit radical, because it might described as
-tossing changes out into a maelstrom and having them them magically
-land at the right destination... but I'm getting ahead of myself.
-
-Let's start with this progression:
-Each BitKeeper source tree on disk is a repository unto itself.
-Each repository has a parent.
-Each repository contains a set of a changsets ("csets").
-Each cset is one or more changed files, bundled together.
-
-Each tree is a repository, so all changes are checked into the local
-tree.  When a change is checked in, all modified files are grouped
-into a logical unit, the changeset.  Internally, BK links these
-changesets in a tree, representing various converging and diverging
-lines of development.  These changesets are the bread and butter of
-the BK system.
-
-After the concept of changesets, the next thing you need to get used
-to having multiple copies of source trees lying around.  This -really-
-takes some getting used to, for some people.  Separate source trees
-are the means in BitKeeper by which you delineate parallel lines
-of development, both minor and major.  What would be branches in
-CVS become separate source trees, or "clones" in BitKeeper [heh,
-or Star Wars] terminology.
-
-Clones and changesets are the tools from which most of the power of
-BitKeeper is derived.  As mentioned earlier, each clone has a parent,
-the tree used as the source when the new clone was created.  In a
-CVS-like setup, the parent would be a remote server on the Internet,
-and the child is your local clone of that tree.
-
-Once you have established a common baseline between two source trees --
-a common parent -- then you can merge changesets between those two
-trees with ease.  Merging changes into a tree is called a "pull", and
-is analagous to 'cvs update'.  A pull downloads all the changesets in
-the remote tree you do not have, and merges them.  Sending changes in
-one tree to another tree is called a "push".  Push sends all changes
-in the local tree the remote does not yet have, and merges them.
-
-From these concepts come some initial command examples:
-
-1) bk clone -q http://linux.bkbits.net/linux-2.5 linus-2.5
-Download a 2.5 stock kernel tree, naming it "linus-2.5" in the local dir.
-The "-q" disables listing every single file as it is downloaded.
-
-2) bk clone -ql linus-2.5 alpha-2.5
-Create a separate source tree for the Alpha AXP architecture.
-The "-l" uses hard links instead of copying data, since both trees are
-on the local disk.  You can also replace the above with "bk lclone -q ..."
-
-You only clone a tree -once-.  After cloning the tree lives a long time
-on disk, being updating by pushes and pulls.
-
-3) cd alpha-2.5 ; bk pull http://gkernel.bkbits.net/alpha-2.5
-Download changes in "alpha-2.5" repository which are not present
-in the local repository, and merge them into the source tree.
-
-4) bk -r co -q
-Because every tree is a repository, files must be checked out before
-they will be in their standard places in the source tree.
-
-5)	bk vi fs/inode.c				# example change...
-	bk citool					# checkin, using X tool
-	bk push bk://[email protected]/alpha-2.5	# upload change
-Typical example of a BK sequence that would replace the analagous CVS
-situation,
-	vi fs/inode.c
-	cvs commit
-
-As this is just supposed to be a quick BK intro, for more in-depth
-tutorials, live working demos, and docs, see http://www.bitkeeper.com/
-
-
-
-BK and Kernel Development Workflow
-----------------------------------
-Currently the latest 2.5 tree is available via "bk clone $URL"
-and "bk pull $URL" at http://linux.bkbits.net/linux-2.5
-This should change in a few weeks to a kernel.org URL.
-
-
-A big part of using BitKeeper is organizing the various trees you have
-on your local disk, and organizing the flow of changes among those
-trees, and remote trees.  If one were to graph the relationships between
-a desired BK setup, you are likely to see a few-many-few graph, like
-this:
-
-		    linux-2.5
-		        |
-	       merge-to-linus-2.5
-		 /    |      |
-	        /     |      |
-	vm-hacks  bugfixes  filesys   personal-hacks
-	      \	      |	     |		/
-	       \      |      |         /
-		\     |      |        /
-	         testing-and-validation
-
-Since a "bk push" sends all changes not in the target tree, and
-since a "bk pull" receives all changes not in the source tree, you want
-to make sure you are only pushing specific changes to the desired tree,
-not all changes from "peer parent" trees.  For example, pushing a change
-from the testing-and-validation tree would probably be a bad idea,
-because it will push all changes from vm-hacks, bugfixes, filesys, and
-personal-hacks trees into the target tree.
-
-One would typically work on only one "theme" at a time, either
-vm-hacks or bugfixes or filesys, keeping those changes isolated in
-their own tree during development, and only merge the isolated with
-other changes when going upstream (to Linus or other maintainers) or
-downstream (to your "union" trees, like testing-and-validation above).
-
-It should be noted that some of this separation is not just recommended
-practice, it's actually [for now] -enforced- by BitKeeper.  BitKeeper
-requires that changesets maintain a certain order, which is the reason
-that "bk push" sends all local changesets the remote doesn't have.  This
-separation may look like a lot of wasted disk space at first, but it
-helps when two unrelated changes may "pollute" the same area of code, or
-don't follow the same pace of development, or any other of the standard
-reasons why one creates a development branch.
-
-Small development branches (clones) will appear and disappear:
-
-	-------- A --------- B --------- C --------- D -------
-	          \                                 /
-		   -----short-term devel branch-----
-
-While long-term branches will parallel a tree (or trees), with period
-merge points.  In this first example, we pull from a tree (pulls,
-"\") periodically, such a what occurs when tracking changes in a
-vendor tree, never pushing changes back up the line:
-
-	-------- A --------- B --------- C --------- D -------
-	          \                       \           \
-	           ----long-term devel branch-----------------
-
-And then a more common case in Linux kernel development, a long term
-branch with periodic merges back into the tree (pushes, "/"):
-
-	-------- A --------- B --------- C --------- D -------
-	          \                       \         / \
-	           ----long-term devel branch-----------------
-
-
-
-
-
-Submitting Changes to Linus
----------------------------
-There's a bit of an art, or style, of submitting changes to Linus.
-Since Linus's tree is now (you might say) fully integrated into the
-distributed BitKeeper system, there are several prerequisites to
-properly submitting a BitKeeper change.  All these prereq's are just
-general cleanliness of BK usage, so as people become experts at BK, feel
-free to optimize this process further (assuming Linus agrees, of
-course).
-
-
-
-0) Make sure your tree was originally cloned from the linux-2.5 tree
-created by Linus.  If your tree does not have this as its ancestor, it
-is impossible to reliably exchanges changesets.
-
-
-
-1) Pay attention to your commit text.  The commit message that
-accompanies each changeset you submit will live on forever in history,
-and is used by Linus to accurately summarize the changes in each
-pre-patch.  Remember that there is no context, so
-	"fix for new scheduler changes"
-would be too vague, but
-	"fix mips64 arch for new scheduler switch_to(), TIF_xxx semantics"
-would be much better.
-
-You can and should use the command "bk comment -C<rev>" to update the
-commit text, and improve it after the fact.  This is very useful for
-development: poor, quick descriptions during development, which get
-cleaned up using "bk comment" before issuing the "bk push" to submit the
-changes.
-
-
-
-2) Include an Internet-available URL for Linus to pull from, such as
-
-	Pull from:  http://gkernel.bkbits.net/net-drivers-2.5
-
-
-
-3) Include a summary and "diffstat -p1" of each changeset that will be
-downloaded, when Linus issues a "bk pull".  The author auto-generates
-these summaries using "bk push -nl <parent> 2>&1", to obtain a listing
-of all the pending-to-send changesets, and their commit messages.
-
-It is important to show Linus what he will be downloading when he issues
-a "bk pull", to reduce the time required to sift the changes once they
-are downloaded to Linus's local machine.
-
-IMPORTANT NOTE:  One of the features of BK is that your repository does
-not have to be up to date, in order for Linus to receive your changes.
-It is considered a courtesy to keep your repository fairly recent, to
-lessen any potential merge work Linus may need to do.
-
-
-4) Split up your changes.  Each maintainer<->Linus situation is likely
-to be slightly different here, so take this just as general advice.  The
-author splits up changes according to "themes" when merging with Linus.
-Simultaneous pushes from local development to goes special trees which
-exist solely to house changes "queued" for Linus.  Example of the trees:
-
-	net-drivers-2.5 -- on-going net driver maintenance
-	vm-2.5 -- VM-related changes
-	fs-2.5 -- filesystem-related changes
-
-Linus then has much more freedom for pulling changes.  He could (for
-example) issue a "bk pull" on vm-2.5 and fs-2.5 trees, to merge their
-changes, but hold off net-drivers-2.5 because of a change that needs
-more discussion.
-
-Other maintainers may find that a single linus-pull-from tree is
-adequate for passing BK changesets to him.
-
-
-
-Frequently Answered Questions
------------------------------
-1) How do I change the e-mail address shown in the changelog?
-A. When you run "bk citool" or "bk commit", set environment
-   variables BK_USER and BK_HOST to the desired username
-   and host/domain name.
-
-
-2) How do I use tags / get a diff between two kernel versions?
-A. Pass the tags Linus uses to 'bk export'.
-
-ChangeSets are in a forward-progressing order, so it's pretty easy
-to get a snapshot starting and ending at any two points in time.
-Linus puts tags on each release and pre-release, so you could use
-these two examples:
-
-    bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less
-        # creates patch-2.5.5 essentially
-    bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less
-        # changes from pre1 to final
-
-A tag is just an alias for a specific changeset... and since changesets
-are ordered, a tag is thus a marker for a specific point in time (or
-specific state of the tree).

diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/bk-make-sum linux-2.5.8/Documentation/BK-usage/bk-make-sum
@@ -1,37 +0,0 @@
-#!/bin/sh -e
-# DIR=$HOME/BK/axp-2.5
-# cd $DIR
-
-LINUS_REPO=$1
-DIRBASE=`basename $PWD`
-
-{
-cat <<EOT
-Linus, please do a
-
-	bk pull http://gkernel.bkbits.net/$DIRBASE
-
-This will update the following files:
-
-EOT
-
-bk changes -L -d'$unless(:MERGE:){:CSETREV:\n}' $LINUS_REPO |
-while read rev; do
-  bk export -tpatch -r$rev
-done | diffstat -p1 2>/dev/null
-
-cat <<EOT
-
-through these ChangeSets:
-
-EOT
-
-bk changes -L -d'$unless(:MERGE:){ChangeSet|:CSETREV:\n}' $LINUS_REPO |
-bk -R prs -h -d'$unless(:MERGE:){<:P:@:HOST:> (:D: :I:)\n$each(:C:){   (:C:)\n}\n}' -
-
-} > /tmp/linus.txt
-
-cat <<EOT
-Mail text in /tmp/linus.txt; please check and send using your favourite
-mailer.
-EOT

diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/bksend linux-2.5.8/Documentation/BK-usage/bksend
@@ -1,36 +0,0 @@
-#!/bin/sh
-# A script to format BK changeset output in a manner that is easy to read.
-# Andreas Dilger <[email protected]>  13/02/2002
-#
-# Add diffstat output after Changelog <[email protected]>   21/02/2002
-
-PROG=bksend
-
-usage() {
-	echo "usage: $PROG -r<rev>"
-	echo -e "\twhere <rev> is of the form '1.23', '1.23..', '1.23..1.27',"
-	echo -e "\tor '+' to indicate the most recent revision"
-
-	exit 1
-}
-
-case $1 in
--r) REV=$2; shift ;;
--r*) REV=`echo $1 | sed 's/^-r//'` ;;
-*) echo "$PROG: no revision given, you probably don't want that";;
-esac
-
-[ -z "$REV" ] && usage
-
-echo "You can import this changeset into BK by piping this whole message to:"
-echo "'| bk receive [path to repository]' or apply the patch as usual."
-
-SEP="\n===================================================================\n\n"
-echo -e $SEP
-bk changes -r$REV
-echo
-bk export -tpatch -du -h -r$REV | diffstat
-echo; echo
-bk export -tpatch -du -h -r$REV
-echo -e $SEP
-bk send -wgzip_uu -r$REV -

diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/unbz64wrap linux-2.5.8/Documentation/BK-usage/unbz64wrap
@@ -1,25 +0,0 @@
-#!/bin/sh
-
-# unbz64wrap - the receiving side of a bzip2 | base64 stream
-# Andreas Dilger <[email protected]>   Jan 2002
-
-# Sadly, mimencode does not appear to have good "begin" and "end" markers
-# like uuencode does, and it is picky about getting the right start/end of
-# the base64 stream, so we handle this explicitly here.
-
-PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin
-
-if mimencode -u < /dev/null > /dev/null 2>&1 ; then
-	SHOW=
-	while read LINE; do
-		case $LINE in
-		begin-base64*) SHOW=YES ;;
-		====) SHOW= ;;
-		*) [ "$SHOW" ] && echo $LINE ;;
-		esac
-	done | mimencode -u | bunzip2
-	exit $?
-else
-	cat - | uudecode -o /dev/stdout | bunzip2
-	exit $?
-fi

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

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

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

In that case you are a wanker with religious agenda. Tomahto, tomato...

Daniel Phillips Awoke this dragon, who will now respond:

Whilst Im not sure I agree that bitkeeper is going to push things 'behind the scenes' (its a source management tool, not the source itself), I do think the basic point being made here has some merit. Think about it...

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

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
[email protected] / [email protected] /
[email protected]
        Ever noticed that common sense isn't really all that common?

Jeff Garzik Awoke this dragon, who will now respond:

You know, I blasted Andre H for using words that were nicer than that. And to think you are working where he left off. worrying.

And its /well known/ that you read here. I think not CCing is not a heinous offense in this case.

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

  "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/

By that logic, we should also include the lkml FAQ in the kernel tree. Should we?

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

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...

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

  "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/

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/

If I objected to the inclusion of a piece of code licensed under Microsoft's 'shared source' license, whould you also say I was denying your freedom?

Daniel

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 Awoke this dragon, who will now respond:

Well, what else can he do? he can hardly go back in time and start the discussion that really should have happened...

I'd say that in that case you'd have a legal basis for objecting: a license conflict with a tarball full of GPL code.

is there a license on the distribution of the documentation in question that presents a legal problem for it to be distributed together with GPL kernel code?

Rob

No. The docs in question are covered by the GPL.

This is part of where I get the censorship jag. The doc _license_ is GPL, so they are clearly complaining about my GPL'd speech describing proprietary software. Fsck them, I will talk about proprietary software as much as I like. And GPL that speech, as much as I like.

Implying (or flat out saying) that _talking_ about something proprietary makes that speech proprietary is silly.

Daniel was trying to dictate what we can and cannot talk about, in the kernel sources. That's offensive.

Jeff

Sorry, I resisted for two days but can't anymore...
Should I start by saying "You are all wrong" to match the style of your signature? Just kidding, no offence, please.

The reason of my email is completely different. It's just after you said the word "offensive" I remembered some tale whereby a sheep was trying to argue with the wolves and the wolves were trying to pretend the sheep has the same rights but after a while they got so annoyed that they told the sheep "you are really rude and offensive" and ate it justifying it as a "self-defence".

How can a sheep argue with the wolves (even if they themselves used to be sheep not so long ago but now having become wolves are quite happy with their position). There are two solutions: 1. for a sheep to be promoted into the status of a wolf or 2. for a sheep to be eaten. Daniel, which one seems more desirable?

Regards,
Tigran

Heh. Neither alternative is 'appetizing' ;-)

Following my personal dictates, I'll try not to become part of the problem. I think I prefer to be a vegetarian wolf.

Daniel

No. A pointer to the lkml FAQ is sufficient.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

On the contrary, I think it has divided the kernel developers firmly into two classes: the "ins" and the "outs".

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.

And some have a more difficult one. So it goes.

Daniel

How?

Linus

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

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

I'm thinking about it. It's still the best project on the planet, but even so, could it be better?

Eeek. That sounds like a lot of work. Oh I see, this is 100% automated.

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.

Well, that's a nice thought, but it's not the crux of the problem.

Daniel

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?

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.*

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

  "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/

Anton Altaparmakov Awoke this dragon, who will now respond:

Out of interest, since when?

Concrete examples, please?

Which patches are the stealth patches?

Jeff

The ones that say 'pull from here' are pretty opaque and seem to go past without much discussion. Off the top of my head, I'd say about I've seen about as many bk pushes as pulls but that could be perceptual bias.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

The point has been made that those patches were sent to Linus without CC'ing lkml, in the past. Do you see any newly stealthed patches, which were not opaque pre-BK?

Jeff

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

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.

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

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 <[email protected]>
Alcove - http://www.alcove.com

Stelian Pop Awoke this dragon, who will now respond:

I dont buy that. Its well known that teams of programmers tend to write WORSE code when they dont talk to each other.

(IMO my answer fits for both these examples)

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

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.

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.

Check it if you think I'm wrong.

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.

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 think so too, having heard more about the idea.

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

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 ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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 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?

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.

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.

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

I think your conclusion is wrong and there has always gone patches directly to Linus even before BK. With BK we can actually see who did what and often why so if something gets in that should not we know who to blame. If anything this should make people think one extra time before hitting the send button.

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...

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...

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.

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

Here's my wrapup...

Yes, it came out in the course of the thread - Linus and Jeff had a private email exchange in which Linus add Jeff to push his Bitkeeper documentation files into the tree. Linus's tree, which is of course, 'our' tree as well, in the sense that everybody here has code in it.

So... there are some who perceive the advent of Bitkeeper as a kind of creeping takeover of the Linux development toolchain, and for these people, seeing the documentation files appear in the Documentation directory as if Bitkeeper were not only *a* sourcecode management tool, but *the* Linux sourcecode management tool, is an irritant. Any argument that these people exist, or that they are irritated?

By the way, I'm not one of them, and I'm not going to do any further speaking for them. Just don't get the impression I'm kidding about this.

I have my own agenda: I'd like to see the development process carried out more in the open and to that extent, increasing reliance on Bitkeeper, with its convenient point-to-point push/pull paths is worrisome.

Interesting, Al Viro, the classic owner of a direct patch hotline to Linus, continues to feed that pipeline with standard patches, which just goes to show that Bitkeeper itself is not the problem. And in fact it's not even right to accuse Al of developing in secret, because if you go trolling through his patch directory on kernel.org you'll get a good snapshot of what he's working on, and of course, if you've got thick skin you can always ask him.

Al's kind of a special case though. What we have now is, *everybody* with a piece of kernel to maintain is in on the private, point-to-point thing now. It's efficient, no doubt, but I fear we're also weakening one of one the basic driving forces of Linux development, that is, the public debate part. If you go take a survey of current lkml postings you won't find a lot of design discussion there, even though a huge amount of design work is taking place at the moment, and many changes are taking place that will affect kernel development for years to come.

It used to be that every major change would start with an [RFC]. Now the typical way is to build private concensus between a few well-placed individuals and go straight from there to feeding patches. At least, that's my impression of the trend.

This may in fact be nothing more than a fear. However if there is any chance I'm talking about a real phenomenon then I would indeed be remiss in failing to draw attention to it.

If it's a real phenomenon then the question is, what if anything needs to be done about it? Well, I'm not going to suggest anything at the moment because, in truth, I don't have concrete suggestions to make, I just have a nagging feeling that now is the time to apply a bit of the old eternal vigilance.

Besides, OLS is coming up fast, and there the price of a plane ticket buys you the chance to be part of the cabal (oops, the cabal that doesn't exist) for a week. Erm, and if there are real issues, they are certain to be raised.

All that said, I have to observe that the current process is *not broken* in the sense that development is now proceeding at a truly impressive rate, perhaps because of the success of kernel 2.4 in delivering true enterprise- class functionality, thus removing the immediate pressure to perform. And so, a lot of work is being done on longstanding deficiencies that were never stoppers, but more in the class of 'wouldn't it be nice if this didn't suck as much as it does'.

Well you know, that would be nice. At least it would show a little sensitivity to the issue. Though arguably the prospect of Linus acting sensitive could be more worrisome than anything ;-)

Depending on the nature of the patch, both are wrong. It's just getting very easy to mix fundamental changes in with the 'boring' patch stream. IMHO, the temptation to do this needs to be resisted.

Not voting, discussion. Without the discussion we miss the chance to get thousands of eyeballs on the issue, some of which may be more experienced in certain aspects of the work than the designer/submitted.

No no no. Think about what you just said. Barn. Door. Horse. Gone.

Yes, I haven't tried that yet myself but we shall see. True, I haven't noticed a lot of grumbling about dropped patches lately. Replaced by other grumbling I suppose.

Huh. I think the advertising material that Bitkeeper has now got in the Linux tree is excessive, given its license, and I don't have more to say about that.

Daniel

I disagree with you here. A short 2.5 list:

BIO - Jens posted patches for MONTHS to lkml (or changelogs with the patch
on kernel.org); plenty of room for discussion
O(1) scheduler - discussed quite a bit on lkml before Linus merged it Preempt - discussed to the extreme before being merged
Ratcache - posted for months and discussed a lot on lkml
Andrew Morten's death-to-buffer - posted to lkml quite a bit, but of course
it needs to work before it can be judged
VFS - you already said that you can see what's going on here

Now that leaves drivers and stuff. Well, for drivers, the maintainer submitting updates, especially minor ones, directly to Linus or the subsystem maintainer is fine by me.

What a shame...

I've been trying to get you to quantify this further. So far, all we've seen are half-sides of the story. Please give the full story:

1. Quantify how much discussion about GNU patches there is on LKML in total.
2. Quantify how much discussion about BK merges there is on LKML.

And now this is the important bit that hasn't been done:

Including how many of each class:
a) have been included into Linus' tree.
b) have not been included into Linus' tree.

Then you can come up with sensible figures that actually mean something, rather than some vague fear about a phenomenon that may in fact be a fantasy.

Facts. Facts. Facts.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

I already did both, and posted the results. I put considerable energy into it, and I am not going to put more time into it. If you want to dispute my (unscientific) results then please repeat my survey or carry out one in accordance with your own, presumably higher standards.

True. I suspect somebody can just look at some statistics somewhere to know that. Personally, I don't know how to do that efficiently and I'm not going to do it. I'll speculate though: I guess that BK patches outnumber GNU patches by more than a factor of 3.

Right. I made the conjecture, if you wish to verify/disprove it then feel free. I did my share of the work already.

Daniel

Yes you did. The results were meaningless without reference to which gets into Linus' tree and which don't.

Shrug - I'm not going to waste my time trying to prove _your_ point to myself.

Correct, and it isn't up to me to prove it.

I therefore consider this matter inadequately proven and closed.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

This is too funny.

If you are unwilling to verify your own conjecture, go ahead and admit it was nothing but pointless, un-backed-up wanking. :)

Jeff

Good point. Perhaps we extend this idea to: A patch goes into the tree that really should have been discussed but wasn't, now we know who to beat up. Err, like the BK documentation patch.

Daniel

I of course question that said patch needed to be discussed beyond the discussion that already occurred (admittedly in private)

But yep. You know who to beat up about these things :)

Jeff

Ok. I admit I haven't read through the entire thread. It's a wee bit big and painful so excuse me if this has already been suggested but... If this is the biggest (or one of the biggest) sticking points then why not get BK to email the lk mailing list when there's a patch submitted with a desc of the patch and the patch itself (if the patch is over size x then a link could be emailed out instead of the patch so as not to overly spam ppls mailboxes) and maybe a short email indicating wether or not Linus has accepted the patch and it's going in. If that's a bit too much email then maybe a summary could be compiled every hour or so and emailed out?

To me this looks like it'd allow those who want to use BK to continue using BK and those who don't don't get to miss out on any patches being put in and they'll also have the traditional medium of flamage^wfeedback that everyone knows and loves easily available to them. This would then generate discussion as ppl have the patch shoved under their noses as it appears to have been the case before and generally would not disturb those who want to use BK as they do now (except via the possible consequences that the extra visibility of the patches would provide).

Anyhow, my apologies if I've babbled (it's 3:15am) and if this has been suggested somewhere amongst the 100-150 or so msgs in this thread (I only read the first 20-30 at the beginning and a select few in the middle).

			       DANGEROUS TREND:
	  American Children Are Trying to Masturbate With Electronic
			 Abdominal Exercise Machines!
	     http://www.landoverbaptist.org/news0302/abtoner.html

sounds like an excellent idea and if it is accepted I will even withdraw my comment about wolves and sheep :)

The key thing to observe now is whether in response to your idea there will be the same sort of demagogical nonsense "generated" as an excuse not to do it (i.e. things like "not enough bandwidth" or "why don't you do it" etc...)

Regards,
Tigran

I can certainly do this for the tree on bkbits.net, i.e., it emails the lk list when it gets new work. Linus?

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

I'll look at automating something at this end, because I might as well also automate the push the both master.kernel.org and to bkbits.net:
right now I do that only when I happen to think about it.

Linus

On Sun, Apr 21, 2002 at 10:40:46AM -0700, Larry McVoy wrote:
[...]

That reminds me.

Can you get the bkbits.net interface to spit out text/plain GNU-style patches?

IIRC the web interface currently spits out HTML-ized per-cset patches, so I am hoping it would be trivial to get you guys to change that to text/plain, or offer text/plain in addition to HTML.

That would IMO eliminate an objection or two about the opaqueness of BK, and also eliminate the need for any bkbits.net user to generate per-cset patches. They would need only to give a URL to a CGI which spits out text/plain GNU-style patches.

Jeff

Horse, barn. We need a solution that works before the patch gets applied.

Perhaps that's what you're talking about?

Daniel

Horse, barn... but horse (patch) is under 24/7 surveillance by one or two GPS-locator-equipped robots that the horse can't escape from (e-mail discussion and/or BK changelog entry) so who cares whether it's in the barn or not? We can find the horse and bring it back to the barn either way.

Or, to drop the metaphor: We do not *need* a solution that works before the patch gets applied. It could be desirable, but it's not *necessary*. Once a BK patch is applied, the code itself is not set in stone; the patch can be discussed on the list, modified, or reverted (i.e., rejected after all) just like a patch that was posted to the mailing list and discussed first.

-Barry K. Nathan <[email protected]>

Not on bkbits.net. It eats up too much bandwidth. If someone else wants to host a bkbits.net mirror and they want to allow that, then I'll add the code.

It actually doesn't do you that much good unless we add an interface to get the pre-patch style diffs. Otherwise you are getting a cset at a time and that's a bit too fine grained, at least I think it is.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

That's what I meant. Email gets sent out to LKML when the patch gets sent to BK for approval by Linus. Another email can then be sent out (unless it's felt that it's too verbose to do so) when Linus accepts it into the tree. (unless I'm missing something about BK ;)

			       DANGEROUS TREND:
	  American Children Are Trying to Masturbate With Electronic
			 Abdominal Exercise Machines!
	     http://www.landoverbaptist.org/news0302/abtoner.html

Your bkbits.net web interface _already_ spits out HTML-ized patches. It _reduces_ bandwidth to spit them out as text/plain.

But I think you are misunderstanding a bit, see below.

That's what the web interface does now, and that's what I'm talking about.

I'm talking about making the "all diffs" link in the web interface spit out text/plain.

Jeff

OK, I think you are missing some details of the workflow used to get patches to Linus. As far as I know, he mostly pulls rather than accepts patches, that's one of the reasons there are so many different kernel repositories on bkbits.net. They are mostly queues of stuff waiting for Linus to pull them.

If that is correct, then what we really want is email when something lands on bkbits.net and is not yet included in Linus' tree. We can certainly set up a trigger to send email in that case.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

This doesn't work -- there is no BK _push_ to Linus. There is no "sent to BK for approval."

Traditional RFC822 email is sent to Linus, telling him that there are BK changesets to be picked up. A human-defined length of time ensues, after which Linus either ignores or comments on the email, and either does a 'bk pull' or not.

Very similar to the way GNU patches are handled, strangely enough ;-)

Jeff

I know it does and people use it to casually browse the tree, not as an update mechanism. What you are talking about is something which makes BK a GNU patch server. A useful thing, I can imagine, but it isn't happening on bkbits.net unless someone offers to pick up the cost of another T1 line. $800/month.

As it is we share the T1 line that bkbits.net uses with everything else, including our voice over IP phone system. I can definitely tell when someone does something on bkbits, it tends to garble the phone.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Can you be convinced to post a sample trigger doing this?

Not only will that show people an example of emailing from a trigger, but more importantly it will expose any wonky details of the bkbits.net email system that need to be accounted for... Does standard pipe to /usr/sbin/sendmail -t -i work as expected, for example?

Jeff

At the moment I'm thinking about returning to the patchbot project (by the way, code *is* available now) and reworking it to handle both BK and GNU patches. The advantage of the patchbot is, it can do things like sniff patches for NOTIFYMEONCHANGE directives, auto-CC a linux-patches list, etc. It could act as an accumulator of GNU patches into a BK repository, waiting for Linus to pull, and in the interim, all interested observers could also peek into the repository.

Hmm, I'm sensing a practical project here.

Yes, well that was never completely satisfying to say the least. IMHO, BK is helping improve the situation, but comes with its own issues, not all of them technical.

Daniel

Yes, ping me early this week if I haven't done so, I'm supposedly taking a break and I'm off to play ball with my son.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Go for it. If you build it, they will come...
I'll reserve judgement until it is up and running, not just code available. There has been lots of talk about patchbots, but I haven't seen anyone crowing about their general-use patchbot on lkml.

I seriously doubt your system will work with GNU patches, though, as they still go privately to Linus. A big advantage of this patchbot would be to expose GNU-style patches that would otherwise be "hidden" in various BK repostories until Linus does a pull and a pre-patch.

(encouraging people to CC all patches to the patchbot would be a good step, though, IMO)

Jeff

In fact, the basic premise is that people mail to the patchbot, not the maintainer. The patchbot knows who the maintainer is and forwards the patch to the maintainer, using the maintainer's format of choice, or as now proposed, just drops it into the BK repository and forwards a notification, both to the maintainer and the linux-patches list.

Daniel

You could say the same of Alan Cox's tree, Marcelo's tree, or Dave Jones's tree. They're all public trees acting in some capacity as code integration and exchange points.

Nopt the Linux source code management tool, the *Linus* source code management tool.

Yeah, I typo those two myself all the time. (I wonder if Linus himself does? :)

There are people still mightily upset that devfs is in the tree, and see THAT as a creeping takeover. And ACPI -IS- a creeping takeover, although mostly on the part of hardware manufacturers.

The existence of irritated people is a constant. There are a bunch of very high level people irritated by the binary modules policy (on both ends: that binary-only modules are allowed at all, AND that there's no consistent binary module interface from version to version). And both sides have a point, but reality continues unimpeded regardless.

If Linus is documenting how to work with Linus, it's his right. The process could involve a live chicken and spandex, and if that's what he has found to be the most efficient way to work...

Putting the submitting patches stuff together into a single subdirectory and pointing out that what's being documented is actually Linus, not the tools themselves, would probably help clarify the issue a bit.

Why have you done this much?

So you're worried that the other tool is convenient?

Does this mean you want developers to use something inconvenient? Or make it

If Linus and the top dozen lieutenants all had special scripts and encryption keys set up (all using open source software) so that their code got to each other's systems more easily and was looked at first before shoveling through the signal to noise ratio on lkml, or the random spam linus gets daily porting some subsystem to c++...

Bitkeeper is not open source, but it's by no means exclusive.

The above scenario would be open source, but there -IS- no software more exclusive than GPG. (That's what it's FOR...)

Cut, halt, wait, stop, hold it, whoa, cease, desist...

Bit of momentum built up there.

I should write a "patch penguin aftermath" thing with what we all LEARNED from this. Linus has seperated the maintainers list into two layers because he cream-skimmed out a half dozen lieutenents in charge of major subsystems. Those lieutenants have a direct hotline to Linus, and the maintainers are expected to filter their patches through them. Individual contributers filter their patches through the maintainers, then the lieutenants, then Linus.

This is not a bad thing, it means that by the time Linus sees code it's been code reviewed by two people: one with intimate knowledge of the particular subsystem and the other with broader knowledge of other areas it needs to interoprate with.

And this hierarchy, now that people know about it, is probably equally as responsible for the declogging of the patch queue as Bitkeeper is. Now when a filesystem patch gets ignored by linus, people know they have to get Jens Axboe to sign off on it first.

A list of who the lieutenants are and what maintainers are under them would be a worthy goal. I've tried to assemble such a list a couple times, but it's too much of a judgement call from this end. (And Linus doesn't want to be pinned down.) Off the top of my head, Al Viro, Jens Axboe, Greg KH, Jeff Garzik, and Dave Jones all seem to be people Linus listens directly to on a regular basis. Strangely enough Andrea Arcangeli is NOT: his patches tend to get filtered through somebody like Dave before winding up in Linus's tree, although Linus does irregularly scoop them up directly as well. (Rik van Riel used to be, but then the whole 2.4 memory management thing happened...)

The important thing is that a maintainer know who their lieutenant is, when there's somebody they need to go through to get Linus's attention.

And all this has NOTHING to do with bitkeeper.

O(1) scheduler and numa? Preemptible kernel? Reverse mapping VM? Ratcache page tables? Software suspend? The new build system? Redoing the boot process around ramfs? Are you saying these haven't been discussed?

I seem to remember rather a LOT of discussion of Jens' new block layer (about half of which I could follow), and the need to slash-and-burn the SCSI subsystem. And the big move away from device numbers Linus was on about a while back still doesn't seem to have happened yet, although they've been busy...

When exactly was this mythical golden age, and did it last longer than a month? I don't remember the VM switch in 2.4.10 involving an RFC at any point. And there were about five different proposed scheduler rewrites being argued over for most of a year, which were all obsolted by Ingo's O(1) scheduler which basically came out of the blue one day and was in the kernel a week or two later...

It continues to be Linus's call about what goes into Linus's tree. There have been times when he's disagreed with EVERYBODY else. (Is there somebody OTHER than Linus who thinks having a kernel level debugger would be a bad idea?)

http://lwn.net/2000/0914/a/lt-debugger.php3

Anything else has been, and continues to be, an illusion. We have the choice of using other trees if this is unacceptable, but so far it's been rather nice. Consensus is a convenience, nothing more.

So you aren't proposing a solution, are not even entirely certain of the nature (or existence) of the problem, but you'd like to draw attention to an issue? Just trying to understand here...

Generally, in a situation like that, I try asking questions. Works For Me (tm). (And yes posting errors (or guesses) is often more effective than asking questions, but the goal's the same...)

That sentence belongs in congress, not on a technical list...

What's the status of integrating the ext2 directory index stuff into ext3, by the way? (I realise that's completely off topic, but I'm curious...)

There Is No Cabal (tm).

Use a bigger hammer. :)

Okay, step back and ask the question: What do you WANT? (Do you HAVE a goal in mind in this discussion? I generally fall back on "education" myself. Good, all-purpose goal. But it does tend to involve a different ratio of declarative to interrogative statements. Or at least a lot of weasel words like "tends" and "generally" indicating willingness to be contradicted... :)

Memo to self: emailing a patch to Linus is wrong. Check.

You mean like the out of the blue 2.4.10 VM switch?

What do you mean "needs"? Who needs it? (Is this the same "they" who are not members of the cabal? Everybody's doing it? Nixon's "silent majority".)

Open source is good at debugging. AFTER the fact. People notice WHEN it breaks, not that it's GOING to break.

Linus released a brown paper bag 2.2.0 and 2.4.0 largely because everybody who was going to test it ahead of time already HAD, and the ONLY way to find the remaining bugs was to let people put it into service in the field and see where it broke.

The number of people who seriously thump on stuff ahead of time (run prepatches, or even the whole 2.5 development series) could probably comfortably fit into a single shopping mall, without making it seem particularly crowded...

Huh? You've never seen a changelog entry with the words "back out" in it?

Think about Al Viro ripping somebody a new one because of some stupidity that went into the latest prepatch. Think about what Martin is doing to all the block copied code Andre Hedrick put in the tree...

You mean like this thread?

The documentation wasn't written by bitkeeper, I believe it was written by Jeff Garzik. It wasn't requested or placed in the tree by bitkeeper, it was requested and placed in the tree by Linus.

I'm pretty darn sure this counts as an honest, spontaneous, grassroots endorsement. Yes, such a thing is possible, even in the US...

Rob

Oh, now that _is_ a good idea. So individuals like me can register and say "notify me if anyone posts something for net/packet/* or include/linux/if_packet.h". Whether I'm a maintainer or not?

That would be pretty useful.

An uber-feature would be "notify me if the VFS interface or locking rules change", for version 2 perhaps ;-)

-- Jamie

Yes, see the NOTIFYONCHANGE remark earlier. Some form of metadata in the file could could be used to effect that, or the patchbot's database could record it.

Want to help throw code at this? I see the scope of this expanding.

Challenging, but doable. It's a database + command interface problem, and of course, coding resource problem. Did you have a framework in mind?

Daniel

I see Rasmus is on the job, I'll defer.

Daniel

I took the discussion off-list though, since this thread is bushy enough as is :)

Due to work stuff, I also dont have the time to do the full patchbot show-and-dance right now. But Jamie had some interesting ideas...

Rasmus

Larry> Not on bkbits.net. It eats up too much bandwidth. If someone Larry> else wants to host a bkbits.net mirror and they want to allow Larry> that, then I'll add the code.

One thing that really irritates me about the bkbits.com page (unless I missed figuring out how to so this) is that you can't seem to be able to pull down the plain text version of a source file. The only thing it will give you is a vile HTML'ified version which adds about 15 chars/line with naming and which has all tab's converted into spaces.

Any chance you'd add this?

Jes

Sure, as soon as we find a mirror for bkbits.net, having a plain text interface to the files/patches, is a fine idea. Until then, I need to hoard my bandwidth. I'm working on the mirror problem.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

These are already available on the kernel.org mirrors.

http://ftp.??.kernel.org/pub/linux/kernel/people/dwmw2/bk-2.5/
http://ftp.??.kernel.org/pub/linux/kernel/people/

The individual patches look sane - I'm not entirely sure about the 'Full patch' version, which seems to contain stuff not in the individual patches.

<MODE REPLY-TO=!linux-kernel>

Larry, any idea why? Script below...

</MODE>

#!/bin/sh
#
# $Id: bkexport.sh,v 1.10 2002/04/23 00:13:24 dwmw2 Exp $

BKDIR="$1"
PATCHDIR="$2"
CACHEDIR="$3"

if [ "$BKDIR" = "" -o "$PATCHDIR" = "" -o "$CACHEDIR" = "" ] ; then
echo "Usage: $o <bkdir> <patchdir> <cachedir>"
exit 1
fi

cd $PATCHDIR || exit 1

cd $CACHEDIR || exit 1

cd $BKDIR || exit 1

TAGCSET=bk changes -t -d:I:\\\n | head -1
TAG=bk changes -r$TAGCSET -d:TAG:

CSETS=bk changes -d":I: " -r$TAGCSET,.

NEWESTCSET=echo $CSETS | cut -f1 -d\

if [ -r $PATCHDIR/cset-$TAGCSET-to-$NEWESTCSET.txt ]; then
# We already ran with this set of changesets. Don't bother to rebuild.
exit 0
fi

bk export -tpatch -r$TAGCSET,$NEWESTCSET > $PATCHDIR/cset-$TAGCSET-to-$NEWESTCSET.txt

cat > $CACHEDIR/newindex.$$.html <<EOF
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html>
<head>
<title>BitKeeper patches for hostname:$BKDIR</title>
</head>

<body>
<H1>BitKeeper patches since $TAG</H1>

<H2><A HREF="cset-$TAGCSET-to-$NEWESTCSET.txt">Full patch from $TAG to ChangeSet $NEWESTCSET</A></H2>

EOF

for CSET in $CSETS; do

    if [ ! -r $PATCHDIR/cset-$CSET.txt -o  \
	 ! -r $CACHEDIR/cset-index-$CSET.html -o \
         ! -r $CACHEDIR/cset-key-$CSET -o \
	 "`cat $CACHEDIR/cset-key-$CSET 2>/dev/null`" != "`bk changes -r$CSET -d:KEY:`" ] ; then
	bk export -tpatch -r$CSET > $PATCHDIR/cset-$CSET.txt
        bk changes -r$CSET -d'<H3><A HREF="cset-:I:.txt">:G: :I:, :D: :T::TZ:, :USER: @ :HOST:</A></H3>\n<P>:HTML_C:</P>\n' > $CACHEDIR/cset-index-$CSET.html
	bk changes -r$CSET -d:KEY: > $CACHEDIR/cset-key-$CSET
    fi
    cat $CACHEDIR/cset-index-$CSET.html >> $CACHEDIR/newindex.$$.html

done

if [ "$CSETS" = "" ] ; then
echo "<H3>No changes since last tag</h3>" >> $CACHEDIR/newindex.$$.html
EOF
fi

cat >> $CACHEDIR/newindex.$$.html <<EOF
<hr>
Index generated at date -u
</body>
</HTML>
EOF
mv $CACHEDIR/newindex.$$.html $PATCHDIR/index.html

# Clean up old patches.
cd $PATCHDIR

for FILE in *.txt ; do

    case $FILE in
    cset-$TAGCSET-to-$NEWESTCSET.txt)
	continue
	;;
    cset-*.txt)
	FILECSET=`echo $FILE | sed "s/^cset-\(.*\).txt\$/\\1/"`
	if ! echo $CSETS | grep -q -- $FILECSET ; then
	    rm "$FILE"
	fi
        continue
	;;
    esac

done

cd $CACHEDIR

for FILE in *.html ; do

    case $FILE in
    index.html)
	continue
	;;
    cset-index-*.html)
	FILECSET=`echo $FILE | sed "s/^cset-index-\(.*\).html\$/\\1/"`
	if ! echo $CSETS | grep -q -- $FILECSET ; then
	    rm "$FILE"
	fi
	continue
	;;
    esac

done

--
dwmw2

Just an added vote of confidence,..
They looked sane enough that I used them to sync my tree up to a few csets short of 2.5.9 over the weekend, (after 2.5.9 final I diffed the tree with csets -> 2.5.9 and then merged that).

The only time this method of me keeping up with Linus falls over is when files move or are deleted. No patch seems to be deleted there, so there's nothing for me to apply.. I can live with this though.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Larry> Sure, as soon as we find a mirror for bkbits.net, having a Larry> plain text interface to the files/patches, is a fine idea. Larry> Until then, I need to hoard my bandwidth. I'm working on the Larry> mirror problem.

My suggestion is actually a bandwidth saver, browsing it and searching for the text file made me download a lot of HTML I would never have downloaded.

And just the spaces replaced with the original tabs would be a big save ;-)

Jes

No argument. However, as soon as we do the patch interface and the plain text interface, BK can be treated as a patch server. Then we get automated scripts slurping down the data that way.

If you're willing to use BK just as a transport, it's a far more efficient transport. Ask people who have run rsync/ftp/bk all on the same system, the BK way gets the same information across in less bits.

We're not going to be a patch server or a plain text server on the end of our little T1 line. If you want us to do that, then find someone to pay for another T1 line and I'll happily dedicate it to bkbits.net and apply the changes you want.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

If it gets the information across. So far I haven't found any feature in BK to allow restarting a pull or clone once it is interrupted. For that reason I use rsync to get a large BK repo to my home machines, which often is temporarily disconnected from the ISP.

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 

True, but it also seemed to create a certain energy that now seems to be slipping away. Maybe this is just called 'maturity', I don't know. Now, my original objection was *only* to the inclusion of the Bitkeeper documentation in the kernel tree. A well-known developer who has chosen to stay out of the discussion - perhaps by reason of being asleep - used the term 'bitkeeper mafia'. That's not a good sign. At this juncture, a little moderation, as you've shown, could do a lot to mitigate that perception.

Then it would be back to the usual programming: how to make it all better.

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...

Daniel

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

I have noticed somewhat less of the "I sent this patch to linus nine times now and never heard back" kind of discussion. Can't say I miss it. :)

Patches might be going in with less discussion simply because they're going in more quickly and easily, rather than sitting around for weeks with everybody second-guessing them simply because Linus didn't notice them until the fifth resend. If it no longer takes two months to get an otherwise completed patch into the tree, then yes, there will be less discussion of it on the list.

There's still plenty of discussion AFTER they go in. And they have been known to get reverted (and/or "cleaned up" with a weed-whacker)...

Rob

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

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.

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?

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

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

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...

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,

Anton

  "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/

Was that a hint? Then certainly, a pointer to the BK documentation would be sufficient, and save download bandwidth as well.

Daniel

Not really. I'm just answering your question about whether the lkml FAQ should be distributed with the kernel sources. As far as I know, there is a pointer, but I haven't looked. If there isn't feel free to send Linus and Marcelo a patch.

I wasn't talking about that. And I won't O:-) But I wonder if I added something to the lkml FAQ whether we might avoid some rounds of this repeat flamewar?

Nah.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

Hi,

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

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 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

Hi,

"start"? People used other source management system already before bk.

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

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

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

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

That was not what your patch did.

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

Oh, please show me how and I will do it gladly. I just don't know how to make diff+patch do that.

You got that right.

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.

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.

I use it too. I do not think it belongs in the tree, especially not with its own directory. My point, pure and simple.

But did you think it might be controversial?

Daniel

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,

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.

Linus Torvalds Awoke this dragon, who will now respond:

Dude, I agree, but that is your /IDEOLOGY/, is it not?

Some might call that an ideology itself...

greg

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 :)

Hi,

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

Oh, my. A couple of thoughts:

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 

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

There ya go, now this is reasonable. Personally, I do not want to step on your stones.

Yes, but not *entirely* good, because it is driving some developers into isolation, or at the best, quiet resentment. This does not qualify as 'best for the kernel'. A slight dose of moderation here would strike that happy medium that seems to be slipping away. No, not you, Larry, this is one of your moderate moments, I think I am going to bronze this email.

Um, no Larry, but that is something we can discuss at our leisure. Executive summary: life does not consist of business models alone. Much great art has nothing to do with business models. Oh for sure, some artists are fine businessmen but it's rare. Usually they just get by, enough to satisfy their immediate needs and produce immortal works for your - our - pleasure. Indeed, there is more to life that business models.

You don't *really* want me to do that. I thought you had a business model. Surely it does not consist of 'goad the open source community into replacing my product with a better, free one, so I can retire in poverty'.

It would be most excellent, and you will get a case of good Berlin lager out of it. Err, maybe life is about business after all...

Daniel

All of what you said, 100% agreed, and insightful, in particular:

Do we want it to break down first? I don't want that.

Daniel

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 ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Russell King Awoke this dragon, who will now respond:

I dont think Daniel claimed BK was contributing to linux downfall.

He said that having proprietary stuff in the kernel was a bad idea.

We dont allow proprietary modules in the kernel, why should docs be any different?

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

Use for what? I'm not clear on this concept.

Now you're crying wolf. Since when has developing and trying out tools been bad?

Sorry, the only way I know of debating is in public. Perhaps I can learn another way, but I'm not sure I want to.

Please show me where I said anyone should not use Bitkeeper.

Not at all, you're just the ARM guy. <- funny, laugh

Daniel

Yup.

Daniel

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.

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 Awoke this dragon, who will now respond:

Be realistic - how is he supposed to do that?

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

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/

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.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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,

He made his intention very clear, you are interpreting something in his action, that simply isn't there.

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.

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

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.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Hi Larry,

Wrong. Many corporate firewalls allow email and http (both via proxy) and reject any other traffic. CVS and BK are both unusable in this environment.

--jochen

Hi,

Could you please stop carbon copying to Linux? I'd be very pissed to receive huge amounts of carbon copies about subjects that don't even matter to me!

About the Corporate Firewalls issue, even though Linus didn't like it, Hans Reiser submitted a few patches as Bitkeeper patches. It doesn't exactly seem impossible to me. Also, if you don't have the ability to use Bk for whatever reason, no one will ever forbid you to submit patches.

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.

Hi,

Oops, that's a typo. I meant Linus, of course.

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.

<taken Linus out of cc: list>

Not wrong. BK works fine over http protocol. CVS is another matter which I cannot comment on...

Best regards,

Anton

  "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/

Hi Anton,

Ok, but there are other scenarios where only email is available (often via mail gateways like softswitch on os/390)...

--jochen

Hi,

Then use BK over email then (to submit a patch of your last change set for example you would do "bk export -tpatch -r+", and the receiving end does a simple "cat emailmessagetext | bk receive" and that's it done.

Obviously you haven't looked at bitkeeper... (-;

Anton

ps. You better be prepared to accept very large emails if you want to send a whole linux kernel repository by email though! Never mind if you are using bitkeeper or just a tar ball!

  "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/

BK works with email as its only transport and has for a long time.

bk help send
bk help receive

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Hi Anton,

This is almost right and I can see there is some confusion, so here's son technical info in the midst of this, err, "discussion" :-)

If you want to send a regular style patch

bk export -tpatch -r+ # send most recent changeset
bk import -tpatch # accept regular patch

If you want to send BK style patches

bk send [email protected]
bk receive

NOTE! bk send will send *everything* it has not already sent to that email address, i.e., the whole tree. See the "bk help send" docs for info on how to tell BK that the user already has part of the tree.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

So you're telling me that what I've been doing over the last months really shouldn't have been possible ?

Rik

Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

What he is telling you is that people whose business is hidden behind corporate firewalls so that they can make money with proprietary work, find it morally outrageous that other people don't give away all their work.

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Hi,

The main reason we use firewalls is to protect the privacy of user data. I don't think people would be very amused if they find their bank account numbers posted on the internet ;-)

--jochen

I don't care what information you keep private. I just find the popular the "your work is free, but of course we are in a company" theory of business to be amusing. If you work at a bank, the decision on whether or not to purchase a bitkeeper license is a business decision that has nothing to do with the ideology of free software - unless you are some new type of bank that is in business to do good.

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Wrong -- both BK and CVS can be proxied.

CVS takes a bit more effort. 'bk helptool url' gives you proxy info for BK.

Jeff

Em Sun, Apr 21, 2002 at 03:57:59AM +0100, Ian Molton escreveu:

The documentation being discussed is not proprietary, it only talks about a non essential proprietary tool used now by lots of kernel hackers.

- Arnaldo

Arnaldo Carvalho de Melo Awoke this dragon, who will now respond:

well, this raises an interesting point...

should documentation be regarded as part of the package it documents or not?

is this 'bitkeeper documentation', 'documentation about bitkeeper', or 'linux kernel documentation', or what?

"Linus documentation".

/me carefully stays the hell away from discussing whether it's a part of documented object or not and what would be the license on said object...

As one of the guys who doesn't use BK _and_ had submitted a lot of patches since Linus had started using it, I'm probably qualified to tell whether it hurts or not, right? Well, it doesn't. So far the only difference was in the quality (and latency) of changelogs and that was definitely welcome.

As long as "I've got a bunch of patches affecting <area>. Seeing that you've merged stuff touching <area> since the last -pre, resync point would be a Good Thing(tm)" works I couldn't care less about BK vs. diff+mail. So far it seems to be working fine.

FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD oopses when..." simply because it's easier to match bug reports that way. Having all deltas downloadable as diff+comment is wonderful, but it doesn't replace well-defined (and less frequent) resync points.

Comments?

From: Alexander Viro <[email protected]>
Date: Sun, 21 Apr 2002 00:05:27 -0400 (EDT)

FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD oopses when..." simply because it's easier to match bug reports that way. Having all deltas downloadable as diff+comment is wonderful, but it doesn't replace well-defined (and less frequent) resync points.

Comments?

I agree, make the daily's available but don't kill the -pre.

In fact, we might as well have a whole subdirectory on "Managing Linus", which some people have become very good at.

The BK docs that people are so in a huff over really _are_ less about BK itself, and almost entirely about how to use it to interface with me. Read them - they are just a "SubmittingPatches" for BK, along with scripts to automate it to get the format that I have found to be useful.

Rememebr how many times people have asked for automated tools, and for getting notification about when I've applied a patch? You've got it. It's all there.

Side note: remember the discussion that pushed me to _try_ BK in the first place?

Who was it that said "Be careful what you pray for"? ;)

Linus

Kidding I hope? What would a reasonable name be?

In principle, would you accept a patch that moves the Bitkeeper docs to a web site, with a URL and blurb in SubmittingPatches?

For what it's worth, seeing all the Linus-oriented docs together in one Documentation directory would be helpful in general. On the downside, it might appear to be kind of fence around your personal involvement with the kernel, and it's hard to see why that would be good.

I think you're kidding though, it's hard to tell.

I hope I made it clear that I believe BK is helping Linux. Furthermore, I don't see why Larry should not collect some advertising for his contribution. Within limits. IMHO, we're on the wrong side of the limit at the moment, and moving further with no sign of moderating.

I pray for a truly free Bitkeeper. Shows you what damn good praying does ;-)

Daniel

Yes, because so many purchasing managers spend their time reading the Documentation subdirectory of the Linux kernel in order to decide what SCM system they should use.

The existence (or non-existence) of the docs has absolutely no marketing value to BK.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

So you have no problem with moving them to a website, leaving a url in SubmittingPatches?

Daniel

It's not my call to make. Take it up with the people who own the tree.

Personally, I think a patch like this is more of what you need:

===== bk-kernel-howto.txt 1.2 vs edited =====

@@ -1,5 +1,9 @@
+To placate some pedantic people who feel that this document is an
+advertisement, the name of the source management system has been
+replaced with "groovy SCM".
 
-                  Doing the BK Thing, Penguin-Style
+
+                  Doing the groovy SCM Thing, Penguin-Style
 
 
 

@@ -11,48 +15,48 @@
 Due to the author's background, an operation may be described in terms
 of CVS, or in terms of how that operation differs from CVS.
 
-This is -not- intended to be BitKeeper documentation.  Always run
+This is -not- intended to be groovy SCM documentation.  Always run
 "bk help <command>" or in X "bk helptool <command>" for reference
 documentation.
 
 
-BitKeeper Concepts
-------------------
+groovy SCM Concepts
+-------------------
 

etc.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

I know that. I was wondering if *you personally* would have any objection.

That's all of us, last I heard. Administrating it is, of course, another story.

Daniel

Do you have a problem with moving other docs out to Websites, which are describing closed-spec hardware? Such hardware (and their vendors) are actively anti-open source, yet we have documents describing those, too.

Jeff

But they are instructions for CVS, you're just about to go to some effort to download over the web. Bogus.

Well, maybe it's really the best thing, or perhaps it's the best I can hope for if I want to stop getting beaten up by the BitKeeper mafia.

Please don't assign me membership in any anti-bitkeeper crew. I am not anti-BitKeeper. If you must have an epithet, try "anti-advertising-in-the-tree" crew.

Changing the documents for a url penalizes you exactly how?

Daniel

I was refering to the BK docs, not CVS and yes, BK works disconected. Which was for me one of the important decision points in in switching ntfs driver development to it. Together with easy merging of new kernel releases, etc, etc...

Oh I wasn't refering just to you. I was refering to the "silently seething" kernel hackers you mentioned but refused to name...

You obviously didn't read my mail properly. )-:

It is an inconvenience having to go lookup some website instead of having the doc right there. What part of that do you not understand? Perhaps you have a 24x7 internet connection, many people don't. Perhaps this is a surpise to you? I have the luxury of living in college provided accomodation with local lan connections in place, but this summer I will have to move into my own accomodation and it is very well possible I will not be able to have 24x7 internet... (I will try to find accomodation where I can get a cable modem but it may not be feasible for financial reasons.) For anyone not connected to the net it would be an inconvenience to have to look up the net. I think that this is self-evident but you obvious don't think so...

Best regards,

Anton

  "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/

As Larry has said, if you are anti-advertising-in-the-tree, then start submitting patches regarding reiserfs, because of the large amount of advertising to Namesys and their sponsors.

After reading the thread in its entirety (boy, that was fun), here's a summary of points that you're trying to make, all of which are independent issues:

1. BK is not GPL; it is commercial software

2. Having the BK doc in Documentation/ is advertising in the tree

3. Having the BK doc in Documentation/ is advertising for commercial software

4. Commercial software should be used as little as possible in such a large-scale GPL project like the Linux kernel

5. Existence of BK doc will promote BK-style patches instead of the more traditional diff-style patches

6. BK enables less discussion of patches because Linus can pull them from other BK trees

7. From point 6, BK therefore makes it easier to have less public review (i.e. mails to LKML with "[RFC]") on patches

8. Because of point 7, there is in fact less public review on patches

9. Less public review on patches is bad

10. Non-BK users feel left out because they feel that many patches are getting into the tree without their knowledge and/or less public review

11. Pulling BK doc in the tree would make less users aware of BK and thus solve most of these problems

As Andrew Morton has said, some of these problems are simply unsolvable, like BK being commercial software. Your ideology vs Jeff's is probably not reconcilable.

So, what are the problems that can be solved? Perhaps adding some lines to the BitKeeper doc saying "Unless your patch is trivial, please post it to linux-kernel for peer review, because this is one of the great strengths of open-source software" would be a good idea.

Supply a shell script in the BK docs which generates a diff-style patch and send that off to LKML if you update a BK tree.

Add that patch which was floating around earlier in the thread saying that BK is non-free, and that it is only one alternative for doing things.

Or maybe set up another separate mailing list (e.g. linux-bk-updates), run by a bot which emails that list whenever a patch to a BK tree is submitted. People who don't use BK, such as yourself, can subscribe to the list and initiate discussion on such patches by bringing the mail to linux-kernel.

BK is here to stay; no doubt about that. Doing something completely controversial like removing the docs for it is not the way to go if you want to solve the problems that it has created. I think it's good that you vocalised the problems with using BK, but you're going about fixing the symptoms in the wrong way.

I'm sure people (Jeff and Larry, in particular) would be much more happy if you addressed those issues by adding things to the BK docs highlighting the problems that it causes, and include ways of fixing them. You say that you're not anti-BK, and I believe you're not, but your actions are indicating otherwise.

BK is not the problem: BK is a new way of working with Linus, which is causing problems for people who are used to the non-BK way of working with him. Fix that problem, not BK itself.

#ozone/algorithm <[email protected]>          - trust.in.love.to.save

Oh, come on now... You're being too logical and level headed. If everyone were like you, suddenly the volume of l-k would drop by half, we wouldn't be wasting thousands of Linux developer-hours, and we might actually get some coding done.

Please don't try this again. Go back and read any one of the dozens of lengthy flame wars on l-k for more appropriate methods of not solving an unsolvable problem.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Brilliant summary, up to point 11. A url to the 'Using Bitkeeper with Linux' docs/scripts would stay in the tree, perhaps in the SubmittingPatches file, so there is no attempt to cut down BK usage by hiding documentation. There is an attempt to keep the tree free of commercial advertising, and no I am *not* going to go attack what you or anyone else perceives as a problem with ReiserFS. Anybody who is concerned about that can speak for themselves.

Yes, that would help.

Too much 'automatic' traffic for lkml, however something similar is being worked on by the patchbot group.

Yes.

Right, linux-patches, with a view to providing notification of *proposed* patches before they become formally part of a tree.

Probably. A deeper fix is needed, indeed.

Sorry, I am anti-bitkeeper now; two days ago I was not.

I now believe that the move to BitKeeper constitutes a creeping takeover of the means of developing linux by commercial interests. I did not believe that going in, but went out of his way to convince me of it. I should have realized earlier, during the period in which Larry was putting considerable energy into discrediting and discouraging the Arch project, and Subversion for that matter.

I now firmly believe that we must have our own tools, and that we are in a transitory period where we are using proprietary tools because free ones are not available. So the path forward is to build the tools we need, or join with others to build them. That's the path I'm taking. I will not suggest that anyone stop using BitKeeper, and especially, I will not advocate that Linus stop using BitKeeper. We need the efficiency, and until there is a functional replacement, BitKeeper is the only game in town.

Thanks for your advice.

Hopefully this is the end of the thread.

Daniel

The other example specifically mentioned was the CVS documentation for jfs, and yes, I think that moving those instructions to the web site in question would make a lot of sense, leaving a URL wherever the docs once were. By definition, the CVS instructions will be available on that site as long as they are useful, and not a moment longer.

This is all irrespective of the fact that CVS does not have the problem of having a restrictive license, but since you asked...

Daniel

Personally I find it _extremely_ annoying having to go and lookup web sites which the kernel points me to instead of just having the docs in the kernel in the first place.

For source code to additional utilities, ok, fair enough, we can't have everything in the tree but for documentation, which is a pre-requisite or at least a help to understanding something about the kernel, I don't see why people have to just be referred out of the tree.

Especially because I only need to look up some URL just when I have no internet access for a week or two (and hence have the time to look things up)... Having documentation on some random web site is not going to help there at all. And guess what? I learned how to use bitkeeper when I was on holiday for two weeks. And guess also what? It was Jeff's document which was my main guide on how to do it in combination with the bk kernel tree. I would have been well pissed off if I had found that I needed to get the document off the web after I had gone away...

As a complete different, general point, the probability of documentation being updated when it is outside the tree is _much_ lower than when it is inside the tree. Admittedly the bitkeeper document itself is unlikely to change over time but the scripts helping submissions which are in the same place as the document may very well change over time.

I would much rather see a disclaimer put in Jeff's document stating that "you don't need to use it, gnu patches are just fine with everyone, etc" as others have already suggested.

If such disclaimer doesn't appease the anti-bitkeeper crew then moving the document out won't either, so moving it out would be a waste of time in addition to penalizing people who want to use bitkeeper, which is unfair and incorrect.

Finally, if you object to this _that_ much, why not fork the tree remove the document, and live happy ever after? Perhaps all the anti-bk people will follow you... (-;

Best regards,

Anton

  "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/

Don't refer to me at all in that context, thankyou.

Indeed. Please get a clue a read the thread. Sheesh. No, I'm still not going to name anybody, figure it out yourself.

Good thing you've got a computer to look it up for you then, isn't it. (moral of this, don't say really stupid things if you don't want an even stupider reply).

I don't understand the part where you find clicking a url difficult. Please tell me it ain't so.

OK, let me get this straight. You've got BitKeeper loaded on your system and you've got a kernel tree, and you've made a patch, and you eventually want to push it to Linus, or have him pull it, but you can't get the docs because you're not connected? Yeesh. I can't believe I responded to this.

Daniel

<cc list trimmed because this is getting silly>

Ok, no problem.

Anyone not prepared to say their name obviously doesn't care enough about the issue therefore their needs need not be considered (pun intended). Considering you are speaking for others who as we said before do not care enough you don't speak for any one who cares anough so you should stop now. Sounds harsh? It's the truth. Think about it. At least you claim to not be an anti-bk person but that you speak for the many anti-bk people. I have to still read from a single line from one of those imaginary figures you have in your head...

I didn't say anything stupid. You did. And your reply is out of context because I am talking about disconnectedness.

I click URL and wait and wait and I get "could not contact server". No internet connection damn!

There are people who work without an internet connection and just carry a floppy around to internet cafes / work, etc. On occasion they use a CDR. I know people who do that. I do that when I go on holiday. Last holiday before leaving I burned the bk tree on a CDR and took it with me together with my laptop.

I worked for two weeks completely disconnected. The only means of connection would have been going to an internet cafe and using a floppy. I chose not to go into an internet cafe, I wanted piece and quiet for two weeks. Going to lookup a URL would have wasted time and money. If that isn't an inconvenience I don't know what is...

If you can't see how disconnectedness can be a problem perhaps you don't take enough holidays? (-;

Best reagards,

Anton

  "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/

Daniel, I won't be nagged into supporting your point of view, sorry. I didn't even know that the doc was in the tree until you raised the point. I don't see a problem with it being in the tree and I do *not* support your attempts to remove it.

You seem to think it has some great value to BitMover to have it in the tree. Sorry, that's not true. It's true to some small extent, in that it may reduce the number of support queries that we get related to the kernel. So we'd prefer it stayed in the tree.

Why don't you ask Jeff to stick in the doc saying something like

BitKeeper is not free software. You may use it for free, subject to the licensing rules (bk help bkl will display them), but it is not open source. If you feel strongly about 100% free software tool chain, then don't use BitKeeper. Linus has repeatedly stated that he will continue to accept and produce traditional "diff -Nur" style patches. It is explicitly not a requirement that you use BitKeeper to do kernel development, people may choose whatever tool works best for them.

You are, as has been repeatedly pointed out, able to create your own tree, with your own rules, and see if you develop a following. It's way past time that you do so, it should be crystal clear to anyone with a clue that you are not the administrator of this tree.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

I've added two subsections to the FAQ about this, which I hope will avoid some future flamewars:
http://www.tux.org/lkml/#s1-20
http://www.tux.org/lkml/#s1-21

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

Hi,

You should fix the first paragraph, read
http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what free software is.
"at no charge" is questionable, Larry wants no money in some cases, but he wants log entries, so please just link to the license ("bk help bkl" is useless, if one just to know the licence) and advise the user to carefully read it, before using bk.

bye, Roman

You should learn to not say "you should" but instead "I suggest".

OK, I'll add this link, but I'd feel more comfortable adding this if there was a URL I could quote for the opposing view, and hence be more balanced. But I guess no-one has bothered to write a manifesto. If someone has or does, let me know.

The purpose of the FAQ entry isn't to support a particular view, but to serve as a "State of the Community" notice.

Adding a URL is good. Fortunately, some other people have sent me the URL, so I can include that as well now.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

Please don't.

I don't want a kernel howto quoting the FSF.

Linus

It already has, for years. Like it or not, certain questions/issues *do* get raised. If the FAQ can capture at least some of these, it saves bandwidth on the list.

Anyway, since both you and Daniel are unhappy about the entry, I figure it averages out to be neutral :-)

It's kind of like the Australian Senate, which for the last 15 years or so has managed to piss-off governments of both of the major parties, and has been called "obstructionist" and "unrepresentative swill" at various times, with government calls for "reform" (read:
transformed into a rubber stamp) from both sides. This probably means, on average, they are doing the right thing. Certainly the voting public seems to be happy with the situation.

Not that I should compare myself with the Australian Senate. What I do is far more important.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

I think Linus actually does not want to endorse the FSF stance about how software must be ethically correct.

Thanks God, at least a guy with good sense =]

--
Fast, cheap, good. Pick two.

Right. Besides, as the whole notion of "free software" has very little to do with the kernel, please just link to some open source site. One of the more neutral ones is "http://www.debian.org/social_contract.html", for example.

Remember: we're not the Judean People's Front, we're the People's Front of Judea. Or maybe we're the Popular Front for the Liberation of Judea. I get confused.

Linus

Don't try to understand this whole mess. It's way more complicated than kernel hacking. Trust me, i know a lot about war and freedom fighting since i have a older brother ;)

--
Fast, cheap, good. Pick two.

Just nuke him from orbit. It's the only way to be sure.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

To add more "balance" (and to show that people will never agree:-), I've added links to the above Debian URL as well as one from OSI.

No, we're the Libertarian Front for the People of Judea. Get it right.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

"Listen. If you really wanted to join the People's Front of Judea, you'd have to really hate [BK-Usage/]."

"I do!!"

"Oh yeah? How much?"

"_A_ _LOT_."

"Right. You're in. The only people we hate more than the ones who wrote the files in that damn dir are the f#@$%ing Judean People's Front!"

t.

Hi,

Would you please explain then, what you want?

bye, Roman

I'm not Linus, but i think he does not want nothing of this at all. He cares about the kernel. The kernel does not know about politics, the kernel knows about HARDWARE.

Why people continue bitching about this? It's just a tool. Maybe we should just start flaming Coca-Cola because it does not open source the formula of the soft drink.

--
Fast, cheap, good. Pick two.

[email protected] (Kiss The Blade) wrote on 28.04.02 in <FCYTRNJE041Y54TSRNOMZTEAG1Z3VTR.3ccc5e20@kingston>:

Maybe if they did, someone could design something actually drinkable from that ... then again, the result would be so different, one might as well start from scratch. And nobody seems interested anyway (or else someone *would* have started from scratch and produced something that doesn't try to be a very close clone).

And I'm probably not interested enough to make ot a commercial success anyway, even if everybody were like me.

MfG Kai

[email protected] (Kiss The Blade) wrote on 28.04.02 in <FCYTRNJE041Y54TSRNOMZTEAG1Z3VTR.3ccc5e20@kingston>:

Maybe if they did, someone could design something actually drinkable from that ... then again, the result would be so different, one might as well start from scratch. And nobody seems interested anyway (or else someone *would* have started from scratch and produced something that doesn't try to be a very close clone).

And I'm probably not interested enough to make ot a commercial success anyway, even if everybody were like me.

MfG Kai

Hi,

Then you should remove the "all software wants to be free (and hence all non-free/proprietary software is evil)" part, that was hardly demanded by the "Community". Read the link I gave you, it's about protecting free software, it's not about forcing our views onto others.

bye, Roman

(Linus removed from CC)

Well, in order to prove you're being fair, your patch should have included removal of those CVS instructions, too :) That's the point Linus made in his first message, and one I agree with.

Jeff

[response not answering the question deleted]

Daniel, this is yet another example of you not answering the question asked. Let's try it again. Please answer the following question, since you seem to have elected yourself to position of license policeman:

There are number of different places in the linux kernel source tree where there are docs/code/whatever related to non-open source features included in the tree. Are you advocating a "cleansing" of all of these or are you specifically targetting BitKeeper. If you are only focussed on BitKeeper, why?

That's two questions, just answer those, nothing but those.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

(Linus removed from the CC... nudge nudge, Larry and Daniel)

Roman Zippel suggested something like this, I am perfectly fine with putting a "disclaimer" like this in the doc.

It was _never_ my intention to imply that BK is required for kernel development.

I want to actively dispute that notion... while encouraging its use, since I believe BK is a useful tool for kernel development.

Jeff

I don't want you to, I want you to go on and get rich. However, you might possibly be nagged into remembering you made an offer. Go back and look at the offer, see if there were strings attached at the time.

No, of course not, you're biased. Expected.

How about a URL instead? Any objection?

Why ask Jeff as opposed to submitting such a patch myself? The first thing I'd do is edit out the 'repeatedly', perhaps the whole 'Linus stated' thing, it's mere rhetoric.

I'd rather see the URL happen though, it just makes so much sense.

True, but I'm a contributor and so I have an interest in it. It would be better if you didn't pursue that line of argument.

How about the URL?

Daniel

Would it satisfy you (just talking about *you* now) if I ammended it so it did? This would be purely to satisfy you of course, since the license issue does not exist with CVS, and it would be contingent on negotiating a new home for the jfs CVS instructions.

You want it, you got it. Deal?

Daniel

Yes.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Huh? Are you reading the same mails I am?

As far as I can see: question about moving the jfs CVS docs out of the tree as well, answered fully and, imho, correctly by me.

Focussed on BitKeeper. It's the license. Simple, we can all coexist happily, and profit from each other's endeavors, but our little commons here should not be carrying Bitkeeper ads.

<counts question marks> Oh right, one missing. Well I answered both questionish things anyway. Please let me know when you're done with your cross examination and we can return to my question to you about the URL.

Daniel

You are misunderstanding me and Linus.

The point is that your patch was singling out BK unfairly, and the mention of CVS was an _example_ of that.

I do not support the removal of the BK docs, nor the CVS docs. Linus does not appear to, either.

In fact, if someone wrote a general doc describing productive kernel development under CVS, I would support the addition of that. (though Linus may not, since it's not vaguely equivalent to SubmittingPatches)

Jeff

What part of "describing closed-spec hardware" did you not understand?

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

And that objection is? You mean you'll refuse to agree with changing out the files for a url?

If the latter is your position, then say so and I'm out of here. I won't even respond, not even to flamebait.

Daniel

(Linus CC removed)

Should we remove all mention of .com email addresses too?

On of the very few requirements of my job at mandrakesoft is to use a mandrakesoft.com email address... as advertisement. Many other email addresses are used similarly. reiserfs included _blatant_ advertisements in printk, for the sponsors of the code. A ton of other code has similar advertisements, though not at

Should we remove all advertisements from the kernel? A Big Penguin would probably object to the removal of this printk advertisement for Swansea:

Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039

If the answer is no, then you are targetting BitKeeper specifically...

The Linux kernel is not a commons. Thankfully. Linus prevents that. Otherwise, we _would_ have the infamous Tragedy of the Commons.

Jeff

My objection is that you are singling out one thing that you don't like and attempting to impose your will on a project which is not under your control. In the US, we still have some semblance of free speech rights and you are stomping all over those rights. Your position would be somewhat stronger if you were applying the same metric to all aspects of the kernel, which you are not, but even then I would object based on the fact that it isn't your job to police the kernel for political correctness. If you want that to be your job, go form your own project and impose whatever rules you see fit.

---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

There is no kernel driver for Bitkeeper. What's your point?

Daniel

Excellent point. If the BitKeeper advertising in the kernel source were held to that level, I would be satisfied.

Daniel

<confused>
First I don't control it, then I'm stomping on rights. What the?

If I were able, I'd fix all bugs in the kernel at once too. But I am not able to do that so I do what I can. Anyway, there is only one non-open tool in the toochain, it attracts special attention.

OK, so you are now requiring that I fix everything that is wrong with the kernel before you reinstate your offer?

Daniel

Yes. Why should I have to cut and paste (assuming I'm in X) or write down and transpose some URL from a file that used to contain the exact instructions I need in order to get those instructions now just to satisfy your sensitivity? (And let's not get me started on "sensitivity" and how personally I think that it's nothing more than a politically correct way of saying "I don't want to hear what you have to say so shut up" and is nothing more than another form of censorship that should be beaten out of all children until it is once and for all eliminated from this earth)

So let me tell a little story for a second. I used to maintain the aic7xxx driver. In so doing, I created a web site for disseminating my patches and what not. As people would grab my patches, I would get regular (and annoying to me) questions like "how do I apply your patches", "what patch version should I grab", "how do I compile my kernel after I apply your patch," etc. So, after enough of the same question, the question itself becomes a "frequently asked question". So, I made a few docs that attempted to answer these questions and put them on my web site along side the patches themselves. These docs most generally described how the linux kernel versioning worked, how my patch versioning worked, how to select patches, how to use the patch command, etc. Now, obviously, some of this was very aic7xxx specific, but large parts of it were background knowledge that was required in order to apply that specific aic7xxx information. It made sense therefore to include that information so that the whole picture, from start to finish, was all described in one easy to access place. So, as a result, even though I could have pointed the reader to the patch man page, I didn't bother to make them read a large document full of options and possible means of screwing things up when all I really wanted them to know was "All of my patches are generated so that if you go into the top level of the linux source directory and type 'patch -p1 < patchname' then things will work properly".

So, I haven't read this "BitKeeper advertisement" you have been complaining about. However, I have heard claims that it deals more specifically with how to interface your own personal BK setup with Linus than it does with usage of BK in general. If I were to sit down and read that document now, the questions I would attempt to answer would be things like A) does it describe BK in general and how to set it up for general use, or does it describe how to set BK up for a specific use related to kernel developement, B) does it describe how that setup is then integrated into a kernel patch submission process, C) is the description relevant to all BK setups (not just linux kernel setups) or is it geared specifically towards linux kernel setups, and D) would the description of BK found in the document be of general use to BK deployments in evil proprietary company "X" or would evil company "X" likely need a more general description of BK capabilities not as it is related to linux kernel development. From those questions, and possibly a few more similar ones, a person can determine if the document belongs on the BK web site, or in the linux documentation directory.

Like I said, I haven't read the document. But, if I did and it turned out that it was similar to my description of how to use patch to apply my aic7xxx patches, IOW if it truly was a limited scope "How to use BK to send patches to Linus" and provided just the needed BK information to teach the user the real goal, which is how to integrate their work into Linus' BK patch process, then I would be greatly offended should the document be moved out it's appropriate location in the linux kernel documentation directory to some web site where it doesn't really belong.

  Doug Ledford <[email protected]>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606

<chuckle> -- and if that occurred, _I_ would fight to remove it as a pointless advertisement.

Jeff

What??? What kind of system are you running? Err... redhat supports
cut and paste I thought. <-- funnny.

Bogus. You'd have to do the same to edit/list the file.

                                                                 ^^^^^^^^^^^

^^^^^^^^^^^

Thanks for your story. It's exactly what I've suggested, put the BK docs on a web site.

You haven't read the thread closely, this was described before. There are one documentation file and three scripts. The documentation file is about half general description of Bitkeeper - which is quite unabashedly promotional and the author does describe it as an adverisement - and half how to use for submitting kernel patches. No matter, Bitkeeper is *all* nonfree and the issue is whether documentation for it should live in our kernel tree or on a web site. I.e., should Linux be advertising Bitkeeper through the kernel source.

As has been pointed out, there are other places in the kernel where .com's and the like appear in the form of url's. If that's the noise level the Bitkeeper documentation stayed at, then fine. But that's not what we have.

It's partly generic, partly specific. Read it, please, it's here:

http://lxr.linux.no/source/Documentation/BK-usage/bk-kernel-howto.txt?v=2.5.7

(Oh gosh, a url! Run away!)

E) What is the license?

Because you can't follow a url? Give me a break.

Bogus.

Daniel

You'd want to get rid of the url that points at your docs?

Daniel

I think you misunderstood Jeff. I would also not be happy if I suddenly saw a bitkeeper advertisement during kernel bootup, which is what is quoted above.

It is not a piece of the kernel so it shouldn't be advertised as such. It is a tool that is used in combination with the kernel and the docs for such tool are rightfully in the kernel. docs != advertising. How many people will read the docs? Not many. And certainly not many who would be purchasing bitkeeper. How many people will see the above show copyright messages on boot? A LOT. Anyone booting Linux in fact...

Best regards,

Anton

  "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/

Depends on what you use to read the file containing the URL. Obviously, if I'm Al Viro I'm on a text console and wouldn't use a mouse if you cemented it in my hand, so cut and paste isn't an option.

No, I wouldn't. In one case I would do "less <filename>" and in the other case I would do "less <filename>", ohh damn, it's only a pointer to the real docs, switch to X or install lynx on my system, go to URL. It's a matter of having the appropriate documentation at hand vs. having to retrieve it.

I put my docs on my web site because that's what I owned/controlled and it was relevant to people already coming to my web site. That in no way indicates that your position is correct, especially since you ignored to truly relevant item in my email:

One place for relevant information, from start to finish.

Limited scope "How to use in this specific case" documentation.

Those were the relevant points you blithely skipped because you know they are true and hurt your position. Selective response is something you've been practicing in this entire thread.

Now, now Daniel, let's not put words into people's mouths. Jeff has said he does like BitKeeper, and he said he could *see how you think his description is an advertisement* but that he *didn't write it as an advertisement*.

And I've already given you my answer. If the documentation in question is specific to how to perform my patch work in a BK environment specifically so that I can interface with Linus' BK environment directly, then I don't really care less what the BK license itself is, the document is *still* a HOWTO submit a patch using BK document and belongs with the linux kernel docs, not with BitKeeper's web site.

That's relevant to the decision of whether or not I use BK. It is not relevant to *how* I would use BK, should I choose to do so, in order to submit patches/interface with Linus. Since the document in question is suppossed to be about how to use BK to interface with Linus, and not a general discussion of whether or not any given individual *should* use BK, this point is irrelevant in determining where the document should live.

No, because I detest censorship, and that's all that your spewing has amounted to so far. Because from every description I've heard so far the document is a valid HOWTO about patch submission. Because the various HOWTO documents about the linux kernel *belong* in the kernel documentation tree. Because if we are going to change the proper location of kernel HOWTO documents then we need to do it on a universal basis, not by discriminating against BK because of it's license (which, again, is a "Should I use" not "How do I use" relevant issue only).

  Doug Ledford <[email protected]>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606

[email protected] (Doug Ledford) wrote on 22.04.02 in <[email protected]>:

I have no idea about Al, but while I do spend most of my time on the console, I do use a mouse there for cut and paste. Long live gpm.

You don't have lynx installed on a development machine?! *boggle*

How about links? W3m? Hell, wget?

The debating tactics used in this thread - on more than one side - are nothing to be proud about.

Could we not try to figure out ways to make Linux better, instead of digging for ways to make each other look bad?

MfG Kai

"that level" was assuming you were referring to the URL-free printk advertisement I quoted above.

Jeff

Would everybody with no mouse on their system please stand up, and leave the room.

Seriously, you're trolling.

lynx <url>

What's the difference?

I'm actually trying to do a little work as well as handle all the input from the Bitkeeper moonies, thankyou.

Err, did I say moonies, sorry I meant advocates, err, apologists, umm. Sorry, I just meant I've been getting a lot of email lately, some of it is too long to read every word. Unless you are a spectacularly good writer, expect some of your deathless prose to drop through the cracks.

Right. bitkeeper.com, any argument?

He agreed it was an advertisement.

Daniel

Oh, I was thinking "a few lines", regardless of content.

Daniel

No more so than your bandwidth argument...pot->kettle.

Right, nice personal attack to deflect the arguments I actually wrote. If you aren't going to answer the arguments, then why do you even bother to reply? If you are falling behind due to the load of incoming mail then it seems bass-ackwards to make non-sense replies and arguments that are unnecessary instead of actually responding to the real arguments made.

BTW, I've never used BK. I've never actually even gone to the BK web site. That's probably why I haven't bothered to read the submitting patches using BK *HOWTO* doc in the kernel doc area.

Wow, more personal attack whilst cutting the actual arguments out. That's always a good way to win an argument. <imagine the sarcastic tone of voice> Of course, that's why I repeated the two points, one of which you again cut.

Yeah. I'll go to bitkeeper.com to learn about how to use bitkeeper. I don't expect nor want to go there to learn about how to send a patch to Linus. It's not the appropriate venue for that information.

Hmmm....Daniel stopped his reply before he even got to the really important arguments in my email. Guess that just means I win those points by default which should pretty much settle this entire issue. All BK advocacy docs need to be transferred to bitkeeper.com. All valid HOWTO docs relating to kernel patch submission (whether via diff+email or via BK) should report to the kernel doc directory where they belong.

  Doug Ledford <[email protected]>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606

To clear things up:

* The intent of the doc is to help kernel developers
* The intent was NOT to advertise BK
* An unavoidable side effect of the doc's presence is implicit advertisement
* I certainly promote the use of BitKeeper

Please keep these things separate...

To imply that the BK doc is an intentioned advertisement is silly. It's in the kernel source tree to help people with, like it or not, what is a part of kernel development. An _optional_ part.

Jeff

Which is *exactly* why it belongs with the kernel docs, and not on bitkeeper's web site. It's an optional part of the kernel process, and just because BK has a license some people don't like is no reason to *not* document how that optional process works.

  Doug Ledford <[email protected]>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606

The difference is that currently linux/Documentation/SubmittingPatches currently exists and advocates the usage of diff. Linus no longer prefers diff, he has made it clear he likes BK output.
Would it be acceptable to simply modify said file to include both instructions for using diff, which I believe Linus has said he will continue to accept, as well as to include basic commands for BK to get output such as Linus wants emailed to him. No feature listing, no advertising, no advocacy, just simple usage.