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
--- linux-2.5.8.clean/Documentation/BK-usage/bk-kernel-howto.txt Sun Apr 14 15:18:43 2002
+++ linux-2.5.8/Documentation/BK-usage/bk-kernel-howto.txt Wed Dec 31 19:00:00 1969
@@ -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
--- linux-2.5.8.clean/Documentation/BK-usage/bk-make-sum Sun Apr 14 15:18:45 2002
+++ linux-2.5.8/Documentation/BK-usage/bk-make-sum Wed Dec 31 19:00:00 1969
@@ -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
--- linux-2.5.8.clean/Documentation/BK-usage/bksend Sun Apr 14 15:18:48 2002
+++ linux-2.5.8/Documentation/BK-usage/bksend Wed Dec 31 19:00:00 1969
@@ -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/bz64wrap linux-2.5.8/Documentation/BK-usage/bz64wrap
--- linux-2.5.8.clean/Documentation/BK-usage/bz64wrap Sun Apr 14 15:18:55 2002
+++ linux-2.5.8/Documentation/BK-usage/bz64wrap Wed Dec 31 19:00:00 1969
@@ -1,41 +0,0 @@
-#!/bin/sh
-
-# bz64wrap - the sending side of a bzip2 | base64 stream
-# Andreas Dilger <[email protected]> Jan 2002
-
-
-PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin
-
-# A program to generate base64 encoding on stdout
-BASE64_ENCODE="uuencode -m /dev/stdout"
-BASE64_BEGIN=
-BASE64_END=
-
-BZIP=NO
-BASE64=NO
-
-# Test if we have the bzip program installed
-bzip2 -c /dev/null > /dev/null 2>&1 && BZIP=YES
-
-# Test if uuencode can handle the -m (MIME) encoding option
-$BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES
-
-if [ $BASE64 = NO ]; then
- BASE64_ENCODE=mimencode
- BASE64_BEGIN="begin-base64 644 -"
- BASE64_END="===="
-
- $BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES
-fi
-
-if [ $BZIP = NO -o $BASE64 = NO ]; then
- echo "$0: can't use bz64 encoding: bzip2=$BZIP, $BASE64_ENCODE=$BASE64"
- exit 1
-fi
-
-# 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 internally.
-echo "$BASE64_BEGIN"
-bzip2 -9 | $BASE64_ENCODE
-echo "$BASE64_END"
diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/cset-to-linus linux-2.5.8/Documentation/BK-usage/cset-to-linus
--- linux-2.5.8.clean/Documentation/BK-usage/cset-to-linus Sun Apr 14 15:18:45 2002
+++ linux-2.5.8/Documentation/BK-usage/cset-to-linus Wed Dec 31 19:00:00 1969
@@ -1,49 +0,0 @@
-#!/usr/bin/perl -w
-
-use strict;
-
-my ($lhs, $rev, $tmp, $rhs, $s);
-my @cset_text = ();
-my @pipe_text = ();
-my $have_cset = 0;
-
-while (<>) {
- next if /^---/;
-
- if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) {
- &cset_rev if ($have_cset);
-
- $rev = $tmp;
- $have_cset = 1;
-
- push(@cset_text, $_);
- }
-
- elsif ($have_cset) {
- push(@cset_text, $_);
- }
-}
-&cset_rev if ($have_cset);
-exit(0);
-
-
-sub cset_rev {
- my $empty_cset = 0;
-
- open PIPE, "bk export -tpatch -hdu -r $rev | diffstat -p1 2>/dev/null |" or die;
- while ($s = <PIPE>) {
- $empty_cset = 1 if ($s =~ /0 files changed/);
- push(@pipe_text, $s);
- }
- close(PIPE);
-
- if (! $empty_cset) {
- print @cset_text;
- print @pipe_text;
- print "\n\n";
- }
-
- @pipe_text = ();
- @cset_text = ();
-}
-
diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/csets-to-patches linux-2.5.8/Documentation/BK-usage/csets-to-patches
--- linux-2.5.8.clean/Documentation/BK-usage/csets-to-patches Sun Apr 14 15:18:56 2002
+++ linux-2.5.8/Documentation/BK-usage/csets-to-patches Wed Dec 31 19:00:00 1969
@@ -1,44 +0,0 @@
-#!/usr/bin/perl -w
-
-use strict;
-
-my ($lhs, $rev, $tmp, $rhs, $s);
-my @cset_text = ();
-my @pipe_text = ();
-my $have_cset = 0;
-
-while (<>) {
- next if /^---/;
-
- if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) {
- &cset_rev if ($have_cset);
-
- $rev = $tmp;
- $have_cset = 1;
-
- push(@cset_text, $_);
- }
-
- elsif ($have_cset) {
- push(@cset_text, $_);
- }
-}
-&cset_rev if ($have_cset);
-exit(0);
-
-
-sub cset_rev {
- my $empty_cset = 0;
-
- system("bk export -tpatch -du -r $rev > /tmp/rev-$rev.patch");
-
- if (! $empty_cset) {
- print @cset_text;
- print @pipe_text;
- print "\n\n";
- }
-
- @pipe_text = ();
- @cset_text = ();
-}
-
diff -uN --recursive linux-2.5.8.clean/Documentation/BK-usage/unbz64wrap linux-2.5.8/Documentation/BK-usage/unbz64wrap
--- linux-2.5.8.clean/Documentation/BK-usage/unbz64wrap Sun Apr 14 15:18:52 2002
+++ linux-2.5.8/Documentation/BK-usage/unbz64wrap Wed Dec 31 19:00:00 1969
@@ -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
On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> I have up to this point been open to the use of Bitkeeper as a development
> aid for Linux, and, again up to this point, have intended to make use of
> Bitkeeper myself, taking a pragmatic attitude towards the concept of using
> the best tool for the job. However, now I see that Bitkeeper documentation
> has quietly been inserted ino the Linux Documentation directory, and that
> without any apparent discussion on lkml. I fear that this demonstrates that
> those who have called the use of Bitkeeper a slippery slope do have a point
> after all.
Guess what? You have the freedom to ignore these docs.
Guess what else? You are taking away freedoms by restricting speech,
making documents less available than they previously were.
Take your closed mind elsewhere. I'm pretty sure Linus has more sense
than to apply this patch.
Jeff
On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> Please do not misinterpret my position: I count Larry as something more than
> a personal acquaintance. I strongly support his efforts to build a business
> for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> documentation, the subject of this patch. I do not support the infusion of
It's also really, really, low class to not even CC me in your attempt
to remove the documentation I wrote from the kernel tree, and placed
into the kernel tree at Linus's request.
Rot in hell, closed mind.
Jeff
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
At 16:12 19/04/02, Daniel Phillips wrote:
>Hi Linus,
>
>I have up to this point been open to the use of Bitkeeper as a development
>aid for Linux, and, again up to this point, have intended to make use of
>Bitkeeper myself, taking a pragmatic attitude towards the concept of using
>the best tool for the job. However, now I see that Bitkeeper documentation
>has quietly been inserted ino the Linux Documentation directory, and that
>without any apparent discussion on lkml. I fear that this demonstrates that
>those who have called the use of Bitkeeper a slippery slope do have a point
>after all.
>
>I respectfully request that you consider applying the attached patch, which
>reverses these proprietary additions to the Documentation directory. Perhaps
>a better place for this documentation would be on kernel.org if Peter Anvin
>agrees, or the submitter's own site if he does not. Or perhaps bitkeeper.com
>would be willing to host these files.
>
>Please do not misinterpret my position: I count Larry as something more than
>a personal acquaintance. I strongly support his efforts to build a business
>for himself out of his Bitkeeper creation. I even like Jeff Garzik's
>documentation, the subject of this patch. I do not support the infusion of
>documentation for proprietary software products into the Linux tree. The
>message is that we have gone beyond optional usage of Bitkeeper here, and it
>is now an absolute requirement, or it is on the way there.
>
>I hope that this proposed patch will receive more discussion than the
>original additions to Documentation did.
>
>Thankyou,
>
>Daniel
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Hi,
Jeff Garzik wrote:
> Guess what else? You are taking away freedoms by restricting speech,
> making documents less available than they previously were.
So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
information as well?
You certainly don't want to restrict the freedoms of other users?
bye, Roman
On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> Daniel,
>
> This is not documentation for bitkeeper but how to use bitkeeper
> effectively for kernel development. It happens to be DAMN USEFULL
> documentation at that for anyone wanting to use bitkeeper for kernel
> development so IMO it fully belongs in the kernel. Just like the
> SubmittingPatches document does, too. Or are you going to remove that as well?
By that logic, we should also include the lkml FAQ in the kernel tree. Should
we?
> If you don't want to use bitkeeper you don't need to read this
> documentation. Just ignore it and stick with what is SubmittingPatches
> document.
>
> What's your problem?
I am worried that a creeping takeover of the Linux hitherto-successful
development process is in progress, that concensus on this topic has not been
achieved, and that there is a split coming. That would not be good.
As always, what I do is in the interest of Linux and freedom. That interest
is not served by driving a wedge firmly between two groups of Linux developers.
I hope you understand that I am a *moderate* with respect to this issue.
--
Daniel
On Sat, Apr 20, 2002 at 06:16:48PM +0200, Roman Zippel wrote:
> Hi,
>
> Jeff Garzik wrote:
>
> > Guess what else? You are taking away freedoms by restricting speech,
> > making documents less available than they previously were.
>
> So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
> information as well?
> You certainly don't want to restrict the freedoms of other users?
Two issues here:
1) Daniel was attempting a 'remove' operation, you are describing an
'add'. The operations do the exact opposite in terms of information
dissemination.
2) If someone writes a good guide to using Arch with the Linux kernel,
or subversion, I don't have an objection to putting it into
Documentation.
Daniel disagrees with the content of the speech in
Documentation/BK-usage, based on his ideology. And he attempted to
restrict the dissemination of that speech. What is the definition
of censorship again?
People may think I'm just pissed because it's my doc he wanted to
remove, but that's only partially true. I see this as a clear cut
case of Daniel's ideology pushing him to attempt to restrict speech.
That is anti-freedom, no matter how you look at it, regardless of
whether we are talking about BitKeeper or anything else.
Maybe we should have warning labels on software, indicating that
a product does not conform completely to some idealist notion of
free software.
Jeff
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
On Sat, 20 Apr 2002, Roman Zippel wrote:
> Hi,
>
> Jeff Garzik wrote:
>
> > Guess what else? You are taking away freedoms by restricting speech,
> > making documents less available than they previously were.
>
> So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
> information as well?
> You certainly don't want to restrict the freedoms of other users?
>
> bye, Roman
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, 2002-04-20 at 17:54, Jeff Garzik wrote:
> On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> > Please do not misinterpret my position: I count Larry as something more than
> > a personal acquaintance. I strongly support his efforts to build a business
> > for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> > documentation, the subject of this patch. I do not support the infusion of
>
> It's also really, really, low class to not even CC me in your attempt
> to remove the documentation I wrote from the kernel tree, and placed
> into the kernel tree at Linus's request.
>
> Rot in hell, closed mind.
You seriously have to improve your manners. Dubbing someone low class
while using such phrases is pretty double standards. Is it really so
difficult to calm down before replying? But I guess I'm just restricting
your freedom of speech.
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?
On Saturday 20 April 2002 18:25, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 06:16:48PM +0200, Roman Zippel wrote:
> > Hi,
> >
> > Jeff Garzik wrote:
> >
> > > Guess what else? You are taking away freedoms by restricting speech,
> > > making documents less available than they previously were.
> >
> > So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
> > information as well?
> > You certainly don't want to restrict the freedoms of other users?
>
> Two issues here:
> 1) Daniel was attempting a 'remove' operation, you are describing an
> 'add'. The operations do the exact opposite in terms of information
> dissemination.
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
On Sat, 20 Apr 2002, Jeff Garzik wrote:
>
> Take your closed mind elsewhere. I'm pretty sure Linus has more sense
> than to apply this patch.
Absolutely.
Like it or not, I personally use BK. I don't use CVS, and I don't use
subversion.
If anybody wants to maintain his own kernel, feel free to remove the
documentation on how to interact with _me_. In such a kernel, those docs
would obviously be meaningless.
In fact, Daniel, if you had bothered to just even grep for CVS, you would
have noticed that we've had CVS information for some other subprojects
too, because _they_ happen to use CVS. Would you argue for removal of the
CVS information in Documentation/filesystems/jfs.txt file?
And if not, then you're a hypocritical bastard with a religious agenda.
Linus
On Saturday 20 April 2002 18:37, Linus Torvalds wrote:
> On Sat, 20 Apr 2002, Jeff Garzik wrote:
> >
> > Take your closed mind elsewhere. I'm pretty sure Linus has more sense
> > than to apply this patch.
>
> Absolutely.
>
> Like it or not, I personally use BK. I don't use CVS, and I don't use
> subversion.
>
> If anybody wants to maintain his own kernel, feel free to remove the
> documentation on how to interact with _me_. In such a kernel, those docs
> would obviously be meaningless.
>
> In fact, Daniel, if you had bothered to just even grep for CVS, you would
> have noticed that we've had CVS information for some other subprojects
> too, because _they_ happen to use CVS. Would you argue for removal of the
> CVS information in Documentation/filesystems/jfs.txt file?
>
> And if not, then you're a hypocritical bastard with a religious agenda.
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
At 17:21 19/04/02, Daniel Phillips wrote:
>On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > Daniel,
> >
> > This is not documentation for bitkeeper but how to use bitkeeper
> > effectively for kernel development. It happens to be DAMN USEFULL
> > documentation at that for anyone wanting to use bitkeeper for kernel
> > development so IMO it fully belongs in the kernel. Just like the
> > SubmittingPatches document does, too. Or are you going to remove that
> as well?
>
>By that logic, we should also include the lkml FAQ in the kernel tree. Should
>we?
The lkml FAQ is aimed at users, not developers. The bitkeeper and the
SubmittingPatches document are aimed at developers. I see a fundamental
difference here...
> > If you don't want to use bitkeeper you don't need to read this
> > documentation. Just ignore it and stick with what is SubmittingPatches
> > document.
> >
> > What's your problem?
>
>I am worried that a creeping takeover of the Linux hitherto-successful
>development process is in progress, that concensus on this topic has not been
>achieved, and that there is a split coming. That would not be good.
>
>As always, what I do is in the interest of Linux and freedom. That interest
>is not served by driving a wedge firmly between two groups of Linux
>developers.
>I hope you understand that I am a *moderate* with respect to this issue.
The fact that some developers use bitkeeper has no effect on other
developers. Well ok, it means that the bk using developers can work faster
but that is not at issue here...
I don't see why there should be any kind of split or anything like that.
Everything continues as before. It's just that some developers now have a
much easier life...
Anton
--
"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/
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > And if not, then you're a hypocritical bastard with a religious agenda.
>
> Err, and if I to argue for it then I'm not? That's easy I argue for it.
In that case you are a wanker with religious agenda. Tomahto, tomato...
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> No I do not. Read the post. I suggested placing the documentation on
> kernel.org, on your site, or on bitmover.com where it belongs.
That was not what your patch did.
> (And there you may have an argument that would satisfy me. However, it
> is not me I'm worried about. It is the other kernel developers who are
> silently seething at this situation. Yes they are, use your ears.)
I would suggest that if you are silently seething about the fact that a
commercial product can do something better than a free one, how about
_doing_ something about it?
Quite frankly, I don't _want_ people using Linux for ideological reasons.
I think ideology sucks. This world would be a much better place if people
had less ideology, and a whole lot more "I do this because it's FUN and
because others might find it useful, not because I got religion".
Would I prefer to use a tool that didn't have any restrictions on it for
kernel maintenance? Yes. But since no such tool exists, and since I'm
personally not very interested in writing one, _and_ since I don't have
any hangups about using the right tool for the job, I use BitKeeper.
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long
since forgotten the password to my old helsinki.fi account ;), and I have
absolutely no interest in web page design. So when I got tired of
explaining how to use BK, I asked Jeff to just send me a patch so that I
could point people to the only thing I _do_ care about, ie the kernel
sources.
Linus
On Sat, Apr 20, 2002 at 06:29:11PM +0200, Nils Philippsen wrote:
> On Sat, 2002-04-20 at 17:54, Jeff Garzik wrote:
> > On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> > > Please do not misinterpret my position: I count Larry as something more than
> > > a personal acquaintance. I strongly support his efforts to build a business
> > > for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> > > documentation, the subject of this patch. I do not support the infusion of
> >
> > It's also really, really, low class to not even CC me in your attempt
> > to remove the documentation I wrote from the kernel tree, and placed
> > into the kernel tree at Linus's request.
> >
> > Rot in hell, closed mind.
>
> You seriously have to improve your manners. Dubbing someone low class
> while using such phrases is pretty double standards. Is it really so
> difficult to calm down before replying? But I guess I'm just restricting
> your freedom of speech.
I never claimed I was not low class[1] ;-) And no, you're not
restricting free speech at all... Posts like yours are a celebration of
free speech.
Jeff
[1] I often joke with my friends, "I've got plenty of class... all of it
low." Usually after telling a tasteless joke :)
On Saturday 20 April 2002 18:51, you wrote:
> The fact that some developers use bitkeeper has no effect on other
> developers.
On the contrary, I think it has divided the kernel developers firmly into
two classes: the "ins" and the "outs".
> Well ok, it means that the bk using developers can work faster
> but that is not at issue here...
Oh I don't disagree at all. Bitkeeper is a big improvement over what
existed before. But it is proprietary. Which other tool in the tool chain
is proprietary?
Heck, it's not even that proprietary. As far as I know I can still download
the source. But... looking at those files sitting in the Documentation
directory, it looks to me like a big old Marlbourough[TM] ad.
> I don't see why there should be any kind of split or anything like that.
> Everything continues as before. It's just that some developers now have a
> much easier life...
And some have a more difficult one. So it goes.
--
Daniel
Hi,
David Lang wrote:
> If they start to be tools that are used to submit changes to the kernel
> then yes they should be included.
"start"? People used other source management system already before bk.
> remember that the reason for the bitkeeper documentation is to help people
> setup a tree that linux (and others) can pull from, not to help people
> setup their own tree just for them to hack on.
The problem is that this suggest, bk would be the choice for kernel
development or even usage. They are lots of kernel projects, which use
cvs, but noone before considered submitting extensive cvs documentation
into the kernel.
bye, Roman
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> And some have a more difficult one. So it goes.
How?
Linus
On Fri, Apr 19, 2002 at 07:05:52PM +0200, Daniel Phillips wrote:
> On Saturday 20 April 2002 18:51, you wrote:
> > The fact that some developers use bitkeeper has no effect on other
> > developers.
>
> On the contrary, I think it has divided the kernel developers firmly into
> two classes: the "ins" and the "outs".
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
On Saturday 20 April 2002 18:56, Linus Torvalds wrote:
> On Fri, 19 Apr 2002, Daniel Phillips wrote:
> >
> > No I do not. Read the post. I suggested placing the documentation on
> > kernel.org, on your site, or on bitmover.com where it belongs.
>
> That was not what your patch did.
Oh, please show me how and I will do it gladly. I just don't know how to
make diff+patch do that.
> > (And there you may have an argument that would satisfy me. However, it
> > is not me I'm worried about. It is the other kernel developers who are
> > silently seething at this situation. Yes they are, use your ears.)
>
> I would suggest that if you are silently seething about the fact that a
> commercial product can do something better than a free one,
You got that right.
> how about _doing_ something about it?
However, first I personally do not want to start that project. Firstly, I
do personally like Larry and do not want to be part of a horde bent on
tearing down his business. There are after all, plenty of genuinely nasty
things out there to attack, attacking Larry as *way* down my list. More
importantly, my time is better spent improving Linux.
> Quite frankly, I don't _want_ people using Linux for ideological reasons.
> I think ideology sucks. This world would be a much better place if people
> had less ideology, and a whole lot more "I do this because it's FUN and
> because others might find it useful, not because I got religion".
That's the point. It is not fun to see the whole thing start tearing itself
apart. Fun is being on the winning side. Fun is not dealing with a lot of
stressed out people with agendas.
> Would I prefer to use a tool that didn't have any restrictions on it for
> kernel maintenance? Yes. But since no such tool exists, and since I'm
> personally not very interested in writing one, _and_ since I don't have
> any hangups about using the right tool for the job, I use BitKeeper.
I use it too. I do not think it belongs in the tree, especially not with its
own directory. My point, pure and simple.
> As to why the docs are in the kernel sources rather than on any web-sites:
> it's simply because I don't even _have_ a web page of my own (I've long
> since forgotten the password to my old helsinki.fi account ;), and I have
> absolutely no interest in web page design. So when I got tired of
> explaining how to use BK, I asked Jeff to just send me a patch so that I
> could point people to the only thing I _do_ care about, ie the kernel
> sources.
But did you think it might be controversial?
--
Daniel
On Sat, 20 Apr 2002, Roman Zippel wrote:
>
> They are lots of kernel projects, which use cvs, but noone before
> considered submitting extensive cvs documentation into the kernel.
More importantly, there was no way in hell I would synchronize with a CVS
tree, so CVS was a non-entity as far as patch submittal was concerned.
The BK documentation is _nothing_ more than a alternative to
"SubmittingPatches".
Anyway, I'm not going to discuss this any more. If somebody has actual
construcive ideas about trying to improve other tools or putting the BK
docs in some place that is equally obvious and easily available for all
parties but somehow "less disturbing" to people with a weak stomach, go
for it. But I'm not interested in yet another religious whine-war.
Linus
Hi,
Jeff Garzik wrote:
> Daniel disagrees with the content of the speech in
> Documentation/BK-usage, based on his ideology. And he attempted to
> restrict the dissemination of that speech. What is the definition
> of censorship again?
Maybe I was to subtle, but your censorship argument is simply bullshit.
A link to the information is completely sufficient. The only question
is, whether the information is relevant for kernel development and most
of it is only bk documentation.
bye, Roman
On Fri, Apr 19, 2002 at 07:05:52PM +0200, Daniel Phillips wrote:
> > The fact that some developers use bitkeeper has no effect on other
> > developers.
> On the contrary, I think it has divided the kernel developers firmly into
> two classes: the "ins" and the "outs".
Care to back that up with numbers ? Take another look at the statistics
Larry posted after the 2.5.8 merge. ISTR pretty much a 50/50 split of
bk merges and regular GNU patches. Whilst a large proportion of the gnu
patches were from the largish sync I did, this ratio seems to be holding
up over every release.
> Oh I don't disagree at all. Bitkeeper is a big improvement over what
> existed before. But it is proprietary. Which other tool in the tool chain
> is proprietary?
Film at 11: proprietory tool used in Linux.
Maybe we should back out all those fixes the Stanford people found with
their checker ? Maybe we should back out the x86-64 port seeing as it
was (partly) done with a commercial simulator?
> > I don't see why there should be any kind of split or anything like that.
> > Everything continues as before. It's just that some developers now have a
> > much easier life...
> And some have a more difficult one. So it goes.
You've not pointed out where this difficulty is yet. Apart from
developers having to wade through this same discussion every third week.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Saturday 20 April 2002 19:09, Linus Torvalds wrote:
> On Fri, 19 Apr 2002, Daniel Phillips wrote:
> >
> > And some have a more difficult one. So it goes.
>
> How?
Those who now chose to carry out their development using the patch+email
method, and prefer to submit everything for discussion on lkml before it
gets included are now largely out of the loop. Things just seem to *appear*
in the tree now, without much fanfare. That's my impression.
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
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> But did you think it might be controversial?
Ehh, the documentaion? Nope, I didn't really think _that_ part would be
controversial.
The change to BK? I sure as hell knew that was going to be "interesting",
yes absolutely. After all, it had been discussed at places like the kernel
summit etc.
But hey - I've never really cared about what other people think about what
I do. If I had, I'd have given up on Linux when Tanenbaum ridiculed it. Or
I wouldn't have done the big dentry change (which was a total disaster in
some peoples minds) in 2.1.x. Or the VM changeover in the middle of 2.4.x.
Or a million other things.
I do what _I_ think is right for the kernel, and while I tend to poll
people and listen to them, when the sh*t hits the fan it is _my_ decision.
You can't please everybody. And usually if you _try_ to please everybody,
the end result is one big mess.
Linus
Hi,
> Quite frankly, I don't _want_ people using Linux for ideological reasons.
> I think ideology sucks. This world would be a much better place if people
> had less ideology, and a whole lot more "I do this because it's FUN and
> because others might find it useful, not because I got religion".
Several guys (mis-)use Linux as war against Windows, which is really
childish. But it seems they're an important amount, on both sides (There
are even users who use Windows as a protest against Linux). That does,
however, not help you to get an non-propietary tool.
As long as there is nothing I could use instead, it's a good idea to use
BitKeeper instead, and as long as there is a way to use it, users will
actually look it up in the Documentation dir. If users don't find an
answer there, they'll certainly massively bother the LKML.
Documentation also contains information on how to use existing tools
with Linux Kernel. If we exclude BitKeeper just because it's propietary
tool, we'll get into trouble.
BTW, why then do we include processor support into the kernel tree? I
can't find any way to download them from the Internet!
Regards,
Thunder
--
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.
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
On Fri, Apr 19, 2002 at 07:32:36PM +0200, Daniel Phillips wrote:
> On Saturday 20 April 2002 19:09, Linus Torvalds wrote:
> > On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > >
> > > And some have a more difficult one. So it goes.
> >
> > How?
>
> Those who now chose to carry out their development using the patch+email
> method, and prefer to submit everything for discussion on lkml before it
> gets included are now largely out of the loop. Things just seem to *appear*
> in the tree now, without much fanfare. That's my impression.
>
> 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.
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
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > > And some have a more difficult one. So it goes.
> >
> > How?
>
> Those who now chose to carry out their development using the patch+email
> method, and prefer to submit everything for discussion on lkml before it
> gets included are now largely out of the loop. Things just seem to *appear*
> in the tree now, without much fanfare. That's my impression.
I don't buy that - I'm not getting changes from any new magical BK "men in
black". The patches are the same kind they always were, the last few
entries in my changelog are now the x86-64 merge (which was half a meg,
and yes it wasn't posted on linux-kernel, but no, it never was before BK
either), and before that the extensively discussed SSE register content
leak patch.
HOWEVER, the fact that you _feel_ like that is clearly a fact.
Any suggestions on how to make the process _appear_ less intimidating?
Note that one thing that I had hoped BK would do for me, but that hasn't
happened because I'm a lazy bastard and I'm bad at doing automated scripts
is to do dialy snapshots as patches (getting rid of the "-pre" kernels,
since they don't actually add any information except act as update
points), and also send out a changelog daily to the kernel mailing list.
That is something that is one of the big _points_ to using source control,
yet because I don't need it personally I've never gotten around to writing
those scripts.
That would actually make the development process MORE open than it was
before BK, and might make even non-BK people appreciate BK more simply
because there is a real point to it.
Comments? Anybody want to hack up a script to do this?
Linus
Daniel Phillips <[email protected]> writes:
> Hi Linus,
>
> I have up to this point been open to the use of Bitkeeper as a development
> aid for Linux, and, again up to this point, have intended to make use of
> Bitkeeper myself, taking a pragmatic attitude towards the concept of using
> the best tool for the job. However, now I see that Bitkeeper documentation
> has quietly been inserted ino the Linux Documentation directory, and that
> without any apparent discussion on lkml. I fear that this demonstrates that
> those who have called the use of Bitkeeper a slippery slope do have a point
> after all.
Daniel I agree that there are some real dangers to using a proprietary
tool, and have seen it severely affect a project.
The primary problem is that some developers are not able to
participate because they do not have the tool.
Given that bitkeeper is currently freely available, and that people
can still send raw patches I do not see that people are currently
being excluded on basis of the tool they use.
I can see the potential for this to break down. However we should
not be crying wolf until this actually does break down.
There is exactly one point where religious attitudes are important.
Because of them some people will not use a non-free tool. So for a
wide spread project there must be some way for them to participate.
diffs are still being accepted, so these people do have a to
participate.
Eric
On Saturday 20 April 2002 19:41, Larry McVoy wrote:
> 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.
There ya go, now this is reasonable. Personally, I do not want to step on
your stones.
> 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.
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.
> 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.
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.
> 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.
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'.
> 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.
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
Anton Altaparmakov <[email protected]> writes:
> The fact that some developers use bitkeeper has no effect on other
> developers. Well ok, it means that the bk using developers can work faster but
> that is not at issue here...
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
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> As always, what I do is in the interest of Linux and freedom.
Then why do you want to deny us the freedom to have a very
useful piece of documentation in the kernel tree ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
All of what you said, 100% agreed, and insightful, in particular:
On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> I can see the potential for this to break down. However we should
> not be crying wolf until this actually does break down.
Do we want it to break down first? I don't want that.
--
Daniel
On Saturday 20 April 2002 19:51, Larry McVoy wrote:
> 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.
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.
> 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.
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
At 18:58 20/04/02, Eric W. Biederman wrote:
>Anton Altaparmakov <[email protected]> writes:
> > The fact that some developers use bitkeeper has no effect on other
> > developers. Well ok, it means that the bk using developers can work
> faster but
> > that is not at issue here...
>
>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.
I would disagree personally. The more I play with the GUI tools provided by
bitkeeper the more interesting things i discover. For example actually
SEEING how patches fit together, being able to see what each patch did,
looking at a file and having each line annotated as to who added it and in
which patch makes it easier for me to understand how the code I am trying
to understand has evolved and why certain things are the way they are. But
that is something very personal to me, others may not find it useful...
>For Linus this is obviously a very important issue. For some of the
>rest of us it is less so.
>
>For myself I find great benefit in reviewing my own patches, and in
>having other people look at them and review them. I may be wrong
>but I do not see bitkeeper helping in that regard (except reduce
>the noise of renames).
I really like the way bk citool works because it makes my changelogs a lot
more useful as I actually see what I have changed when writing them. But
again, that is just me...
Best regards,
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/
On Fri, Apr 19, 2002 at 08:27:58PM +0200, Daniel Phillips wrote:
> The missing part is watching the mail go by. It's the discourse, where
> has it gone? What happened to the times when patches were actually
> discussed before going into the tree? Can we somehow have that and
> bitkeeper too... and a fairy castle...
The level of discussion of my own patches is exactly the same, pre- and
post-BitKeeper.
What patches do you think are being sneaked into the tree?
Jeff
On Fri, Apr 19, 2002 at 08:15:14PM +0200, Daniel Phillips wrote:
> All of what you said, 100% agreed, and insightful, in particular:
>
> On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > I can see the potential for this to break down. However we should
> > not be crying wolf until this actually does break down.
>
> Do we want it to break down first? I don't want that.
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
Daniel Phillips <[email protected]> writes:
> All of what you said, 100% agreed, and insightful, in particular:
>
> On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > I can see the potential for this to break down. However we should
> > not be crying wolf until this actually does break down.
>
> Do we want it to break down first? I don't want that.
The price of freedom is continual vigilance.
So when confronted by changes in practice that we aren't sure about
the appropriate procedure is to ask (publicly?). If this is keeping
developers from participating. Or if it is placing a significant
barrier in the way of developers. If we start the conversation
without condemnation of change, we won't be crying wolf. Only asking
is that a wolf?
Addressing the filter is doing X fun. For me working with near-free
tools is not fun, because I must always be aware of the difference. I
am never quite certain where I stand with the tool vendor. The tool
is not free obviously because money making opportunities are more
important than my ability to use and modify the tool.
At the same time constant vigilance even of free software is required.
A non-free tool that does a sufficiently good job that I don't feel
like fixing it, is usable. It simply becomes a minor background
irritant that I can ignore.
Linus working more efficiently so he can accept more patches is
obviously more fun :)
Eric
On Saturday 20 April 2002 20:48, Russell King wrote:
> On Fri, Apr 19, 2002 at 08:15:14PM +0200, Daniel Phillips wrote:
> > All of what you said, 100% agreed, and insightful, in particular:
> >
> > On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > > I can see the potential for this to break down. However we should
> > > not be crying wolf until this actually does break down.
> >
> > Do we want it to break down first? I don't want that.
>
> 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.
Use for what? I'm not clear on this concept.
> 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...
Now you're crying wolf. Since when has developing and trying out tools
been bad?
> 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.)
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.
> 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.
Please show me where I said anyone should not use Bitkeeper.
> 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.
Not at all, you're just the ARM guy. <- funny, laugh
--
Daniel
On Saturday 20 April 2002 20:44, Eric W. Biederman wrote:
> Linus working more efficiently so he can accept more patches is
> obviously more fun :)
Yup.
--
Daniel
On Saturday 20 April 2002 20:13, you wrote:
> On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> > As always, what I do is in the interest of Linux and freedom.
>
> Then why do you want to deny us the freedom to have a very
> useful piece of documentation in the kernel tree ?
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
On Fri, Apr 19, 2002 at 09:43:48PM +0200, Daniel Phillips wrote:
> On Saturday 20 April 2002 20:13, you wrote:
> > On Fri, 19 Apr 2002, Daniel Phillips wrote:
> >
> > > As always, what I do is in the interest of Linux and freedom.
> >
> > Then why do you want to deny us the freedom to have a very
> > useful piece of documentation in the kernel tree ?
>
> 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?
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
On Saturday 20 April 2002 19:51, Linus Torvalds wrote:
> Any suggestions on how to make the process _appear_ less intimidating?
I'm thinking about it. It's still the best project on the planet, but even
so, could it be better?
> Note that one thing that I had hoped BK would do for me, but that hasn't
> happened because I'm a lazy bastard and I'm bad at doing automated scripts
> is to do dialy snapshots as patches (getting rid of the "-pre" kernels,
> since they don't actually add any information except act as update
> points), and also send out a changelog daily to the kernel mailing list.
Eeek. That sounds like a lot of work. Oh I see, this is 100% automated.
> That would actually make the development process MORE open than it was
> before BK, and might make even non-BK people appreciate BK more simply
> because there is a real point to it.
Well, it would be more like working in a fishbowl anyway. The part that's
missing is the discussion. Just looking at the recent traffic... there's
Martin Dalecki's IDE patch, gosh, look at all the fun. It's a non-BK
patch, let's see if there's a pattern. Hmm, the next bushy one is "[PATCH]
zerocopy NFS updated", descending from a traditional patch set. The next
one, "[PATCH] IDE TCQ #4" is also a traditional patch. Hmm, no bitkeeper
patches showing up yet, I don't think I need to go on.
There is a clear inverse relationship between the bk-ness of a patch and
the extent to which it's discussed on lkml. I don't know what to read into
that, but it does seem to lend credence to the idea that the bitkeeper
style of working is not compatible with the idea of community discussion.
Perhaps there are really two kinds of patches, those that are mainly
functional and don't need to be discussed, for which Bitkeeper is an
entirely appropriate medium, and patches-needing-discussion, for which
the Bitkeeper channel is entirely inappropriate. Most of the volume is in
the former, and hence, that is where most of the time savings are. The
corollary of that is, we will not lose a lot of productivity by *not*
using Bitkeeper for the kind of patch that could or should be discussed.
> Comments? Anybody want to hack up a script to do this?
Well, that's a nice thought, but it's not the crux of the problem.
--
Daniel
On Sat, Apr 20, 2002 at 07:19:23PM +0200, Roman Zippel wrote:
> Hi,
>
> Jeff Garzik wrote:
>
> > Daniel disagrees with the content of the speech in
> > Documentation/BK-usage, based on his ideology. And he attempted to
> > restrict the dissemination of that speech. What is the definition
> > of censorship again?
>
> Maybe I was to subtle, but your censorship argument is simply bullshit.
> A link to the information is completely sufficient.
What was Daniel's action? Remove the text. Nothing else. Sure, he
suggested other options, but he did attempt to implement them? No.
He just implied that people need to step up and do this work for him.
Daniel attempted to remove speech he disgreed with from wide
distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
it is plainly obvious that removing a doc from one of the mostly
widely distributed open source projects reduces the doc's distribution
dramatically. _That_ is a form of censorship, just like buying out
printing presses, to silence them, in the old days. It's still
around... just progressively harder to obtain.
> The only question
> is, whether the information is relevant for kernel development and most
> of it is only bk documentation.
And the answer is, it is BK documentation written for kernel developers
by kernel developers, with the intention of being a SubmittingPatches
document for BK users. Very relevant to kernel devel. This relevance
was proved by its origin -- emails bouncing back and forth, generally
originating by Linus, CC'ing me, asking me for the emails I had
already sent to other hackers, describing kernel development under BK.
After the info had been separately requested multiple times, it
got turned into a document -- the BK version of SubmittingPatches.
After that doc was requested multiple times, it went to the same
place where SubmittingPatches is stored.
Jeff
On Fri, Apr 19, 2002 at 11:02:04PM +0200, Daniel Phillips wrote:
> Martin Dalecki's IDE patch, gosh, look at all the fun. It's a non-BK
> patch, let's see if there's a pattern. Hmm, the next bushy one is "[PATCH]
> zerocopy NFS updated", descending from a traditional patch set. The next
> one, "[PATCH] IDE TCQ #4" is also a traditional patch. Hmm, no bitkeeper
> patches showing up yet, I don't think I need to go on.
>
> There is a clear inverse relationship between the bk-ness of a patch and
> the extent to which it's discussed on lkml. I don't know what to read into
> that, but it does seem to lend credence to the idea that the bitkeeper
> style of working is not compatible with the idea of community discussion.
Concrete examples, please?
Which patches are the stealth patches?
Jeff
Jeff Garzik wrote:
>
> And the answer is, it is BK documentation written for kernel developers
> by kernel developers, with the intention of being a SubmittingPatches
> document for BK users. Very relevant to kernel devel. This relevance
> was proved by its origin -- emails bouncing back and forth, generally
> originating by Linus, CC'ing me, asking me for the emails I had
> already sent to other hackers, describing kernel development under BK.
That's not true. Section 1 of 'SubmittingPatches' is entitled
"Creating and Sending Your Change" while section 1 of your
bk bullshit is called "Bitkeeper Concepts."
All of section 1 is an advertisement for using bk...including
directions on how to setup your own clone. Those are _clearly_
bitkeeper directions and have nothing to do with how to submit
patches.
Delete sections 1 & 2 and make section 3 the gist of the document
and _then_ you'll have the bk equivalent of 'SubmittingPatches.'
--
Skip
On Sat, 20 Apr 2002, Skip Ford wrote:
> All of section 1 is an advertisement for using bk...including
> directions on how to setup your own clone. Those are _clearly_
> bitkeeper directions and have nothing to do with how to submit
> patches.
I'm sure Jeff would be more than happy to include an
advertisement for a free bitkeeper alternative, once
one exists. ;)
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Sat, Apr 20, 2002 at 05:36:45PM -0400, Skip Ford wrote:
> Jeff Garzik wrote:
> >
> > And the answer is, it is BK documentation written for kernel developers
> > by kernel developers, with the intention of being a SubmittingPatches
> > document for BK users. Very relevant to kernel devel. This relevance
> > was proved by its origin -- emails bouncing back and forth, generally
> > originating by Linus, CC'ing me, asking me for the emails I had
> > already sent to other hackers, describing kernel development under BK.
>
> That's not true. Section 1 of 'SubmittingPatches' is entitled
> "Creating and Sending Your Change" while section 1 of your
> bk bullshit is called "Bitkeeper Concepts."
>
> All of section 1 is an advertisement for using bk...including
> directions on how to setup your own clone. Those are _clearly_
> bitkeeper directions and have nothing to do with how to submit
> patches.
What you call an ad is the result of evolution of several resendings
of similar emails, and answering FAQs. This is the stuff that has
proven useful over time.
To call that an advertisement is to insult the kernel developers
that asked these questions, which are answered in the doc. They were
not requesting endorsements, they were asking honest questions about
ways to optimize their kernel development, and merging with Linus.
Responding with an intro on how BK clones work has proven to be a
good first step to that.
Jeff
On Saturday 20 April 2002 23:07, Jeff Garzik wrote:
> On Fri, Apr 19, 2002 at 11:02:04PM +0200, Daniel Phillips wrote:
> > Martin Dalecki's IDE patch, gosh, look at all the fun. It's a non-BK
> > patch, let's see if there's a pattern. Hmm, the next bushy one is "[PATCH]
> > zerocopy NFS updated", descending from a traditional patch set. The next
> > one, "[PATCH] IDE TCQ #4" is also a traditional patch. Hmm, no bitkeeper
> > patches showing up yet, I don't think I need to go on.
> >
> > There is a clear inverse relationship between the bk-ness of a patch and
> > the extent to which it's discussed on lkml. I don't know what to read into
> > that, but it does seem to lend credence to the idea that the bitkeeper
> > style of working is not compatible with the idea of community discussion.
>
> Concrete examples, please?
>
> Which patches are the stealth patches?
Let me turn that around. Which bitkeeper patches have been posted to lkml and
generated significant amounts of discussion on lkml in the last week? Versus
how many lines of bitkeeper patches applied to Linus's tree?
I went through the 1,000 or so most recent postings on lkml, looking for patches
that generated discussion. Here's what I found:
BK patches generating discussion:
[PATCH] for_each_zone / for_each_pgdat
[BK PATCH] USB device support for 2.5.8
[BKPATCH 2.4] meye driver: fix request_irq bug
Non BK patches generating discussion:
[CFT][PATCH] (1/5) sane procfs/dcache interaction
[PATCH] Documenation/vm/numa
[PATCH] fix ips driver compile problems
[PATCH] IDE TCQ #4
[PATCH] migration thread fix
[PATCH] Wrong IRQ for USB on Sony Vaio (dmi_scan.c, pci-irq.c)
[PATCH] x86 boot enhancements, boot bean counting 8/11
[PATCH][2.5-dj] P4 thermal LVT (damage control)
[PATCHSET] Linux 2.4.19-pre7-jam1
[RFC] 2.5.8 sort kernel tables
page_alloc.c comments patch
[PATCH] Re: SSE related security hole
Both BK and non-BK:
[PATCH] i386 arch subdivision into machine types for 2.5.8
The next question you might ask is: are there more BK patches or
more Non-BK, in total, on and off lkml? I don't have statistics at
hand but I'm willing to bet that there are more BK patches, because
that is how the bulk of the grunt tree maintainance is getting
done these days.
My conclusion: though there are more BK patches being applied to Linus's
tree than non-BK, they are generating less discussion on lkml than non-BK
patches do. Or to put it bluntly: BK patches are not being discussed.
--
Daniel
From 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.*
At 23:00 20/04/02, Stevie O wrote:
> From what I can see, this is the situation:
>
>Daniel is now bothered by the presence of BK documentation in the Linux
>kernel tree. Therefore, he submitted a patch to remove this documentation.
>
>Just about everybody else involved in this thread accuses him of
>censorship, for attempting to restrict the dissemination of ideas. I do
>not know whether all of these people use BK; all I know is the
>"censorship" claim, on the basis that he is restricting the dissemination
>of information.
>
>I ask this: What if, instead of Daniel removing this documentation change,
>Linus himself did the patch?
That is completely different. Linus owns the Linux kernel. He is the
dictator on what happens with it. As such he can do with it as he pleases.
If anyone doesn't like his actions, they are free to fork the kernel and do
whatever they want. That is what the GPL is all about!
This thread is getting sillier and sillier...
Best regards,
Anton
>2600 asserted that source code is speech, with the DeCSS case. I doubt
>EVERYONE here agrees with that, but I do agree that source code is a very
>precise form of communcating ideas...
>
>
>(1) If I were to write a driver, and submit it for inclusion with the
>mainline kernel, would Linus be "censoring" me if he did not include my patch?
>
>And here is a better reason:
>
>(2) If I had such a driver included in mainline, and that driver broke in
>the 2.5 series -- due to, say, BIO changes, VFS changes, procfs changes,
>DMA changes, PCI subsystem changes, you get the idea -- and as a result,
>Linus chose to remove it from mainline, he's restricting the dissemination
>of my ideas (driver). Does that mean he is censoring me?
>
>--
>
>Stevie-O
>
>*This sig was deleted for violating the DMCA.*
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> Let me turn that around. Which bitkeeper patches have been posted to lkml and
> generated significant amounts of discussion on lkml in the last week? Versus
> how many lines of bitkeeper patches applied to Linus's tree?
Prior to BK, many people still emailed patches privately to Linus:
me, DaveM, Alan, Al, GregKH, ... You might consider private email
stealth, but usually the changes are either (a) obvious or (b)
previously discussed. With BK, the situation is the same.
So your argument is red herring -- which changes are _newly stealthed_
under BK? Do you have even ONE objectionable example?
BK only changes the medium of transmission of patches to Linus,
and gives us _more_ information about submittors than pre-BK.
> The next question you might ask is: are there more BK patches or
> more Non-BK, in total, on and off lkml? I don't have statistics at
> hand but I'm willing to bet that there are more BK patches, because
> that is how the bulk of the grunt tree maintainance is getting
> done these days.
> My conclusion: though there are more BK patches being applied to Linus's
> tree than non-BK,
So... your conclusion is based on a guess which is based on a guess.
Even if your conclusion is correct (it might be), how do you use
that to support the argument that, less discussion occurs due to BK?
As I mentioned, most merging with Linus occured in private anyway.
If you want to argue against that, go ahead. But don't try to blame
BitKeeper for it.
If there are _specific solutions_ that can be implemented to equalize
things with BK versus non-BK developers, please, chime in. I think the
daily snapshot idea is a good one. Deleting a document, and nothing
else, accomplishes no forward progress (except maybe spawning this
discussion on the evils of BK).
Jeff
On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> My conclusion: though there are more BK patches being applied to Linus's
> tree than non-BK, they are generating less discussion on lkml than non-BK
> patches do. Or to put it bluntly: BK patches are not being discussed.
Or maybe using a SCM puts more pressure on the developper which
writes better code, which will get accepted with less discussion.
In general, when you seek discussion with a quick and dirty piece
of code, you post a patch, not the BK equivalent, since you know
this will not get accepted anyway...
Stelian.
--
Stelian Pop <[email protected]>
Alcove - http://www.alcove.com
On Sat, Apr 20, 2002 at 06:00:36PM -0400, Stevie O wrote:
> (1) If I were to write a driver, and submit it for inclusion with
> the mainline kernel, would Linus be "censoring" me if he did not
> include my patch?
(IMO my answer fits for both these examples)
> (2) If I had such a driver included in mainline, and that driver
> broke in the 2.5 series -- due to, say, BIO changes, VFS changes,
> procfs changes, DMA changes, PCI subsystem changes, you get the
> idea -- and as a result, Linus chose to remove it from mainline,
> he's restricting the dissemination of my ideas (driver). Does that
> mean he is censoring me?
In the strictest sense, yes. But the key difference would be his
reasoning in your example would be technical, whereas Daniel's stated
reason was ideology.
One of the reasons why I like the Linux kernel is the freedom to make
the best technical decision, regardless of conflicting ideologies or
politics.
Jeff
On Sunday 21 April 2002 00:20, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> > Let me turn that around. Which bitkeeper patches have been posted to lkml and
> > generated significant amounts of discussion on lkml in the last week? Versus
> > how many lines of bitkeeper patches applied to Linus's tree?
>
> Prior to BK, many people still emailed patches privately to Linus:
> me, DaveM, Alan, Al, GregKH, ... You might consider private email
> stealth, but usually the changes are either (a) obvious or (b)
> previously discussed. With BK, the situation is the same.
>
> So your argument is red herring -- which changes are _newly stealthed_
> under BK? Do you have even ONE objectionable example?
Of course I do: the patch to add the Bk files to Documentation. I will not
call that objectionable - I object to it, but that is not the same thing. I
will call it 'not discussed' when it should have been.
> BK only changes the medium of transmission of patches to Linus,
> and gives us _more_ information about submittors than pre-BK.
I'm not arguing that BK is not a good way to do the grunt maintainance work.
I think it is, and that's great. Heck, I'm not arguing against Bitkeeper *at
all*. I'm arguing against building the bitkeeper documentation into the
kernel tree, giving the impression that Bitkeeper is *required* for
submitting patches.
> > The next question you might ask is: are there more BK patches or
> > more Non-BK, in total, on and off lkml? I don't have statistics at
> > hand but I'm willing to bet that there are more BK patches, because
> > that is how the bulk of the grunt tree maintainance is getting
> > done these days.
>
> > My conclusion: though there are more BK patches being applied to Linus's
> > tree than non-BK,
>
> So... your conclusion is based on a guess which is based on a guess.
Check it if you think I'm wrong.
> Even if your conclusion is correct (it might be), how do you use
> that to support the argument that, less discussion occurs due to BK?
We haven't established that, we do see a strong correlation. But think.
It's obvious anyway, why discuss anything in public when you don't have
to? Just push it straight to Linus's tree, why bother with formalities?
It's so easy.
> As I mentioned, most merging with Linus occured in private anyway.
> If you want to argue against that, go ahead. But don't try to blame
> BitKeeper for it.
I sense that the discussion of patches on lkml is in decline and I do
blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
> If there are _specific solutions_ that can be implemented to equalize
> things with BK versus non-BK developers, please, chime in. I think the
> daily snapshot idea is a good one.
I think so too, having heard more about the idea.
> Deleting a document, and nothing
> else, accomplishes no forward progress (except maybe spawning this
> discussion on the evils of BK).
Larry already agreed to it, and to provide a new home for it. Linus
said 'don't be silly', but that was a long way back. So that's where
it stands.
--
Daniel
On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> I went through the 1,000 or so most recent postings on lkml, looking for
> patches that generated discussion. Here's what I found:
Nice work. However, you forgot the other half of the job - finding out
how many BK "patches" got merged into Linus' tree, and how many GNU
patches. Only then can we make a real comparison.
And yes, I've done Linus a favour - I've deleted him from the CC: list
because he's said he's not interested in this discussion.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, Apr 20, 2002 at 12:34:19AM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 00:20, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> > > Let me turn that around. Which bitkeeper patches have been posted to lkml and
> > > generated significant amounts of discussion on lkml in the last week? Versus
> > > how many lines of bitkeeper patches applied to Linus's tree?
> >
> > Prior to BK, many people still emailed patches privately to Linus:
> > me, DaveM, Alan, Al, GregKH, ... You might consider private email
> > stealth, but usually the changes are either (a) obvious or (b)
> > previously discussed. With BK, the situation is the same.
> >
> > So your argument is red herring -- which changes are _newly stealthed_
> > under BK? Do you have even ONE objectionable example?
>
> Of course I do: the patch to add the Bk files to Documentation. I will not
> call that objectionable - I object to it, but that is not the same thing. I
> will call it 'not discussed' when it should have been.
It was requested by Linus to be in the tree as a convenience, because he
and I and others were constantly bouncing it to new people.
I don't see the point of discussing such an obvious patch, outside of
ideological grounds. And when we start making decisions based on
ideology and politics rather than technical merit, we can all go home.
> > BK only changes the medium of transmission of patches to Linus,
> > and gives us _more_ information about submittors than pre-BK.
>
> I'm not arguing that BK is not a good way to do the grunt maintainance work.
> I think it is, and that's great. Heck, I'm not arguing against Bitkeeper *at
> all*. I'm arguing against building the bitkeeper documentation into the
> kernel tree, giving the impression that Bitkeeper is *required* for
> submitting patches.
I think the conclusion that BitKeeper is required, because of the
presence of this documentation, is ludicrous. And I have already stated
many times that I think objecting to the presence of the doc solely on
ideological grounds is also ludicrous.
Linus repeatedly says GNU patches are still acceptable, did you miss that?
> > Even if your conclusion is correct (it might be), how do you use
> > that to support the argument that, less discussion occurs due to BK?
>
> We haven't established that, we do see a strong correlation. But think.
> It's obvious anyway, why discuss anything in public when you don't have
> to? Just push it straight to Linus's tree, why bother with formalities?
> It's so easy.
This "it's easy" argument can easily be applied to the pre-BK days.
Straight-to-Linus-without-discussion is obviously faster, regardless of
whether BK is used or not.
> > As I mentioned, most merging with Linus occured in private anyway.
> > If you want to argue against that, go ahead. But don't try to blame
> > BitKeeper for it.
>
> I sense that the discussion of patches on lkml is in decline and I do
> blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
huh?? "I <think this>. Am I wrong? Prove it."
Typically, one is expected to prove their arguments :)
Can you offer any evidence of patches that would have been discussed, in
the pre-BK days, that are no longer discussed? Support your argument,
please.
> > Deleting a document, and nothing
> > else, accomplishes no forward progress (except maybe spawning this
> > discussion on the evils of BK).
>
> Larry already agreed to it, and to provide a new home for it. Linus
> said 'don't be silly', but that was a long way back. So that's where
> it stands.
IOW, it stands at 'don't be silly'.
IMO the acceptance of your patch would indicate that Linus has started
accepting patches based on something other than technical merit.
_There_ is your slippery slope we should avoid at all costs.
Jeff
> On Sat, 20 Apr 2002, Skip Ford wrote:
> > All of section 1 is an advertisement for using bk...including
> > directions on how to setup your own clone. Those are _clearly_
> > bitkeeper directions and have nothing to do with how to submit
> > patches.
>
> I'm sure Jeff would be more than happy to include an
> advertisement for a free bitkeeper alternative, once
> one exists. ;)
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
Daniel Phillips wrote:
> 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.
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.
On Friday 19 April 2002 02:27 pm, Daniel Phillips wrote:
> 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...
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
Hi,
Jeff Garzik wrote:
> What was Daniel's action? Remove the text. Nothing else. Sure, he
> suggested other options, but he did attempt to implement them? No.
> He just implied that people need to step up and do this work for him.
He made his intention very clear, you are interpreting something in his
action, that simply isn't there.
> Daniel attempted to remove speech he disgreed with from wide
> distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
> it is plainly obvious that removing a doc from one of the mostly
> widely distributed open source projects reduces the doc's distribution
> dramatically. _That_ is a form of censorship, just like buying out
> printing presses, to silence them, in the old days. It's still
> around... just progressively harder to obtain.
Censorship requires the means to enforce it and has Daniel this ability?
Could we please stop these "censorship" and "ideology" arguments? In
this context they are simply nonsense.
> And the answer is, it is BK documentation written for kernel developers
> by kernel developers, with the intention of being a SubmittingPatches
> document for BK users. Very relevant to kernel devel. This relevance
> was proved by its origin -- emails bouncing back and forth, generally
> originating by Linus, CC'ing me, asking me for the emails I had
> already sent to other hackers, describing kernel development under BK.
kernel development with bk requires net access and so it's sufficient,
when it's available over the net. On the other hand SubmittingPatches
describes the lowest common denominator, which works with any SCM and
doesn't favour any of them.
Personally I don't care what tools people use, but I'm getting
concerned, when a nonfree tool is advertised as tool of choice for
kernel for development as if there would be no choice. bk has advantages
for distributed development, but beside of this they are alternatives
and we should rather encourage users to try them and to help with the
development of them. But there isn't anything like that, so Joe Hacker
has to think he should use bk as SCM to get his patch into the kernel,
because Linus is using it.
bye, Roman
On Sun, Apr 21, 2002 at 02:04:07AM +0200, Roman Zippel wrote:
> kernel development with bk requires net access and so it's sufficient,
> when it's available over the net. On the other hand SubmittingPatches
> describes the lowest common denominator, which works with any SCM and
> doesn't favour any of them.
Huh? BK requires no more net access than you require when submitting
a regular patch. You need to be connected to move the bits. Working
disconnected is one of the things BK does best, compare it to any other
tool and you can do far more with BK unconnected, simply because BK
takes the history with you.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 20 Apr 2002, Jeff Garzik wrote:
> Which patches are the stealth patches?
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.."
Linus Torvalds Awoke this dragon, who will now respond:
> "I do this because it's FUN and
> because others might find it useful, not because I got religion".
Dude, I agree, but that is your /IDEOLOGY/, is it not?
Jeff Garzik Awoke this dragon, who will now respond:
> > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > A link to the information is completely sufficient.
>
> What was Daniel's action? Remove the text. Nothing else. Sure, he
> suggested other options, but he did attempt to implement them? No.
Be realistic - how is he supposed to do that?
Daniel Phillips Awoke this dragon, who will now respond:
> A steady slide toward proprietary tools and behind-the-scenes development
> in cathedral-style is an issue.
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...
Jeff Garzik Awoke this dragon, who will now respond:
> 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
> Rot in hell, closed mind.
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.
Stelian Pop Awoke this dragon, who will now respond:
> Or maybe using a SCM puts more pressure on the developper which
> writes better code, which will get accepted with less discussion.
I dont buy that. Its well known that teams of programmers tend to write
WORSE code when they dont talk to each other.
Anton Altaparmakov Awoke this dragon, who will now respond:
> That is completely different. Linus owns the Linux kernel.
Out of interest, since when?
Jeff Garzik Awoke this dragon, who will now respond:
>
> You tried to -remove-, not include something.
Well, what else can he do? he can hardly go back in time and start the
discussion that really should have happened...
Russell King Awoke this dragon, who will now respond:
> 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.
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?
Em Sun, Apr 21, 2002 at 03:57:59AM +0100, Ian Molton escreveu:
> Russell King Awoke this dragon, who will now respond:
> > 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.
>
> 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 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:
> The documentation being discussed is not proprietary, it only talks about
> a non essential proprietary tool used now by lots of kernel hackers.
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?
Em Sun, Apr 21, 2002 at 04:46:16AM +0100, Ian Molton escreveu:
> Arnaldo Carvalho de Melo Awoke this dragon, who will now respond:
>
> > The documentation being discussed is not proprietary, it only talks about
> > a non essential proprietary tool used now by lots of kernel hackers.
>
> well, this raises an interesting point...
>
> should documentation be regarded as part of the package it documents or
> not?
yes, and this is the case :)
> is this 'bitkeeper documentation', 'documentation about bitkeeper', or
> 'linux kernel documentation', or what?
This is "how to use bitkeeper with the Linux kernel sources and to submit
patches to Linus", AFAIK...
As pointed out by Linus, in the jfs subtree there is similar docs, but using
CVS instead.
Ah, removing Linus from the CC list as he is not interested in this thread
at all :)
- Arnaldo
On Sun, 21 Apr 2002, Ian Molton wrote:
> 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.
On Sun, 21 Apr 2002, Alexander Viro wrote:
>
> "Linus documentation".
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
Alexander Viro Awoke this dragon, who will now respond:
>
> 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 orSure, except no-one cares about this point.
Sure, except no-one cares about this point.
the documentation is the 'sticky wicket'...
From: Ian Molton <[email protected]>
Date: Sun, 21 Apr 2002 05:31:43 +0100
Alexander Viro Awoke this dragon, who will now respond:
> 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 orSure, except no-one cares about this point.
Sure, except no-one cares about this point.
the documentation is the 'sticky wicket'...
Incorrect. The argument for the documentation was that it along with
other things wrt. BK create some "barrier to entry" for Linux kernel
development and almost force someone to use BK. That someone just
submitting patches is somehow "left out".
Al is showing that these claims are not well founded at all.
"David S. Miller" wrote:
>
> 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.
Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
please. "-20Apr02" would suit. (I suspect if that started happening,
the -pre's would become redundant. But that can be decided at a later
stage)
-
David S. Miller Awoke this dragon, who will now respond:
> From: Ian Molton <[email protected]>
> Date: Sun, 21 Apr 2002 05:31:43 +0100
> Sure, except no-one cares about this point.
> the documentation is the 'sticky wicket'...
>
> Incorrect. The argument for the documentation was that it along with
> other things wrt. BK create some "barrier to entry" for Linux kernel
> development and almost force someone to use BK. That someone just
> submitting patches is somehow "left out".
>
> Al is showing that these claims are not well founded at all.
hmm.
I take it as blatently obvious that BK isnt a barrier to entry, as the old
methods still work fine.
what I /do/ appreciate is that by including directions to proprietary tools
in the docs, we are heading down a greased incline, so to speak.
Extreme example:
Include docs on 'how to avoid a pesky kernel compile' that teach how to
install windows, not linux because its an 'all in one' install with 'no
hassle'...
see how many people compile their own kernels afer that...
From: Ian Molton <[email protected]>
Date: Sun, 21 Apr 2002 05:42:53 +0100
what I /do/ appreciate is that by including directions to proprietary tools
in the docs, we are heading down a greased incline, so to speak.
And Linus is telling everyone it's his tree and if you don't like it
distribute your own tree without the doc file or implement an free
source management system that he can use.
Alexander Viro wrote:
>
> 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.
That's only 1 aspect. The frustrating part is bug reports mailed to the
list getting a response of "oh, that's fixed in the latest bk tree."
That's happened a dozen times in the last week...no wonder non-bk users
feel out of the loop. I've been staring at the code for a lot of years
and it's finally just starting to make sense to me, now by the time I see
it the core hackers have moved on to something else.
Daily snapshots would be great.
--
Skip
Ian Molton wrote:
> what I /do/ appreciate is that by including directions to proprietary tools
> in the docs, we are heading down a greased incline, so to speak.
>
> Extreme example:
>
> Include docs on 'how to avoid a pesky kernel compile' that teach how to
> install windows, not linux because its an 'all in one' install with 'no
> hassle'...
Come on, it's not like suddenly all the people who contribute to linux
are going to become blind and fall down the slippery slope. Slippery
slope arguments only work in academic debates, the real world is much too
complex and robust to be susceptible, especially in the long term.
There's bugs to fix and features to add. The day they are not accepted
because of your patch format, then we can take appropriate action.
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
On Apr 20, 2002 21:32 -0700, Andrew Morton wrote:
> Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
> please. "-20Apr02" would suit. (I suspect if that started happening,
> the -pre's would become redundant. But that can be decided at a later
> stage)
Well, hopefully it will be "-pre020420" so that increasing kernel
versions can be sorted... Also, skip releasing snapshots on days
when no new deltas have been applied...
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
On Sun, 21 Apr 2002, Ian Molton wrote:
> I take it as blatently obvious that BK isnt a barrier to entry, as the old
> methods still work fine.
>
> what I /do/ appreciate is that by including directions to proprietary tools
> in the docs, we are heading down a greased incline, so to speak.
Sigh... When it comes to software there are three systems of beliefs.
One of them:
* Thou shalt know by your heart that all software sucks.
* Beware of those who say that their software does not suck, for they
are either fools or liars.
* Beware of those who give you garments and do not allow to mend them,
for sooner or later thou shalt find what needs mending.
* But beware also of those who give you badly rotten garments and say
"Thou shalt prefer that above everything, for thou art allowed to
mend it".
* Thou shalt not treat software as a living being, for it is not one.
* Choose a license of thine liking for sofware thou writest and do not
blame those who choose differently for software they write.
* Know when to say "It can be mended, I shalt do that" and when to
say "It is rotten beyond repair".
* Choose free over non-free when it is better or when thou art willing
to fix what is broken.
* When shit happens, think how to fix it.
Another:
* All software wants to be free
* Thou shalt not use non-free software
* Thou shalt not mention non-free software
* Thou shalt make all thine software free
* Thou shalt choose free above working, even if free one is broken
beyond repair
* When shit happens, add new features
and the last one:
* Our 3133t! K3wl! Software! Does Not Suck!!!
* Always choose our software above everything else
* When shit happens, we add new features
If you happen to believe in second variant, you have my condolence as
long as you don't force your beliefs on everybody else. If you choose
to emulate door-to-door pests^H^H^H^Hreachers - don't expect to be
treated differently.
On Friday 19 April 2002 06:34 pm, Daniel Phillips wrote:
> I'm not arguing that BK is not a good way to do the grunt maintainance
> work. I think it is, and that's great. Heck, I'm not arguing against
> Bitkeeper *at all*. I'm arguing against building the bitkeeper
> documentation into the kernel tree, giving the impression that Bitkeeper is
> *required* for submitting patches.
I'm under the impression that Linus specifically asked for that
documentation, because BK is a tool he used that he was getting flooded with
questions about.
The question isn't really whether BitKeeper is required for kernel
development, it's a question of whether submitting patches to LINUS is
required for kernel development.
It seems like the BitKeeper documentation belongs together with the other
submitting patches documentation, and should be moved to the directory
"Documentation/Linus".
I.E. explicitly, the Kernel is only interested in documenting bitkeeper to
the extent we're documenting how Linus works. (And it IS how Linus works.)
If you're going to argue about Linus being a single point of failure (and
quite possibly a closed and irreproducible system for which we have not seen
source code), that's a can of worms I'm staying well away from this time
'round, thanks. :)
It might be a good idea if there was a Documentation/SubmittingPatches
directory that mentioned where the various active high visibility trees are
and what they're for (Linus's 2.5 tree, Dave Jones's tree, Marcelo's 2.4
tree, and Alan Cox's come to mind.) But that sort of wanders off into
Maintainers land (to get USB patches in, send them to Greg KH, who has this
email address and whose bitkeeper tree can be pulled from...) With all the
maintenance issues that implies...
> > > The next question you might ask is: are there more BK patches or
> > > more Non-BK, in total, on and off lkml? I don't have statistics at
> > > hand but I'm willing to bet that there are more BK patches, because
> > > that is how the bulk of the grunt tree maintainance is getting
> > > done these days.
> > >
> > > My conclusion: though there are more BK patches being applied to
> > > Linus's tree than non-BK,
> >
> > So... your conclusion is based on a guess which is based on a guess.
>
> Check it if you think I'm wrong.
I think he's saying that the burden of proof about there BEING a problem
rests on the one who is complaining about the problem. Complaining and then
expecting other people to prove there ISN'T a problem is kind of impolite...
> > Even if your conclusion is correct (it might be), how do you use
> > that to support the argument that, less discussion occurs due to BK?
>
> We haven't established that, we do see a strong correlation. But think.
> It's obvious anyway, why discuss anything in public when you don't have
> to? Just push it straight to Linus's tree, why bother with formalities?
> It's so easy.
And this differs from emailing him a patch without cc'ing linux-kernel in
what way?
Either you trust Linus's judgement about what patches to accept, or you use
somebody else's tree. Did I miss where voting on linux-kernel ever got a
patch in that Linus didn't want to merge, or kept one out that he did?
And AFTER the merge, you still get to flame all you want. And produce a
better patch to "clean up" the old one the way Martin "cleaned" Andre's name
right out of the maintainers file...
I seem to remember Al Viro taking a clue-by-four to Richard Gooch's head over
devfs on a fairly regular basis, and it was generally about the stuff that
had already made it into the tree, not about pending unmerged stuff.
The ONLY reduction in access I can see to Linus's pending unmerged patch
queue is due to the fact that completed patches don't hang around unmerged
for months at a time anymore. And since Bitkeeper seems to have
significantly contributed to lubricating Linus's in-box, I consider it a net
benefit.
Yes, it's a proprietary tool with "source under glass" licensing, but it's
basically a groupware application. Linus might as well be using proprietary
email software: as long as the email he sends and receives is still ascii
text, I can't say it makes a difference to me.
Think data, not applications. The kernel tarballs produced are completely
independent of bitkeeper. Patches contributed to the kernel tarballs have
been made without bitkeeper for a decade, and can still be made and
contributed without use of bitkeeper. The data being transmitted starts and
ends in the same open format as always (C source code in a filesystem->C
source code in a tarball), and the process in between is well understood and
could be done by hand (even with paper and pencil) if necessary. Bitkeeper
just helps Linus to scale.
Proprietary software sucks when you derive work from it in an exclusive and
dependent way. Then they own your derived work. (Like a microsoft word file
you wrote, which microsoft can charge you to access because they own word and
your file is useless without it.) When it's something you can use but don't
have to, it's basically a service. Not owning a service is unsuprising.
In this case, none of the Linux kernel's end product is derived from
bitkeeper. It's just using bitkeeper as an optional tool in the process of
producing that work. It's analogous to using a proprietary bios to boot your
Linux kernel: if it causes a problem, it can be replaced without changing the
kernel being booted in any way.
> > As I mentioned, most merging with Linus occured in private anyway.
> > If you want to argue against that, go ahead. But don't try to blame
> > BitKeeper for it.
>
> I sense that the discussion of patches on lkml is in decline and I do
> blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
I sense that the chronic memory management problems of early 2.4 have finally
calmed down a bit, that 2.5 has opened so people have an outlet for CODE
rather than just plans for code, and that rather a lot of the intellectual
bandwidth of the list is currently devoted to keeping up with all the changes
in 2.5 that have already been made or are immediately pending, rather than
speculating about a future that hasn't been coded yet. And that the best
flamewar we've managed to come up with recently (before this one) has been
about the IDE subsystem (far too technical for most people to get really
upset about) rather than something juicy like CML2's use of a version of
Python that Red Hat doesn't ship yet. :)
I also sense that it's spring, the weather's nice and the flowers are
blooming, and certain people might be spending some of their time away from a
computer in a way that isn't as much of an option in the winter...
Rob
On Friday 19 April 2002 03:43 pm, Daniel Phillips wrote:
> 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?
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
On Sunday 21 April 2002 12:05 am, Alexander Viro wrote:
> 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.
The well-defined resync points are the 2.5.N releases. If -pre goes away,
then the dot-releases might need to come a little closer together, that's all.
Rob
On Sun, Apr 21, 2002 at 12:40:11AM -0400, Skip Ford wrote:
> That's only 1 aspect. The frustrating part is bug reports mailed to the
> list getting a response of "oh, that's fixed in the latest bk tree."
>
> That's happened a dozen times in the last week...no wonder non-bk users
> feel out of the loop. I've been staring at the code for a lot of years
> and it's finally just starting to make sense to me, now by the time I see
> it the core hackers have moved on to something else.
>
> Daily snapshots would be great.
We have hourly snapshots, thanks to the work David Woodhouse and
Rik van Riel did at a moments notice. Does this satisfy your
concerns above?
I have a suspicion that the problem of conflicting obvious fixes
won't go away.
There's another interesting twist here... - I didn't see any of them on
linux-kernel.
<joke>
I'm a BK user! GNU patches are being submitted behind my back without
discussion on linux-kernel. I'm going to remove the SubmittingPatches
document! It's harming discussion of patches on linux-kernel.
</joke>
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Hi Larry,
> Huh? BK requires no more net access than you require when submitting
> a regular patch. You need to be connected to move the bits.
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,
> > We dont allow proprietary modules in the kernel, why should docs be any
> > different?
>
> The documentation being discussed is not proprietary, it only talks about a non
> essential proprietary tool used now by lots of kernel hackers.
So would Linus accept a document on how to run Linux/390 on hercules (yet
another proprietary emulator)? This also was a FAQ on the linux-390
mailing list until the documentation is available on the hercules home
page...
Developing kernel stuff on 390 without emulator can be much fun as host
operators tend to get very pissed if the IPL ratio comes near to 1/min ;-)
--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,
On Sun, 21 Apr 2002, Thunder from the hill wrote:
> Could you please stop carbon copying to Linux?
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>
At 10:22 21/04/02, Jochen Friedrich wrote:
>Hi Larry,
>
> > Huh? BK requires no more net access than you require when submitting
> > a regular patch. You need to be connected to move the bits.
>
>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.
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/
Alexander Viro Awoke this dragon, who will now respond:
>
> If you happen to believe in second variant, you have my condolence as
> long as you don't force your beliefs on everybody else.
What provoked that?!!
On Sun, 21 Apr 2002, Jochen Friedrich wrote:
> > Huh? BK requires no more net access than you require when submitting
> > a regular patch. You need to be connected to move the bits.
>
> 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.
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/
On Sun, Apr 21, 2002 at 10:18:34AM -0300, Rik van Riel wrote:
> On Sun, 21 Apr 2002, Jochen Friedrich wrote:
>
> > > Huh? BK requires no more net access than you require when submitting
> > > a regular patch. You need to be connected to move the bits.
> >
> > 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.
>
> So you're telling me that what I've been doing over the
> last months really shouldn't have been possible ?
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.
http://www.fsmlabs.com http://www.rtlinux.com
> 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.
: Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
: please. "-20Apr02" would suit.
= Well, hopefully it will be "-pre020420" so that increasing kernel
= versions can be sorted... Also, skip releasing snapshots on days
= when no new deltas have been applied...
In the good old days we had frequent releases.
For example, the 1.3 series went from 1.3.1 to 1.3.100
in eleven months, an average of one patch every three days.
These days we have pre-patches (15 since Feb 1), and patches
(5 since Feb 1) showing an average of one patch every four days.
So, maybe there is a small slow-down, or maybe the testintervals
were chosen unfortunately.
If it is possible to increase the fequency with which patches are
released, then that is very good. There is no need to invent new
numbering schemes. Indeed, I would be in favour of collapsing
the present scheme (for 2.5), and call everything patch-2.5.N,
no reason to panic when N reaches into the hundreds.
The reason I object to "-20Apr02" or "-pre020420" is that it
makes it difficult to see whether there are missing patches
in a given archive. Sequential numbering is better.
(Moreover, there might be two patches on one day, there is a
handful of examples already.)
Concerning the collapsing of patches and prepatches:
For a stable series like 2.4 one needs pre-patches to have a
test-period. For an unstable series like 2.5 pre-patches only
cause a small amount of hassle (the naming is different, they
live in different directories, the patches are not incremental,
incremental patches again have a different naming scheme)
and as far as I can see the presumed advantage, namely that the
result of a patch is more stable than that of a pre-patch, is
absent so far in the 2.5 series. Maybe prepatches should first
be reinvented again shortly before the release of 2.6.
Andries
On Sun, Apr 21, 2002 at 11:22:10AM +0200, Jochen Friedrich wrote:
> Hi Larry,
>
> > Huh? BK requires no more net access than you require when submitting
> > a regular patch. You need to be connected to move the bits.
>
> 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.
Wrong -- both BK and CVS can be proxied.
CVS takes a bit more effort. 'bk helptool url' gives you proxy info for BK.
Jeff
On Sun, Apr 21, 2002 at 03:30:38AM +0100, Ian Molton wrote:
> Jeff Garzik Awoke this dragon, who will now respond:
>
> > > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > > A link to the information is completely sufficient.
> >
> > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > suggested other options, but he did attempt to implement them? No.
>
> Be realistic - how is he supposed to do that?
It's really trivial to put a document up on a Web site, before
submitting a patch to remove said document. Or to contact someone, and
get them to post the doc.
Did he even attempt to do that? No.
Jeff
On Sat, Apr 20, 2002 at 08:38:26PM -0500, Oliver Xymoron wrote:
> On Sat, 20 Apr 2002, Jeff Garzik wrote:
>
> > Which patches are the stealth patches?
>
> 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.
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
On Sun, Apr 21, 2002 at 03:57:59AM +0100, Ian Molton wrote:
> Russell King Awoke this dragon, who will now respond:
>
> > 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.
>
> I dont think Daniel claimed BK was contributing to linux downfall.
Sure he did.
> 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 docs are not proprietary.
Jeff
On Sun, Apr 21, 2002 at 04:46:16AM +0100, Ian Molton wrote:
> Arnaldo Carvalho de Melo Awoke this dragon, who will now respond:
>
> > The documentation being discussed is not proprietary, it only talks about
> > a non essential proprietary tool used now by lots of kernel hackers.
>
> well, this raises an interesting point...
>
> should documentation be regarded as part of the package it documents or
> not?
No, it doesn't raise this point. Documentation is licensed either
separately, or with the package containing it. As it is here.
There is no "should it be regarded" questions.
Jeff
Here's my wrapup...
On Sunday 21 April 2002 03:41, Rob Landley wrote:
> On Friday 19 April 2002 06:34 pm, Daniel Phillips wrote:
> > I'm not arguing that BK is not a good way to do the grunt maintainance
> > work. I think it is, and that's great. Heck, I'm not arguing against
> > Bitkeeper *at all*. I'm arguing against building the bitkeeper
> > documentation into the kernel tree, giving the impression that Bitkeeper is
> > *required* for submitting patches.
>
> I'm under the impression that Linus specifically asked for that
> documentation, because BK is a tool he used that he was getting flooded with
> questions about.
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'.
> 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".
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 ;-)
> 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.)
> > > Even if your conclusion is correct (it might be), how do you use
> > > that to support the argument that, less discussion occurs due to BK?
> >
> > We haven't established that, we do see a strong correlation. But think.
> > It's obvious anyway, why discuss anything in public when you don't have
> > to? Just push it straight to Linus's tree, why bother with formalities?
> > It's so easy.
>
> And this differs from emailing him a patch without cc'ing linux-kernel in
> what way?
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.
> Either you trust Linus's judgment 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?
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.
> And AFTER the merge, you still get to flame all you want.
No no no. Think about what you just said. Barn. Door. Horse. Gone.
> 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, 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.
> 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 unsurprising.
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
On Sunday 21 April 2002 17:33, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 03:30:38AM +0100, Ian Molton wrote:
> > Jeff Garzik Awoke this dragon, who will now respond:
> >
> > > > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > > > A link to the information is completely sufficient.
> > >
> > > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > > suggested other options, but he did attempt to implement them? No.
> >
> > Be realistic - how is he supposed to do that?
>
> It's really trivial to put a document up on a Web site, before
> submitting a patch to remove said document. Or to contact someone, and
> get them to post the doc.
>
> Did he even attempt to do that? No.
You're wrong. I suggested posting the documents on the bitkeeper site among
other things and Larry agreed to do that. What do you think I should have done,
demanded that Larry do that?
--
Daniel
On Sat, Apr 20, 2002 at 09:46:43PM -0400, Rob Landley wrote:
> 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?
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
Em Sun, Apr 21, 2002 at 11:28:36AM +0200, Jochen Friedrich escreveu:
> > > We dont allow proprietary modules in the kernel, why should docs be any
> > > different?
> >
> > The documentation being discussed is not proprietary, it only talks about a non
> > essential proprietary tool used now by lots of kernel hackers.
>
> So would Linus accept a document on how to run Linux/390 on hercules (yet
> another proprietary emulator)? This also was a FAQ on the linux-390
Don't know, tried to submit?
Just checked, Hercules is not a proprietary emulator, in fact it is licensed
under the QPL. http://www.conmicro.cx/hercules/herclic.html
> mailing list until the documentation is available on the hercules home
> page...
> Developing kernel stuff on 390 without emulator can be much fun as host
> operators tend to get very pissed if the IPL ratio comes near to 1/min ;-)
<joke>
Another good question: does Linus cares about Linux S/390? ;)
</joke>
- Arnaldo
On Sat, Apr 20, 2002 at 05:46:57PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 17:33, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 03:30:38AM +0100, Ian Molton wrote:
> > > Jeff Garzik Awoke this dragon, who will now respond:
> > >
> > > > > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > > > > A link to the information is completely sufficient.
> > > >
> > > > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > > > suggested other options, but he did attempt to implement them? No.
> > >
> > > Be realistic - how is he supposed to do that?
> >
> > It's really trivial to put a document up on a Web site, before
> > submitting a patch to remove said document. Or to contact someone, and
> > get them to post the doc.
> >
> > Did he even attempt to do that? No.
>
> You're wrong. I suggested posting the documents on the bitkeeper site among
> other things and Larry agreed to do that. What do you think I should have done,
> demanded that Larry do that?
Suggestion != doing
If Linus had applied your patch, there would be a lag time during which
the doc would have no home at all.
Anything _other_ than removal before re-posting, what you attempted to
do, would have been far more palatable. One doesn't create their
fallback _after_ they nuke the primary.
Jeff
On Sat, Apr 20, 2002 at 05:44:07PM +0200, Daniel Phillips wrote:
> Here's my wrapup...
What a shame...
> 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.
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
In article <E16yx1z-0000jV-00@starship> you wrote:
> 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.
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.
On Sunday 21 April 2002 17:59, Russell King wrote:
> On Sat, Apr 20, 2002 at 05:44:07PM +0200, Daniel Phillips wrote:
> > 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.
>
> 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.
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.
> 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.
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.
> 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.
Right. I made the conjecture, if you wish to verify/disprove it then feel
free. I did my share of the work already.
--
Daniel
On Sat, Apr 20, 2002 at 06:10:12PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 17:59, Russell King wrote:
> > 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.
>
> I already did both, and posted the results.
Yes you did. The results were meaningless without reference to which
gets into Linus' tree and which don't.
> 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.
Shrug - I'm not going to waste my time trying to prove _your_ point to
myself.
> Right. I made the conjecture,
Correct, and it isn't up to me to prove it.
> if you wish to verify/disprove it then feel
> free. I did my share of the work already.
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
On Sat, Apr 20, 2002 at 06:10:12PM +0200, Daniel Phillips wrote:
> Right. I made the conjecture, if you wish to verify/disprove it then feel
> free. I did my share of the work already.
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
On Sun, 21 Apr 2002, Jeff Garzik wrote:
> 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
Daniel Phillips writes:
> On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > Daniel,
> >
> > This is not documentation for bitkeeper but how to use bitkeeper
> > effectively for kernel development. It happens to be DAMN USEFULL
> > documentation at that for anyone wanting to use bitkeeper for kernel
> > development so IMO it fully belongs in the kernel. Just like the
> > SubmittingPatches document does, too. Or are you going to remove that as well?
>
> By that logic, we should also include the lkml FAQ in the kernel
> tree. Should we?
No. A pointer to the lkml FAQ is sufficient.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sun, 21 Apr 2002, Ian Molton wrote:
> Extreme example:
>
> Include docs on 'how to avoid a pesky kernel compile' that teach how to
> install windows, not linux because its an 'all in one' install with 'no
> hassle'...
your analogy is false because in the case of the bitkeeper documentation
it explains an alternate which accomplishes something the same as
SubmittingPatches (some would say more, i.e. changelogs). however Windows
does not accomplish the same as Linux. for example, i can't run windows
on ARM (i take it from your mail address that ARM is of interest to you).
-dean
On Sun, Apr 21, 2002 at 02:04:07AM +0200, Roman Zippel wrote:
> Hi,
>
> Jeff Garzik wrote:
>
> > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > suggested other options, but he did attempt to implement them? No.
> > He just implied that people need to step up and do this work for him.
>
> He made his intention very clear, you are interpreting something in his
> action, that simply isn't there.
How can one misinterpret the action of "<this> is my ideology.
this document offends me. I remove it."?
> > Daniel attempted to remove speech he disgreed with from wide
> > distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
> > it is plainly obvious that removing a doc from one of the mostly
> > widely distributed open source projects reduces the doc's distribution
> > dramatically. _That_ is a form of censorship, just like buying out
> > printing presses, to silence them, in the old days. It's still
> > around... just progressively harder to obtain.
>
> Censorship requires the means to enforce it and has Daniel this ability?
> Could we please stop these "censorship" and "ideology" arguments? In
> this context they are simply nonsense.
Ideology was the __sole__ reason for removing the document.
Since Linus uses BK, and the document is there in the first place
to make life easier, Daniel is therefore making life more difficult
because of ideology, and no other reason.
If you want to be really semantic, Daniel's patch was an attempt to
censor, not censorship itself. But when it's a GPL'd document that
I wrote, I'll treat them equally.
> kernel development with bk requires net access
No it doesn't
> 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.
Linus, myself, and others _repeatedly_ say that BitKeeper is _not_
the sole means of submitting patches. Thus actively and repeatedly
disputing "as if there would be no choice."
This policy of supporting GNU patches has been in existence since
time began, and absolutely nothing has changed in that regard.
To imply otherwise is to spread Fear, Uncertainty, and Doubt.
> 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.
How many users here, besides me, have actually done serious patching of
the CVS source? The argument that kernel developers will help develop
an SCM is admirable, but unrealistic IMO. Otherwise, kernel hackers
would have written a BK alternative by now, instead of simply whining.
> 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.
If Linus and others repeatedly claim this is untrue, and repeatedly
prove this by taking GNU patches, your statement is utter fantasy.
Jeff
On Sunday 21 April 2002 18:26, Tigran Aivazian wrote:
> On Sun, 21 Apr 2002, Jeff Garzik wrote:
> > Daniel was trying to dictate what we can and cannot talk about, in the
> > kernel sources. That's offensive.
>
> 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?
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
On Sun, 21 Apr 2002, Skip Ford wrote:
> That's only 1 aspect. The frustrating part is bug reports mailed to the
> list getting a response of "oh, that's fixed in the latest bk tree."
in the pre-bk past i've seen "that's fixed in my tree" with no reference
to how to get "my tree" -- this repeated by many folks, including linus.
for those of you with issues against using bk, you should just pretend
that's what you're reading. you can even respond with "could you make a
snapshot available?" like folks used to. you can even go pick up the new
daily snapshots.
so your frustration is either not a new thing, or has been solved.
-dean
On Sunday 21 April 2002 18:27, Richard Gooch wrote:
> Daniel Phillips writes:
> > On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > > Daniel,
> > >
> > > This is not documentation for bitkeeper but how to use bitkeeper
> > > effectively for kernel development. It happens to be DAMN USEFULL
> > > documentation at that for anyone wanting to use bitkeeper for kernel
> > > development so IMO it fully belongs in the kernel. Just like the
> > > SubmittingPatches document does, too. Or are you going to remove that as well?
> >
> > By that logic, we should also include the lkml FAQ in the kernel
> > tree. Should we?
>
> No. A pointer to the lkml FAQ is sufficient.
Was that a hint? Then certainly, a pointer to the BK documentation would be
sufficient, and save download bandwidth as well.
--
Daniel
Daniel Phillips writes:
> On Sunday 21 April 2002 18:27, Richard Gooch wrote:
> > Daniel Phillips writes:
> > > On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > > > Daniel,
> > > >
> > > > This is not documentation for bitkeeper but how to use bitkeeper
> > > > effectively for kernel development. It happens to be DAMN USEFULL
> > > > documentation at that for anyone wanting to use bitkeeper for kernel
> > > > development so IMO it fully belongs in the kernel. Just like the
> > > > SubmittingPatches document does, too. Or are you going to remove that as well?
> > >
> > > By that logic, we should also include the lkml FAQ in the kernel
> > > tree. Should we?
> >
> > No. A pointer to the lkml FAQ is sufficient.
>
> Was that a hint?
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.
> Then certainly, a pointer to the BK documentation would be
> sufficient, and save download bandwidth as well.
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]
On Sunday 21 April 2002 18:32, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 02:04:07AM +0200, Roman Zippel wrote:
> Since Linus uses BK, and the document is there in the first place
> to make life easier, Daniel is therefore making life more difficult
> because of ideology, and no other reason.
Yup, that's me. No, I don't always check my conscience at the door. If
that were my habit I'd have spent the past three years comfortably
programming big, expensive machines under Windows.
N.B., not implying you're morally bankrupt, no suggestion of that at
all. Still, since you just dumps on all those who prefer to follow
their hearts, you deserve to be publically challenged.
Let's pull back a little from the proselytizing, shall we? I'll modify
my proposal to 'include just a pointer to the bk documentation in the
kernel tree itself'. This should satisfy everybody.
--
Daniel
Hi Anton,
> >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.
>
> Not wrong. BK works fine over http protocol. CVS is another matter which I
> cannot comment on...
Ok, but there are other scenarios where only email is available (often via
mail gateways like softswitch on os/390)...
--jochen
Hi,
> > So you're telling me that what I've been doing over the
> > last months really shouldn't have been possible ?
>
> 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.
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
On Sat, Apr 20, 2002 at 06:46:11PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 18:32, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 02:04:07AM +0200, Roman Zippel wrote:
> > Since Linus uses BK, and the document is there in the first place
> > to make life easier, Daniel is therefore making life more difficult
> > because of ideology, and no other reason.
>
> Yup, that's me. No, I don't always check my conscience at the door. If
> that were my habit I'd have spent the past three years comfortably
> programming big, expensive machines under Windows.
>
> N.B., not implying you're morally bankrupt, no suggestion of that at
> all. Still, since you just dumps on all those who prefer to follow
> their hearts, you deserve to be publically challenged.
Public challenges kick ass. As people here know, I love a good flamewar :)
I follow my heart quite often, so I've no doubt I will be on the other
side of the coin. I get dumped on by vendors for being staunchly GPL
when doing driver development. We all pick our issues. :)
> Let's pull back a little from the proselytizing, shall we? I'll modify
> my proposal to 'include just a pointer to the bk documentation in the
> kernel tree itself'. This should satisfy everybody.
No, it doesn't. It was put into the tree for convenience.
It therefore stands to reason that removing it creates inconvenience.
Further, the only reason to remove it is ideology. i.e. something
other than technical merit. So your proposal is still a no-go.
My advice to you: ignore Documentation/BK-usage, it is apparently
causing you anguish :)
Jeff
On Sun, Apr 21, 2002 at 06:46:07PM +0200, Jochen Friedrich wrote:
> > >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.
> >
> > Not wrong. BK works fine over http protocol. CVS is another matter which I
> > cannot comment on...
>
> Ok, but there are other scenarios where only email is available (often via
> mail gateways like softswitch on os/390)...
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,
At 17:46 21/04/02, Jochen Friedrich wrote:
> > >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.
> >
> > Not wrong. BK works fine over http protocol. CVS is another matter which I
> > cannot comment on...
>
>Ok, but there are other scenarios where only email is available (often via
>mail gateways like softswitch on os/390)...
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/
On Sunday 21 April 2002 01:15, Kenneth Johansson wrote:
> Daniel Phillips wrote:
>
> > 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.
>
> 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.
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
On Sunday 21 April 2002 17:35, you wrote:
> On Sun, Apr 21, 2002 at 03:57:59AM +0100, Ian Molton wrote:
> > Russell King Awoke this dragon, who will now respond:
> >
> > > 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.
> >
> > I dont think Daniel claimed BK was contributing to linux downfall.
>
> Sure he did.
Would you please show me where? At most you'll find a warning we should
be vigilant, that we should be thinking about how to improve the level of
discussion of important patches.
Private patch streams containing important work have always tended to
dissipate the essential strength of the community, in my opinion.
Bitkeeper just makes it easier. That is far from suggesting Linux is
teetering on the brink.
--
Daniel
On Sunday 21 April 2002 18:57, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 06:46:11PM +0200, Daniel Phillips wrote:
> > Let's pull back a little from the proselytizing, shall we? I'll modify
> > my proposal to 'include just a pointer to the bk documentation in the
> > kernel tree itself'. This should satisfy everybody.
>
> No, it doesn't. It was put into the tree for convenience.
How much less convenient is it to click on a link? So much harder that it's
worth pissing off some key developers?
> It therefore stands to reason that removing it creates inconvenience.
> Further, the only reason to remove it is ideology. i.e. something
> other than technical merit. So your proposal is still a no-go.
According to you, yes. I'll leave it on the table.
--
Daniel
Hi Anton,
On Sun, Apr 21, 2002 at 06:05:43PM +0100, Anton Altaparmakov wrote:
> 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.
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
On Sun, Apr 21, 2002 at 12:05:27AM -0400, Alexander Viro wrote:
> "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...
A discussion on _Linus_ licensing would be interesting ;-)
To be pedantic, though, I point out that the BK doc at the center of
this flamewar is GPL'd.
> 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?
hmmm hmmm.
My alternative suggestion, which only applies to development series
kernels, is to spit out pre-patches and releases more frequently.
The releases would be your formal testing points by users, and the
pre-patches would be the sync points for developers, and test points
for developers. i.e. make the current system work as intended ;-)
Maybe write a script for Linus that automates his side of pre-patch
publishing (if it isn't 100% automatic now)? i.e. my guess is that
pre-patching is currently automated maybe 70% or so... This automation
I describe increments the pre-patch number in the makefile, checks
that update into BK, rolls a patch, scp's it to master, and posts the
changelog to linux-kernel. I could roll a demo script that does this,
if people think this is a sane alternative.
IOW, I propose to create a "linuspush" script that replaces his current
"bk push" command. Linus pushes batches of csets out at a time,
make these cset batches the pre-patches...
Jeff, who wouldn't mind snapshots either
On Sat, Apr 20, 2002 at 07:05:40PM +0200, Daniel Phillips wrote:
> 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.
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
Daniel Phillips wrote:
> On Sunday 21 April 2002 18:57, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 06:46:11PM +0200, Daniel Phillips wrote:
> > > Let's pull back a little from the proselytizing, shall we? I'll modify
> > > my proposal to 'include just a pointer to the bk documentation in the
> > > kernel tree itself'. This should satisfy everybody.
> >
> > No, it doesn't. It was put into the tree for convenience.
>
> How much less convenient is it to click on a link? So much harder that it's
> worth pissing off some key developers?
Linus has already explained why he put it into the kernel sources.
And, who are these key developers you are speaking for?
> > It therefore stands to reason that removing it creates inconvenience.
> > Further, the only reason to remove it is ideology. i.e. something
> > other than technical merit. So your proposal is still a no-go.
>
> According to you, yes. I'll leave it on the table.
Linus has already explained he isn't applying your patch.
Jeff
On Sun, Apr 21, 2002 at 06:50:39PM +0200, Jochen Friedrich wrote:
> Hi,
>
> > > So you're telling me that what I've been doing over the
> > > last months really shouldn't have been possible ?
> >
> > 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.
>
> 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 ;-)
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.
http://www.fsmlabs.com http://www.rtlinux.com
On Fri, Apr 19, 2002 at 11:02:04PM +0200, Daniel Phillips wrote:
> > That would actually make the development process MORE open than it was
> > before BK, and might make even non-BK people appreciate BK more simply
> > because there is a real point to it.
>
> Well, it would be more like working in a fishbowl anyway. The part that's
> missing is the discussion. Just looking at the recent traffic... there's
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
> IOW, I propose to create a "linuspush" script that replaces his current
> "bk push" command. Linus pushes batches of csets out at a time,
> make these cset batches the pre-patches...
This is easily doable as a trigger. I'm pretty sure that all you want
is
cat > BitKeeper/triggers/pre-incoming.diffs
#!/bin/sh
bk prs -hr+ -nd:KEY: ChangeSet > BitKeeper/log/save_key
^D
cat > BitKeeper/triggers/post-incoming.diffs
#!/bin/sh
i=0
while test -f BitKeeper/tmp/diffs-$i
do i=`expr $i + 1`
done
bk diffs -C`cat BitKeeper/log/save_key` > BitKeeper/tmp/diffs-$i
^D
chmod +x BitKeeper/triggers/*incoming.diffs
The only reason I don't do this on bkbits.net is that regular style patches
eat a lot more bandwidth than BK patches and we can't afford to offer up
the bandwidth for free.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, Apr 21, 2002 at 10:23:39AM -0700, Larry McVoy wrote:
> > IOW, I propose to create a "linuspush" script that replaces his current
> > "bk push" command. Linus pushes batches of csets out at a time,
> > make these cset batches the pre-patches...
>
> This is easily doable as a trigger. I'm pretty sure that all you want
> is
Not quite -- pre-patches are a one-big-patch, diffed against the most
recently released kernel. Perl could easily parse the linux/Makefile
kernel version and deduce the BK tag (used for diffing) from that.
Finally, I'm not sure that BK can generate these kind of diffs, can it?
One quality of all traditional Linus pre-patches and patches is that
if you have N csets modifying a single file, you see N gnu-style diff
modifications, instead of the single one you would get when generating
the patch via GNU diff.
Also, (assuming Linus wants this, of course) I would want the
'linuspush' script to increment the pre-patch and check in that change,
before pushing.
Jeff
On Sun, Apr 21, 2002 at 01:32:25PM -0400, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 10:23:39AM -0700, Larry McVoy wrote:
> > > IOW, I propose to create a "linuspush" script that replaces his current
> > > "bk push" command. Linus pushes batches of csets out at a time,
> > > make these cset batches the pre-patches...
> >
> > This is easily doable as a trigger. I'm pretty sure that all you want
> > is
>
> Not quite -- pre-patches are a one-big-patch, diffed against the most
> recently released kernel.
That's easier yet.
bk diffs -Cv2.5.8
> One quality of all traditional Linus pre-patches and patches is that
> if you have N csets modifying a single file, you see N gnu-style diff
> modifications, instead of the single one you would get when generating
> the patch via GNU diff.
Did you get that backwards? Do you want to see N diffs on a single
file or do you want one? We can do either, diffs -C does one.
Also, we're planning on making a "push stack", which remembers the set of
csets pushed each time, so you can do
bk undo # remove the last push effects
bk undo # remove the last push effects
..
bk undo # remove the clone effects and destroy the repository
You could use that to generate these patches you want.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, Apr 22, 2002 at 03:16:29AM +1000, CaT wrote:
> On Fri, Apr 19, 2002 at 11:02:04PM +0200, Daniel Phillips wrote:
> > > That would actually make the development process MORE open than it was
> > > before BK, and might make even non-BK people appreciate BK more simply
> > > because there is a real point to it.
> >
> > Well, it would be more like working in a fishbowl anyway. The part that's
> > missing is the discussion. Just looking at the recent traffic... there's
>
> 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
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
On Sun, Apr 21, 2002 at 10:39:23AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 01:32:25PM -0400, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 10:23:39AM -0700, Larry McVoy wrote:
> > > > IOW, I propose to create a "linuspush" script that replaces his current
> > > > "bk push" command. Linus pushes batches of csets out at a time,
> > > > make these cset batches the pre-patches...
> > >
> > > This is easily doable as a trigger. I'm pretty sure that all you want
> > > is
> >
> > Not quite -- pre-patches are a one-big-patch, diffed against the most
> > recently released kernel.
>
> That's easier yet.
>
> bk diffs -Cv2.5.8
>
> > One quality of all traditional Linus pre-patches and patches is that
> > if you have N csets modifying a single file, you see N gnu-style diff
> > modifications, instead of the single one you would get when generating
> > the patch via GNU diff.
>
> Did you get that backwards? Do you want to see N diffs on a single
> file or do you want one? We can do either, diffs -C does one.
Didn't get it backwards, I misunderstood BK.
It sounds like 'bk diffs -C' does what I want.
> Also, we're planning on making a "push stack", which remembers the set of
> csets pushed each time, so you can do
>
> bk undo # remove the last push effects
> bk undo # remove the last push effects
> ..
> bk undo # remove the clone effects and destroy the repository
>
> You could use that to generate these patches you want.
Gnifty... I don't know that I would ever use the multiple-undo stack,
but being able to see a single GNU-style patch for set of "what I just
downloaded in the last bk pull" would definitely come in handy.
(substitute "last bk pull" with "a bk pull N pulls ago" if you like)
Jeff
On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> Daniel Phillips wrote:
> > On Sunday 21 April 2002 18:57, Jeff Garzik wrote:
> > > On Sat, Apr 20, 2002 at 06:46:11PM +0200, Daniel Phillips wrote:
> > > > Let's pull back a little from the proselytizing, shall we? I'll modify
> > > > my proposal to 'include just a pointer to the bk documentation in the
> > > > kernel tree itself'. This should satisfy everybody.
> > >
> > > No, it doesn't. It was put into the tree for convenience.
> >
> > How much less convenient is it to click on a link? So much harder that it's
> > worth pissing off some key developers?
>
> Linus has already explained why he put it into the kernel sources.
So far the only argument I've seen is: it's convenient. Did I miss something?
The convenience argument is bogus. A url is just as convenient, especially as
Larry has offered an appropriate home, one which will by definition continue
to exist as long as Bitkeeper stays alive. Plus, the url saves download
bandwidth. A compelling argument I'd say.
> And, who are these key developers you are speaking for?
They can introduce themselves if they wish. Or you can ask around.
--
Daniel
> Gnifty... I don't know that I would ever use the multiple-undo stack,
> but being able to see a single GNU-style patch for set of "what I just
> downloaded in the last bk pull" would definitely come in handy.
We have a graphical version of that already, sort of, do a "bk csets"
after doing a pull.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
On Sun, Apr 21, 2002 at 10:47:25AM -0700, Larry McVoy wrote:
> > Gnifty... I don't know that I would ever use the multiple-undo stack,
> > but being able to see a single GNU-style patch for set of "what I just
> > downloaded in the last bk pull" would definitely come in handy.
>
> We have a graphical version of that already, sort of, do a "bk csets"
> after doing a pull.
I know, but graphical is useless to me...
Give me text/plain GNU-style patches, that I can spit out without
requiring X. :)
Jeff
On Sunday 21 April 2002 19:40, Larry McVoy wrote:
> On Mon, Apr 22, 2002 at 03:16:29AM +1000, CaT wrote:
> > On Fri, Apr 19, 2002 at 11:02:04PM +0200, Daniel Phillips wrote:
> > > > That would actually make the development process MORE open than it was
> > > > before BK, and might make even non-BK people appreciate BK more simply
> > > > because there is a real point to it.
> > >
> > > Well, it would be more like working in a fishbowl anyway. The part that's
> > > missing is the discussion. Just looking at the recent traffic... there's
> >
> > 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
>
> I can certainly do this for the tree on bkbits.net, i.e., it emails the
> lk list when it gets new work. Linus?
Horse, barn. We need a solution that works before the patch gets applied.
Perhaps that's what you're talking about?
--
Daniel
On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > Daniel Phillips wrote:
> > > How much less convenient is it to click on a link? So much harder that it's
> > > worth pissing off some key developers?
> > Linus has already explained why he put it into the kernel sources.
> So far the only argument I've seen is: it's convenient. Did I miss something?
> The convenience argument is bogus. A url is just as convenient,
If you say this, then you either missed, or are willfully ignoring,
what Linus said. Search for the string "helsinki.fi".
> > And, who are these key developers you are speaking for?
>
> They can introduce themselves if they wish. Or you can ask around.
I am asking. My previous post was asking. Who are you speaking for?
Jeff
On Sun, Apr 21, 2002 at 01:48:51PM -0400, Jeff Garzik wrote:
> Can you get the bkbits.net interface to spit out text/plain GNU-style
> patches?
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
On Sun, Apr 21, 2002 at 01:49:55PM -0400, Jeff Garzik wrote:
> I know, but graphical is useless to me...
> Give me text/plain GNU-style patches, that I can spit out without
> requiring X. :)
I did. Install those triggers and you've got it. Sorry to sound
uncooperative but the trigger mechanism is there to handle this, and
email notification, and automatic mirroring, and ...
So the mechanism is there, you can make the mechanism do whatever you
want. If you check in the triggers, they will make their way into each
tree. So do the first one and write yourself a shell script to use it.
I wouldn't check in the second one.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Apr 20, 2002 at 07:50:14PM +0200, Daniel Phillips wrote:
> > > 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
> >
> > I can certainly do this for the tree on bkbits.net, i.e., it emails the
> > lk list when it gets new work. Linus?
>
> Horse, barn. We need a solution that works before the patch gets applied.
>
> Perhaps that's what you're talking about?
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
On Sun, Apr 21, 2002 at 10:54:37AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 01:48:51PM -0400, Jeff Garzik wrote:
> > Can you get the bkbits.net interface to spit out text/plain GNU-style
> > patches?
>
> Not on bkbits.net. It eats up too much bandwidth.
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.
> Otherwise you are getting a cset at a
> time and that's a bit too fine grained, at least I think it is.
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
> I am asking. My previous post was asking. Who are you speaking for?
"Answer zee question, old man!"
--
Daniel
On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> Plus, the url saves download
> bandwidth. A compelling argument I'd say.
The docs are all of 12K, I just went and looked. If you care about
bandwidth, you'd be arguing in favor of BK, it saves tons of bandwidth
compared to diff and patch.
In fact, your path to remove them proves that. If you cared about bandwidth,
you would have posted a BK patch to do it. :-)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, Apr 21, 2002 at 10:57:06AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 01:49:55PM -0400, Jeff Garzik wrote:
> > I know, but graphical is useless to me...
> > Give me text/plain GNU-style patches, that I can spit out without
> > requiring X. :)
>
> I did. Install those triggers and you've got it. Sorry to sound
> uncooperative but the trigger mechanism is there to handle this, and
> email notification, and automatic mirroring, and ...
(did you miss that we're off on a tangent? :))
If we are talking about 'bk diffs -C' for Linus, agreed.
But you started talking about the nifty feature of seeing what you
downloaded in the last 'bk pull'.
Triggers are completely useless for "show me what the next-to-last
'bk pull' downloaded, in GNU patch style." It's unrealistic to assume
that everybody is gonna set up triggers and their own cset GNU patch
archive, just to provide themselves with this capability. Especally
when (IMO) bk can generate that stuff on the fly.
If BK knows a single basic unit of information -- the list of csets
downloaded in each 'bk pull' -- then it should be able to generate
patches for those csets. Or at the very least, have a bk command
that spits out that list of csets, and user-written scripts take it
from there.
Jeff
On Mon, Apr 22, 2002 at 03:54:04AM +1000, CaT wrote:
> 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 ;)
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
> 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 ;)
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
On Sun, 21 Apr 2002, Jochen Friedrich wrote:
> Hi,
>
> > > We dont allow proprietary modules in the kernel, why should docs be any
> > > different?
> >
> > The documentation being discussed is not proprietary, it only talks about a non
> > essential proprietary tool used now by lots of kernel hackers.
>
> So would Linus accept a document on how to run Linux/390 on hercules (yet
> another proprietary emulator)? This also was a FAQ on the linux-390
> mailing list until the documentation is available on the hercules home
> page...
<Puzzled> I thought hercules was an open source project... There are some
prioriatery 390 emulators (UMX, Flex) but not hercules.
>
> Developing kernel stuff on 390 without emulator can be much fun as host
> operators tend to get very pissed if the IPL ratio comes near to 1/min ;-)
>
> --jochen
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sunday 21 April 2002 19:55, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > > Daniel Phillips wrote:
> > > > How much less convenient is it to click on a link? So much harder that it's
> > > > worth pissing off some key developers?
>
> > > Linus has already explained why he put it into the kernel sources.
>
> > So far the only argument I've seen is: it's convenient. Did I miss something?
> > The convenience argument is bogus. A url is just as convenient,
>
> If you say this, then you either missed, or are willfully ignoring,
> what Linus said. Search for the string "helsinki.fi".
Linus said:
> As to why the docs are in the kernel sources rather than on any web-sites:
> it's simply because I don't even _have_ a web page of my own (I've long
> since forgotten the password to my old helsinki.fi account ;),
Larry has offered to host it, so Linus's argument is answered.
--
Daniel
On Sunday 21 April 2002 20:08, Larry McVoy wrote:
> On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > Plus, the url saves download
> > bandwidth. A compelling argument I'd say.
>
> The docs are all of 12K, I just went and looked. If you care about
> bandwidth, you'd be arguing in favor of BK, it saves tons of bandwidth
> compared to diff and patch.
All you said is 'it doesn't waste *that* much bandwidth'. Remember, this is
the place we spend days arguing over a cycle or two.
--
Daniel
On Sun, Apr 21, 2002 at 02:07:53PM -0400, Jeff Garzik wrote:
> Triggers are completely useless for "show me what the next-to-last
> 'bk pull' downloaded, in GNU patch style."
All you need to do is save the starting and ending cset revs as keys,
and then send those into bk export -tpatch. So a trigger which saved
top of trunk on a stack is all you need, the rest is a tiny amount of
perl/shell. Write it, send it to me, if people like it, we'll roll it
into the mainline release.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Apr 20, 2002 at 08:13:48PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 19:55, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > > On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > > > Daniel Phillips wrote:
> > > > > How much less convenient is it to click on a link? So much harder that it's
> > > > > worth pissing off some key developers?
> >
> > > > Linus has already explained why he put it into the kernel sources.
> >
> > > So far the only argument I've seen is: it's convenient. Did I miss something?
> > > The convenience argument is bogus. A url is just as convenient,
> >
> > If you say this, then you either missed, or are willfully ignoring,
> > what Linus said. Search for the string "helsinki.fi".
>
> Linus said:
>
> > As to why the docs are in the kernel sources rather than on any web-sites:
> > it's simply because I don't even _have_ a web page of my own (I've long
> > since forgotten the password to my old helsinki.fi account ;),
>
> Larry has offered to host it, so Linus's argument is answered.
These are docs-about-Linus, not docs-about-Larry.
Do you propose to move SubmittingPatches and all info related to CVS, to
Larry's web site?
If not... (see the last line of Linus's first response in this thread)
Jeff
Em Sun, Apr 21, 2002 at 11:11:52AM -0700, John Alvord escreveu:
> On Sun, 21 Apr 2002, Jochen Friedrich wrote:
> > > > We dont allow proprietary modules in the kernel, why should docs be any
> > > > different?
> > >
> > > The documentation being discussed is not proprietary, it only talks about a non
> > > essential proprietary tool used now by lots of kernel hackers.
> >
> > So would Linus accept a document on how to run Linux/390 on hercules (yet
> > another proprietary emulator)? This also was a FAQ on the linux-390
> > mailing list until the documentation is available on the hercules home
> > page...
> <Puzzled> I thought hercules was an open source project... There are some
> prioriatery 390 emulators (UMX, Flex) but not hercules.
As I said, its QPLed, so non-proprietary but subject to flamefest, but lets
stick (not me, thanks) to the regular bk ones ;)
- Arnaldo
On Sun, Apr 21, 2002 at 01:59:55PM -0400, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 10:54:37AM -0700, Larry McVoy wrote:
> > On Sun, Apr 21, 2002 at 01:48:51PM -0400, Jeff Garzik wrote:
> > > Can you get the bkbits.net interface to spit out text/plain GNU-style
> > > patches?
> >
> > Not on bkbits.net. It eats up too much bandwidth.
>
> Your bkbits.net web interface _already_ spits out HTML-ized patches.
> It _reduces_ bandwidth to spit them out as text/plain.
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
On Sun, Apr 21, 2002 at 11:11:34AM -0700, Larry McVoy wrote:
> 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.
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
> > As to why the docs are in the kernel sources rather than on any web-sites:
> > it's simply because I don't even _have_ a web page of my own (I've long
> > since forgotten the password to my old helsinki.fi account ;),
>
> Larry has offered to host it, so Linus's argument is answered.
Larry hereby retracts his offer until you back up your claims and answer
the questions you have been asked. You've made one unsubstantiated
claim after another and when challenged, you tell the challenger to do
the legwork to support your unsubstantiated claim.
If you think I'm going to aid in your silliness, think again.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, Apr 21, 2002 at 02:20:30PM -0400, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 11:11:34AM -0700, Larry McVoy wrote:
> > 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.
>
> Can you be convinced to post a sample trigger doing this?
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
On Sun, Apr 21, 2002 at 11:14:50AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 02:07:53PM -0400, Jeff Garzik wrote:
> > Triggers are completely useless for "show me what the next-to-last
> > 'bk pull' downloaded, in GNU patch style."
> All you need to do is save the starting and ending cset revs as keys,
> and then send those into bk export -tpatch. So a trigger which saved
> top of trunk on a stack is all you need, the rest is a tiny amount of
> perl/shell. Write it, send it to me, if people like it, we'll roll it
> into the mainline release.
In order to implement multiple 'bk undo' stack as you described, you
need to store or deduce that info anyway. If I wrote it, wouldn't I be
duplicating work (or doing work for you)?
Jeff
On Sunday 21 April 2002 20:15, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 08:13:48PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 19:55, Jeff Garzik wrote:
> > > On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > > > On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > > > > Daniel Phillips wrote:
> > > > > > How much less convenient is it to click on a link? So much harder that it's
> > > > > > worth pissing off some key developers?
> > >
> > > > > Linus has already explained why he put it into the kernel sources.
> > >
> > > > So far the only argument I've seen is: it's convenient. Did I miss something?
> > > > The convenience argument is bogus. A url is just as convenient,
> > >
> > > If you say this, then you either missed, or are willfully ignoring,
> > > what Linus said. Search for the string "helsinki.fi".
> >
> > Linus said:
> >
> > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > it's simply because I don't even _have_ a web page of my own (I've long
> > > since forgotten the password to my old helsinki.fi account ;),
> >
> > Larry has offered to host it, so Linus's argument is answered.
>
> These are docs-about-Linus, not docs-about-Larry.
>
> Do you propose to move SubmittingPatches and all info related to CVS, to
> Larry's web site?
Which part of 'Larry offered to host it' was not completely clear?
CVS does not have the license issues. Red herring.
--
Daniel
On Mon, 22 Apr 2002, CaT wrote:
> 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
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
On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > it's simply because I don't even _have_ a web page of my own (I've long
> > > since forgotten the password to my old helsinki.fi account ;),
> >
> > Larry has offered to host it, so Linus's argument is answered.
>
> Larry hereby retracts his offer until you back up your claims and answer
> the questions you have been asked. You've made one unsubstantiated
> claim after another and when challenged, you tell the challenger to do
> the legwork to support your unsubstantiated claim.
So the offer was not in good faith.
--
Daniel
On Sat, Apr 20, 2002 at 08:23:49PM +0200, Daniel Phillips wrote:
> 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.
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
On Sun, Apr 21, 2002 at 02:24:47PM -0400, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 11:14:50AM -0700, Larry McVoy wrote:
> > On Sun, Apr 21, 2002 at 02:07:53PM -0400, Jeff Garzik wrote:
> > > Triggers are completely useless for "show me what the next-to-last
> > > 'bk pull' downloaded, in GNU patch style."
>
> > All you need to do is save the starting and ending cset revs as keys,
> > and then send those into bk export -tpatch. So a trigger which saved
> > top of trunk on a stack is all you need, the rest is a tiny amount of
> > perl/shell. Write it, send it to me, if people like it, we'll roll it
> > into the mainline release.
>
> In order to implement multiple 'bk undo' stack as you described, you
> need to store or deduce that info anyway. If I wrote it, wouldn't I be
> duplicating work (or doing work for you)?
Perhaps. You'd also be getting your needs met on your schedule, not mine.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sunday 21 April 2002 20:12, Jeff Garzik wrote:
> On Mon, Apr 22, 2002 at 03:54:04AM +1000, CaT wrote:
> > 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 ;)
>
> 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.
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.
> Very similar to the way GNU patches are handled, strangely enough ;-)
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
On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > since forgotten the password to my old helsinki.fi account ;),
> > >
> > > Larry has offered to host it, so Linus's argument is answered.
> >
> > Larry hereby retracts his offer until you back up your claims and answer
> > the questions you have been asked. You've made one unsubstantiated
> > claim after another and when challenged, you tell the challenger to do
> > the legwork to support your unsubstantiated claim.
>
> So the offer was not in good faith.
Like I said, Daniel, put up or shut up. Would you like me to go through
the thread and come up with a list of claims you have made, been challenged
on, and refuse to substantiate?
We can discuss the good-faith issue *after* you answer the questions.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> > Larry hereby retracts his offer until you back up your claims and answer
> > the questions you have been asked. You've made one unsubstantiated
> > claim after another and when challenged, you tell the challenger to do
> > the legwork to support your unsubstantiated claim.
>
> So the offer was not in good faith.
Daniel: I thought better of you.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
On Sat, 20 Apr 2002, Rob Landley wrote:
>
> The well-defined resync points are the 2.5.N releases. If -pre goes away,
> then the dot-releases might need to come a little closer together, that's all.
I agree.
I've told myself that I shouldn't have done "-preX" releases at all in
2.5.x - the "real" numbers have become diluted by them, and I suspect the
-pre's are really just because I got used to making them during the
over-long 2.4.x time.
For development stuff, I think I personally would rather have dailies
together with a higher frequency of "real" releases. But as it is now
(because it isn't automated), the dailies would be a lot of work..
Linus
On Sat, Apr 20, 2002 at 08:26:58PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 20:15, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 08:13:48PM +0200, Daniel Phillips wrote:
> > > Linus said:
> > >
> > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > since forgotten the password to my old helsinki.fi account ;),
> > >
> > > Larry has offered to host it, so Linus's argument is answered.
> >
> > These are docs-about-Linus, not docs-about-Larry.
> >
> > Do you propose to move SubmittingPatches and all info related to CVS, to
> > Larry's web site?
>
> Which part of 'Larry offered to host it' was not completely clear?
>
> CVS does not have the license issues. Red herring.
No, this is, to me, _the_ issue. And something you keep ignoring.
And proving that you ignored the point of Linus's first post in
this thread.
We have docs describing how kernel developers should merge with Linus.
In your opinion, if those docs describe closed source software,
they should be treated differently than other docs. Regardless of
relevance.
They _are_ relevant, everyone admits that. Therefore treating them
differently only introduces additional barriers and violates the
Principle of Least Surprise.
You are, in effect, trying to disallow politically incorrect speech
from the kernel sources.
Jeff
On Sunday 21 April 2002 20:36, Larry McVoy wrote:
> On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > > since forgotten the password to my old helsinki.fi account ;),
> > > >
> > > > Larry has offered to host it, so Linus's argument is answered.
> > >
> > > Larry hereby retracts his offer until you back up your claims and answer
> > > the questions you have been asked. You've made one unsubstantiated
> > > claim after another and when challenged, you tell the challenger to do
> > > the legwork to support your unsubstantiated claim.
> >
> > So the offer was not in good faith.
>
> Like I said, Daniel, put up or shut up. Would you like me to go through
> the thread and come up with a list of claims you have made, been challenged
> on, and refuse to substantiate?
Larry, you just lathered on a bunch of new conditions of dubious merit. I
understand by this that you had no real intention of following through on
your offer because you thought that it would never get close to becoming
reality.
> We can discuss the good-faith issue *after* you answer the questions.
Riiiiight. I have at least forwarded your demands to those who have
expressed their positions to me privately. If you think I'm going to
violate their confidence on your whim, you can think again.
--
Daniel
On Sun, 21 Apr 2002, Larry McVoy wrote:
>
> I can certainly do this for the tree on bkbits.net, i.e., it emails the
> lk list when it gets new work. Linus?
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 Sunday 21 April 2002 20:30, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 08:23:49PM +0200, Daniel Phillips wrote:
> > 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.
>
> 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)
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
On Sat, 20 Apr 2002, Daniel Phillips wrote:
> Riiiiight. I have at least forwarded your demands to those who have
> expressed their positions to me privately. If you think I'm going to
> violate their confidence on your whim, you can think again.
so then you're having private discussions in email, and one of your
complaints is about other private discussions in email?
On Sat, 20 Apr 2002, Daniel Phillips wrote:
> All you said is 'it doesn't waste *that* much bandwidth'. Remember, this is
> the place we spend days arguing over a cycle or two.
this bk thread alone has so far consumed 597023 bytes just for the message
bodies... plus who knows how many bytes for TCP/IP headers, SMTP overhead,
and DNS overhead. that's uncompressed, and multiplied by the, hmm,
approximately 2000 subscribers to l-k plus the dozen or two web archives
of l-k?
what was that you were saying about wasting bandwidth? if you cared at
all about bandwidth you might want to consider not replying.
personally i probably wouldn't be so interested in bk if it weren't for
all the zealots telling me it's something i shouldn't even consider using.
your approach is about as effective as the war on drugs, or minimum
alcohol consumption age limits. tell what i can't do and i'm damn well
going to go investigate what it is that's supposedly so bad for me.
thanks to all of you for pointing me in the direction of a tool which
looks to be a huge step forward in SCM. i believe "paradigm shift" would
be an apt term for bk.
-dean
On Sat, Apr 20, 2002 at 08:46:40PM +0200, Daniel Phillips wrote:
> > > > > Larry has offered to host it, so Linus's argument is answered.
> > > >
> > > > Larry hereby retracts his offer until you back up your claims and answer
> > > > the questions you have been asked. You've made one unsubstantiated
> > > > claim after another and when challenged, you tell the challenger to do
> > > > the legwork to support your unsubstantiated claim.
> > >
> > > So the offer was not in good faith.
> >
> > Like I said, Daniel, put up or shut up. Would you like me to go through
> > the thread and come up with a list of claims you have made, been challenged
> > on, and refuse to substantiate?
>
> Larry, you just lathered on a bunch of new conditions of dubious merit. I
> understand by this that you had no real intention of following through on
> your offer because you thought that it would never get close to becoming
> reality.
Larry hereby retracts his offer until you back up your claims and answer
the questions you have been asked. You've made one unsubstantiated
claim after another and when challenged, you tell the challenger to do
the legwork to support your unsubstantiated claim.
(follow up again, get the same response, cut and paste is easy).
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
dean gaudet wrote:
>
> On Sat, 20 Apr 2002, Daniel Phillips wrote:
>
> > Riiiiight. I have at least forwarded your demands to those who have
> > expressed their positions to me privately. If you think I'm going to
> > violate their confidence on your whim, you can think again.
>
> so then you're having private discussions in email, and one of your
> complaints is about other private discussions in email?
>
The reason why people do not express their disquiet is very plain - any
time anyone dares comes out, they promptly get their head kicked in.
Guys, this problem is permanent, and it's not going away.
Larry has stated that kernel's use of bitkeeper is not providing
collateral sales, and nor was it intended for that. Fair enough.
But it's inevitable that, in some people's eyes, kernel's very
public use of bitkeeper be viewed as promotion of bitmover's
product, and as endorsement of bitmover's licensing innovations.
Some people don't like this, and never will. I'm tempted here to
say "get over it". This disagreement is a permanent part of the
kernel landscape.
Linus took the work of others and used it in a way which they did
not expect, without their permission, and contrary to their wishes.
He knew what he was doing, and he knew that some wouldn't like it.
If he had chosen any other path, he'd be juggling ascii diffs
until the end of time.
My take on Daniel's patch is that it is addressing the symptoms,
not the problem. And the problem is unsolveable. The differences
of opinion are irreconcilable. Both sides are populated by
perfectly sensible people with perfectly legitimate points of view.
So. Life goes on. We will have regular bitkeeper flamewars, and
that's a good thing - it reminds everyone that there are different
opinions and different work practices which need to be accommodated.
Oh. And the problem of stealth patches is a human one, not a tool
one. Tree owners should prefer to drop unreviewed patches. Not just
because said patches may have bugs which they miss. Not just because
having others check the work lightens their workload. Not just because
others may have other, different implementations in the works. But
also because it keeps everyone informed as to what's going on, and
generally makes for a better development team.
It would help to avoid, say, the situation where random fs maintainer
"A" is amazed to discover one day that a patch from random VFS maintainer
"B" had caused said filesystem to be doing a surprise "up" on a non-downed
semaphore. Not that this could ever happen.
-
Russell King wrote:
> On Sun, Apr 21, 2002 at 12:40:11AM -0400, Skip Ford wrote:
> > That's only 1 aspect. The frustrating part is bug reports mailed to the
> > list getting a response of "oh, that's fixed in the latest bk tree."
> >
> > Daily snapshots would be great.
>
> We have hourly snapshots, thanks to the work David Woodhouse and
> Rik van Riel did at a moments notice. Does this satisfy your
> concerns above?
It does as long as those hourly snapshots are the official kernel. If
the snapshots are different than what's available at kernel.org then the
problem is still there.
We need to have more frequent releases so the current kernel is
available to everyone, including non-bk users. It doesn't matter
to me what it's called (snapshots, -pre, regular releases 2.5.X).
--
Skip
On Saturday 20 April 2002 11:44 am, Daniel Phillips wrote:
> Here's my wrapup...
>
> On Sunday 21 April 2002 03:41, Rob Landley wrote:
> > On Friday 19 April 2002 06:34 pm, Daniel Phillips wrote:
> > > I'm not arguing that BK is not a good way to do the grunt maintainance
> > > work. I think it is, and that's great. Heck, I'm not arguing against
> > > Bitkeeper *at all*. I'm arguing against building the bitkeeper
> > > documentation into the kernel tree, giving the impression that
> > > Bitkeeper is *required* for submitting patches.
> >
> > I'm under the impression that Linus specifically asked for that
> > documentation, because BK is a tool he used that he was getting flooded
> > with questions about.
>
> 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.
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.
> 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.
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?
:)
> Any argument that these people exist, or that they are irritated?
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.
> By the way, I'm not one of them, and I'm not going to do any further
> speaking for them.
Why have you done this much?
> 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.
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...)
> 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.
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.
> 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.
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...
> It used to be that every major change would start with an [RFC].
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...
> 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.
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.
> 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.
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...)
> If it's a real phenomenon then the question is, what if anything needs to
> be done about it?
That sentence belongs in congress, not on a technical list...
> 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.
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...)
> 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.
There Is No Cabal (tm).
> All that said, I have to observe that the current process is *not broken*
Use a bigger hammer. :)
> > It seems like the BitKeeper documentation belongs together with the other
> > submitting patches documentation, and should be moved to the directory
> > "Documentation/Linus".
>
> 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 ;-)
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... :)
> > And this differs from emailing him a patch without cc'ing linux-kernel in
> > what way?
>
> Depending on the nature of the patch, both are wrong.
Memo to self: emailing a patch to Linus is wrong. Check.
> 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.
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".)
> > Either you trust Linus's judgment 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?
>
> 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.
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...
> > And AFTER the merge, you still get to flame all you want.
>
> No no no. Think about what you just said. Barn. Door. Horse. Gone.
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...
> > 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, 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.
You mean like this thread?
> > 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 unsurprising.
>
> 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.
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
Daniel Phillips wrote:
> Horse, barn. We need a solution that works before the patch gets applied.
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]>
Jeff Garzik Awoke this dragon, who will now respond:
> If Linus had applied your patch, there would be a lag time during which
> the doc would have no home at all.
He merely provided the patch. he didnt try to force it through in a hurry,
which left plenty of time for relocation in the meantime.
On Sun, Apr 21, 2002 at 01:22:37PM -0700, Andrew Morton wrote:
> The reason why people do not express their disquiet is very plain - any
> time anyone dares comes out, they promptly get their head kicked in.
In the "let's be fair" department, it's obvious that there is enough
head kicking to go around on all sides, right? No answer needed...
> So. Life goes on. We will have regular bitkeeper flamewars, and
> that's a good thing - it reminds everyone that there are different
> opinions and different work practices which need to be accommodated.
If Daniel had started out this thread with
Hey, I've noticed that the BK patches aren't getting as much review
or notification on the lk list, is there something we can do about
that?
He would have gotten a useful answer in a few minutes, and we would have
moved on.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, 21 Apr 2002 00:05:27 -0400 (EDT)
Alexander Viro <[email protected]> wrote:
> 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.
"me too". Actually, I found it easier to get the Trivial patches in, and
about the same for per-cpu and futex patches. I don't bk.
When patches didn't go in, it's more due to Mingo Theorum[1] than being
non-bk. And that's a Good Thing for calibrating my coding tastes upwards.
Rusty.
[1] Message-ID: <[email protected]>
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
Hi,
Jeff Garzik wrote:
> > He made his intention very clear, you are interpreting something in
his
> > action, that simply isn't there.
>
> How can one misinterpret the action of "<this> is my ideology.
> this document offends me. I remove it."?
If "ideology" means to state a different opinion, then I'm guilty too,
I'm an ideologist and proud of it. Please get your terminology straight
before you make such accusations.
> If you want to be really semantic, Daniel's patch was an attempt to
> censor, not censorship itself. But when it's a GPL'd document that
> I wrote, I'll treat them equally.
One doesn't "attempt to censor" by publicly announcing it. Get real,
this is getting ridiculous.
> > kernel development with bk requires net access
>
> No it doesn't
What you describe in the document does.
> > 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.
>
> Linus, myself, and others _repeatedly_ say that BitKeeper is _not_
> the sole means of submitting patches. Thus actively and repeatedly
> disputing "as if there would be no choice."
I was talking about SCM systems. The current situations favours bk and
you currently doing your best to piss anyone off, who cares about free
software.
> Otherwise, kernel hackers
> would have written a BK alternative by now, instead of simply whining.
Nobody is whining here. I accept Linus' decision for bk and I understand
why. I'm not entirely happy about it, but there is currently not much I
can do about it and it's still better than using no SCM system at all.
> > 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.
>
> If Linus and others repeatedly claim this is untrue, and repeatedly
> prove this by taking GNU patches, your statement is utter fantasy.
Again, I was more talking about SCM systems here. I don't care, what
tools you are using, but we should avoid giving the impression, that
Joe Hacker should use bk, because Linus is using it.
You and Linus may only care about hacking for fun, but other people also
care about the freedom to hack. Recent developments in the US and Europe
should have made clear that this is necessary. Nobody wants to make Larry
the bad guy here, but is on the other hand a little respect really too
much to ask for, when people critize the usage of bk, that they not
automatically get branded as bunch of fanatics with some strange
"ideology"?
Could we at least add something like below as a compromise (it's only a
suggestion and not an attempt to brainwash or something like that). It's
not enough to assume that people know that they have a choice, we have to
tell them that and besides of some statements on the LKML, I can't find it
officially documented anywhere:
Unlike Linux itself bk is not free software, but it was choosen by Linus
and other developers because of it qualities as distributed source code
management system. Before you start using bk you should have carefully
read http://www.bitkeeper.com/Sales.Licensing.Free.html and decided for
yourself whether these conditions are acceptable. Alternatively the latest
kernel sources will also always be available at http://www.kernel.org. If you
require a source code management system, you might also consider one of
the freely available systems.
bye, Roman
On Sunday 21 April 2002 06:13, Linus Torvalds wrote:
> On Sun, 21 Apr 2002, Alexander Viro wrote:
> > "Linus documentation".
>
> In fact, we might as well have a whole subdirectory on "Managing Linus",
> which some people have become very good at.
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?
> 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.
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.
> 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.
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.
> 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"? ;)
I pray for a truly free Bitkeeper. Shows you what damn good praying does ;-)
--
Daniel
On Sunday 21 April 2002 06:20, David S. Miller wrote:
> From: Ian Molton <[email protected]>
> Date: Sun, 21 Apr 2002 05:31:43 +0100
>
> Alexander Viro Awoke this dragon, who will now respond:
>
> > 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 orSure, except no-one cares about this point.
>
> Sure, except no-one cares about this point.
>
> the documentation is the 'sticky wicket'...
>
> Incorrect. The argument for the documentation was that it along with
> other things wrt. BK create some "barrier to entry" for Linux kernel
> development and almost force someone to use BK.
It was my argument, so I'm qualified to say what it was. Ian Molton is correct,
your interpretation is strictly secondary.
--
Daniel
On Sunday 21 April 2002 10:31, Russell King wrote:
> On Sun, Apr 21, 2002 at 12:40:11AM -0400, Skip Ford wrote:
> > That's only 1 aspect. The frustrating part is bug reports mailed to the
> > list getting a response of "oh, that's fixed in the latest bk tree."
> >
> > That's happened a dozen times in the last week...no wonder non-bk users
> > feel out of the loop. I've been staring at the code for a lot of years
> > and it's finally just starting to make sense to me, now by the time I see
> > it the core hackers have moved on to something else.
> >
> > Daily snapshots would be great.
>
> We have hourly snapshots, thanks to the work David Woodhouse and
> Rik van Riel did at a moments notice. Does this satisfy your
> concerns above?
Interesting. How does that work, exactly?
--
Daniel
On Sun, Apr 21, 2002 at 03:05:27PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 10:31, Russell King wrote:
> > We have hourly snapshots, thanks to the work David Woodhouse and
> > Rik van Riel did at a moments notice. Does this satisfy your
> > concerns above?
>
> Interesting. How does that work, exactly?
If you want details of this, go grab the publically accessible
scripts that these guys worked on. Just don't ask me.
I'm no longer interested in this BK anti BK crap. Take it elsewhere.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Fellow Linux Hackers,
Saturday I downloaded kernel 2.5.8. After compiling it last night, I have to
say that I am quite pleased with how it works on my computer. I don't care
what SCM is used, as long as the kernel quality continues to be this good.
Matthew.
On Sunday 21 April 2002 20:36, Larry McVoy wrote:
> On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > > since forgotten the password to my old helsinki.fi account ;),
> > > >
> > > > Larry has offered to host it, so Linus's argument is answered.
> > >
> > > Larry hereby retracts his offer until you back up your claims and answer
> > > the questions you have been asked. You've made one unsubstantiated
> > > claim after another and when challenged, you tell the challenger to do
> > > the legwork to support your unsubstantiated claim.
> >
> > So the offer was not in good faith.
>
> Like I said, Daniel, put up or shut up. Would you like me to go through
> the thread and come up with a list of claims you have made, been challenged
> on, and refuse to substantiate?
Yes.
--
Daniel
On Sunday 21 April 2002 21:06, dean gaudet wrote:
> personally i probably wouldn't be so interested in bk if it weren't for
> all the zealots telling me it's something i shouldn't even consider using.
> your approach is about as effective as the war on drugs, or minimum
> alcohol consumption age limits. tell what i can't do and i'm damn well
> going to go investigate what it is that's supposedly so bad for me.
>
> thanks to all of you for pointing me in the direction of a tool which
> looks to be a huge step forward in SCM. i believe "paradigm shift" would
> be an apt term for bk.
You seem to think I'm against Bitkeeper, or its use, or that I think
Bitkeeper isn't helping linux. You're wrong. I am against carrying what
*appears* to be a big advertisement for Bitkeeper itself in the Linux
source tree. This I see as akin to putting up a commercial billboard in a
public park. Would you be comfortable with that?
If my comments have caused increased interest in Bitkeeper and spiked up
Larry's downloads, I am glad. Now everybody is happy except a number of
those whose involvement with Linux is based on some kind of philosophical
belief in the freeness of software (or at least in the freeness of Linux)
and who have been on the butt end of numerous insults in this thread,
your insult above ("zealots") being a good example.
I have suggested carrying a URL instead. Is it reasonable? Who is being
extreme here?
Furthermore, who is making the vicious attacks, and why?
--
Daniel
On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> 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.
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
On Monday 22 April 2002 17:44, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > 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.
>
> 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.
So you have no problem with moving them to a website, leaving a url in
SubmittingPatches?
--
Daniel
On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > The existence (or non-existence) of the docs has absolutely no marketing
> > value to BK.
>
> So you have no problem with moving them to a website, leaving a url in
> SubmittingPatches?
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.2/Documentation/BK-usage/bk-kernel-howto.txt Fri Mar 15 09:08:54 2002
+++ edited/bk-kernel-howto.txt Mon Apr 22 09:04:26 2002
@@ -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
On Monday 22 April 2002 18:10, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > > The existence (or non-existence) of the docs has absolutely no marketing
> > > value to BK.
> >
> > So you have no problem with moving them to a website, leaving a url in
> > SubmittingPatches?
>
> It's not my call to make.
I know that. I was wondering if *you personally* would have any objection.
> Take it up with the people who own the tree.
That's all of us, last I heard. Administrating it is, of course, another story.
--
Daniel
(Linus removed from CC)
On Mon, Apr 22, 2002 at 02:06:05PM +0200, Roman Zippel wrote:
> Hi,
>
> Jeff Garzik wrote:
>
> > > He made his intention very clear, you are interpreting something in
> his
> > > action, that simply isn't there.
> >
> > How can one misinterpret the action of "<this> is my ideology.
> > this document offends me. I remove it."?
>
> If "ideology" means to state a different opinion, then I'm guilty too,
> I'm an ideologist and proud of it. Please get your terminology straight
> before you make such accusations.
I have my terminology straight. Everyone have some amount of core
ideology, I imagine. I was illustrating cause and effect, with the
above statement.
Ideology is a good thing. If you believe in something, fight for it.
But... if you believe that all documents in the kernel source should
conform to a certain ideology, the WRONG way to go about fighting
that is to remove documents. Why is it wrong? You are trampling on
the rights of others. One RIGHT way to fight would be to write an
alternate SCM that people can switch to -- eliminate the need for BK.
I may disagree with Daniel's action, but his viewpoint is more than
fair, and is shared by others. My point with all this censorship /
free speech stuff is -- don't let your viewpoint cause others' rights
to be trampled.
> > If you want to be really semantic, Daniel's patch was an attempt to
> > censor, not censorship itself. But when it's a GPL'd document that
> > I wrote, I'll treat them equally.
>
> One doesn't "attempt to censor" by publicly announcing it. Get real,
> this is getting ridiculous.
Read up on censorship. It doesn't have to be private to be censorship.
In fact, it usually isn't.
Fact: GPL'd BK document contains speech Daniel doesn't like
Fact: Daniel tried to remove doc because he dislikes its contents
Interpret the facts however you wish.
> > > 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.
> >
> > If Linus and others repeatedly claim this is untrue, and repeatedly
> > prove this by taking GNU patches, your statement is utter fantasy.
>
> Again, I was more talking about SCM systems here. I don't care, what
> tools you are using, but we should avoid giving the impression, that
> Joe Hacker should use bk, because Linus is using it.
I agree. (shocked? :))
Nobody should feel forced or coerced into using BK, and we should
actively combat this notion.
I wonder if we can agree, as well, that no one should feel forced or
coerced into _not_ using BK, also. Do you agree?
Freedom of choice is also an important freedom. We, the BK fans, should
actively combat the notion of being forced to use BK. OTOH, the anti-BK
crowd should IMO actively combat the notion of being forced _not_ to use
BK. Daniel used the term "BitKeeper mafia" -- let's work together as a
community to ensure there is never an "anti-BitKeeper mafia" also...
> You and Linus may only care about hacking for fun, but other people also
> care about the freedom to hack. Recent developments in the US and Europe
> should have made clear that this is necessary. Nobody wants to make Larry
> the bad guy here, but is on the other hand a little respect really too
> much to ask for, when people critize the usage of bk, that they not
> automatically get branded as bunch of fanatics with some strange
> "ideology"?
I hold up Andrew Morton and Andi Kleen as two shining examples of people
who appear to disagree with BK, but are willing to patiently point out
problems. Andrew Morton's message in the middle of this thread was
wonderful, to-the-point, and rings true to me. I was very happy that he
posted it.
But to be honest, I _do_ feel that Daniel was being a fanatic.
That's an opinion, and I'm sure some people disagree.
Free speech is all about letting someone else that you _disagree_ with
air their opinion. Daniel's patch was not about that principle at all.
I will not cast aspersions on anyone else, since I only have Daniel's
actions to judge.
> Could we at least add something like below as a compromise (it's only a
> suggestion and not an attempt to brainwash or something like that). It's
> not enough to assume that people know that they have a choice, we have to
> tell them that and besides of some statements on the LKML, I can't find it
> officially documented anywhere:
I am perfectly fine with adding this paragraph to the BK doc, and
will save your email here with the intention of doing so. Your doc is
fair and I did not think for one second it was an attempt to brainwash.
Thank you,
Jeff
On Sun, Apr 21, 2002 at 04:53:05PM +0200, Daniel Phillips wrote:
> You seem to think I'm against Bitkeeper, or its use, or that I think
> Bitkeeper isn't helping linux. You're wrong. I am against carrying what
> *appears* to be a big advertisement for Bitkeeper itself in the Linux
> source tree. This I see as akin to putting up a commercial billboard in a
> public park. Would you be comfortable with that?
No, poor analogy -- the doc has proven useful time and time to kernel
developers. It's in the kernel source because of that.
Let us separate that fact from the notion that it is a BK
advertisement, and discuss that part, since that seems to be the
important issue. As the author of the doc, I state the doc was
not written as an advertisement, and was not paid for, directly
or indirectly.
That said, it certainly can been seen as an advertisement. I like BK,
and like to encourage others to use it.
So let us term the BK doc as, "not intended as an advertisement,
but can easily be considered such." I hope we agree so far? :)
Now that we have that...
Q. What is the justification for removing an admittedly-useful
advertisement?
A. Some people disagree with the author's point of view
(that POV being, "it's ok to use BK in the open source Linux project")
There is no dispute that the doc is useful, only dispute with certain
beliefs. Disagreement is fine... encouraged, even. But that's a
poor justification to remove the doc from the tree.
I hear your point, I really do. I just feel very strongly that
removing the BK docs from the tree is the worst way to go about
supporting this point of view.
Jeff
On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 17:44, Larry McVoy wrote:
> > On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > > 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.
> >
> > 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.
>
> So you have no problem with moving them to a website, leaving a url in
> SubmittingPatches?
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
On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 17:44, Larry McVoy wrote:
> > > On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > > > 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.
> > >
> > > 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.
> >
> > So you have no problem with moving them to a website, leaving a url in
> > SubmittingPatches?
>
> 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.
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
On Sun, Apr 21, 2002 at 06:21:27PM +0200, Daniel Phillips wrote:
> > It's not my call to make.
>
> I know that. I was wondering if *you personally* would have any objection.
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.
> > Take it up with the people who own the tree.
>
> That's all of us, last I heard. Administrating it is, of course, another story.
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
(Linus removed from CC)
On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > 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.
>
> 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...
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
On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > 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.
>
[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
On Monday 22 April 2002 19:03, Jeff Garzik wrote:
> Let us separate that fact from the notion that it is a BK
> advertisement, and discuss that part, since that seems to be the
> important issue. As the author of the doc, I state the doc was
> not written as an advertisement, and was not paid for, directly
> or indirectly.
>
> That said, it certainly can been seen as an advertisement.
OK, we've established that then.
> I like BK, and like to encourage others to use it.
>
> So let us term the BK doc as, "not intended as an advertisement,
> but can easily be considered such." I hope we agree so far? :)
>
> Now that we have that...
>
> Q. What is the justification for removing an admittedly-useful
> advertisement?
1) It would be equally as useful as a URL
2) It would not consume download bandwidth
3) It would show some sensitivity to the concerns of those who are
uncomfortable with the license.
> There is no dispute that the doc is useful, only dispute with certain
> beliefs. Disagreement is fine... encouraged, even. But that's a
> poor justification to remove the doc from the tree.
>
> I hear your point, I really do. I just feel very strongly that
> removing the BK docs from the tree is the worst way to go about
> supporting this point of view.
I really don't see how changing out the files for a url qualifies as
the "worst way" of addressing the issue. If Larry unretracts his offer
to host the files - and I fully expect he will do that after some period
of indulging in his wounded bird act - then by definition the documentation
will always be available exactly when and where needed. Is there *anybody*
here who'd have further license-related complaints about Bitkeeper if that
were done? (Speak or forever hold your peace.)
--
Daniel
On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> Is there *anybody*
> here who'd have further license-related complaints about Bitkeeper if that
> were done? (Speak or forever hold your peace.)
Oh boy oh boy oh boy, if you can deliver a commitment that this is the
last time we have a BK license-related complaint from a kernel hacker,
I'll be the first to argue vehemently for that patch you want.
I'd like to know how you are going to deliver on that offer you just made.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
(Linus removed from the CC... nudge nudge, Larry and Daniel)
On Mon, Apr 22, 2002 at 10:17:50AM -0700, Larry McVoy wrote:
> 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.
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
On Monday 22 April 2002 19:17, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 06:21:27PM +0200, Daniel Phillips wrote:
> > > It's not my call to make.
> >
> > I know that. I was wondering if *you personally* would have any objection.
>
> Daniel, I won't be nagged into supporting your point of view, sorry.
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.
> 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.
No, of course not, you're biased. Expected.
> 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.
How about a URL instead? Any objection?
> 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.
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.
> > > Take it up with the people who own the tree.
> >
> > That's all of us, last I heard. Administrating it is, of course, another story.
>
> 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.
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
On Monday 22 April 2002 19:19, Jeff Garzik wrote:
> (Linus removed from CC)
>
> On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > > 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.
> >
> > 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...
>
> Well, in order to prove you're being fair, your patch should have
> included removal of those CVS instructions, too :)
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.
> That's the point Linus made in his first message, and one I agree with.
You want it, you got it. Deal?
--
Daniel
On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> How about a URL instead? Any objection?
Yes.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> 1) It would be equally as useful as a URL
Maybe 5% less useful or so. There are reasons we move other
(non-controversial) docs into the kernel source. 100% of these docs can
be URLs.
> 2) It would not consume download bandwidth
This is a silly argument that dean gaudet dismembered. It's 12K
compressed and not your main argument at all.
> 3) It would show some sensitivity to the concerns of those who are
> uncomfortable with the license.
I agree.
So, I believe points #1 and #2 are silly, and #3 is your core argument.
And I agree that it would show sensitivity towards those people who
dislike the BK license.
That said, I still think removing the doc is a hideously wrong thing
to do. I see the action of BK doc removal as encouraging some strict
notion of what we can and cannot discuss, inside the kernel sources.
_That_ is the free speech aspect.
I see enforcing a strict notion of acceptable speech in the kernel
sources as a very bad thing for the Linux project.
I'm not asking you to agree -- but do you even understand my viewpoint here?
> > There is no dispute that the doc is useful, only dispute with certain
> > beliefs. Disagreement is fine... encouraged, even. But that's a
> > poor justification to remove the doc from the tree.
> >
> > I hear your point, I really do. I just feel very strongly that
> > removing the BK docs from the tree is the worst way to go about
> > supporting this point of view.
>
> I really don't see how changing out the files for a url qualifies as
> the "worst way" of addressing the issue. If Larry unretracts his offer
> to host the files - and I fully expect he will do that after some period
> of indulging in his wounded bird act - then by definition the documentation
> will always be available exactly when and where needed. Is there *anybody*
> here who'd have further license-related complaints about Bitkeeper if that
> were done? (Speak or forever hold your peace.)
First, I can host the doc. And will, if there is justification.
I do not see a justification. Larry is irrelevant.
Second, I guarantee that license-related complaints about BitKeeper will
continue to exist, regardless of the doc's location. Moving the doc
does absolutely nothing to assauge bad feelings about the BK license.
Jeff
On Monday 22 April 2002 19:21, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > > 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.
> >
> [response not answering the question deleted]
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.
> 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?
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.
> That's two questions, just answer those, nothing but those.
<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
On 21 Apr 02 at 19:34, Daniel Phillips wrote:
>
> 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?
Why we have kernel tarball at all, then? Just put URLs where you can
download different pieces of kernel, and we are done. You finally
solved problem how to help users who do not want to download different
arch subdirectories, or different drivers, as they do not need them
for their hardware, and downloading them takes a precious time.
As there is definitely at least one developer who uses Bitkeeper, and
as this information is seen useful at least by some people (me including),
I see no reason why this information should not be part of kernel.
Otherwise we must remove ncpfs and matroxfb from the kernel immediately, as
they both use proprietary protocol/interface, and there is available only
one vendor on the world who provides/supports this protocol/interface
(Novell resp. Matrox), and matroxfb documentation is just hidden advertising
of Matrox corp.
Best regards,
Petr Vandrovec
[email protected]
On Sun, Apr 21, 2002 at 07:37:47PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:19, Jeff Garzik wrote:
> > (Linus removed from CC)
> >
> > On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > > > 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.
> > >
> > > 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...
> >
> > Well, in order to prove you're being fair, your patch should have
> > included removal of those CVS instructions, too :)
>
> 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.
>
> > That's the point Linus made in his first message, and one I agree with.
>
> You want it, you got it. Deal?
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
On Monday 22 April 2002 19:30, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> > Is there *anybody*
> > here who'd have further license-related complaints about Bitkeeper if that
> > were done? (Speak or forever hold your peace.)
>
> Oh boy oh boy oh boy, if you can deliver a commitment that this is the
> last time we have a BK license-related complaint from a kernel hacker,
> I'll be the first to argue vehemently for that patch you want.
>
> I'd like to know how you are going to deliver on that offer you just made.
Clearly I'm not going to shut anyone up. However, only somebody with a very
limited perception of the situation could fail to note that you're being
tested, and what you do next is going to help form attitudes for some time
to come.
--
Daniel
On Monday 22 April 2002 19:38, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > How about a URL instead? Any objection?
>
> Yes.
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
On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> > > > 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.
>
> 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.
What part of "describing closed-spec hardware" did you not understand?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
(Linus CC removed)
On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> 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.
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
> > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > How about a URL instead? Any objection?
> >
> > Yes.
>
> And that objection is?
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
On Monday 22 April 2002 19:40, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> > 1) It would be equally as useful as a URL
>
> Maybe 5% less useful or so. There are reasons we move other
> (non-controversial) docs into the kernel source. 100% of these docs can
> be URLs.
>
> > 2) It would not consume download bandwidth
>
> This is a silly argument that dean gaudet dismembered. It's 12K
> compressed and not your main argument at all.
>
>
> > 3) It would show some sensitivity to the concerns of those who are
> > uncomfortable with the license.
>
> I agree.
>
> So, I believe points #1 and #2 are silly, and #3 is your core argument.
I think you stated that #1 is only 5% silly, by implication, 95% unsilly.
Two out of three ain't bad.
> And I agree that it would show sensitivity towards those people who
> dislike the BK license.
>
> That said, I still think removing the doc is a hideously wrong thing
> to do.
I agree. (/me listens for sound of garzik hitting floor) The doc was never
to be removed, it was to be moved. Read the original mail please. I repeat:
I *like* your docs, in fact I think they are excellent docs. I just don't
like to see them sitting in Documentation, for reasons we've been over in
some detail.
> I see the action of BK doc removal as encouraging some strict
> notion of what we can and cannot discuss, inside the kernel sources.
> _That_ is the free speech aspect.
>
> I see enforcing a strict notion of acceptable speech in the kernel
> sources as a very bad thing for the Linux project.
>
> I'm not asking you to agree -- but do you even understand my viewpoint here?
I do. I don't agree with you that any of this has something to do with free
speech, but I'm willing to accept that you view the kernel source as a kind of
podium.
> > I really don't see how changing out the files for a url qualifies as
> > the "worst way" of addressing the issue. If Larry unretracts his offer
> > to host the files - and I fully expect he will do that after some period
> > of indulging in his wounded bird act - then by definition the documentation
> > will always be available exactly when and where needed. Is there *anybody*
> > here who'd have further license-related complaints about Bitkeeper if that
> > were done? (Speak or forever hold your peace.)
>
> First, I can host the doc. And will, if there is justification.
> I do not see a justification. Larry is irrelevant.
To this discussion? Debatable. I'll go with you on that for now though, and
see where it leads.
> Second, I guarantee that license-related complaints about BitKeeper will
> continue to exist, regardless of the doc's location. Moving the doc
> does absolutely nothing to assauge bad feelings about the BK license.
It would for me, others mileage may vary.
--
Daniel
At 18:17 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 17:44, Larry McVoy wrote:
> > > > On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > > > > 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.
> > > >
> > > > 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.
> > >
> > > So you have no problem with moving them to a website, leaving a url in
> > > SubmittingPatches?
> >
> > 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.
>
>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.
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/
On Monday 22 April 2002 19:48, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> > > > > 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.
> >
> > 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.
>
> What part of "describing closed-spec hardware" did you not understand?
There is no kernel driver for Bitkeeper. What's your point?
--
Daniel
On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> (Linus CC removed)
>
> On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> > 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.
>
> 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...
Excellent point. If the BitKeeper advertising in the kernel source were
held to that level, I would be satisfied.
--
Daniel
On Monday 22 April 2002 19:53, Larry McVoy wrote:
> > > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > > How about a URL instead? Any objection?
> > >
> > > Yes.
> >
> > And that objection is?
>
> 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.
<confused>
First I don't control it, then I'm stomping on rights. What the?
> Your position would be somewhat stronger
> if you were applying the same metric to all aspects of the kernel, which
> you are not,
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.
> 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.
OK, so you are now requiring that I fix everything that is wrong with the
kernel before you reinstate your offer?
--
Daniel
Petr Vandrovec Awoke this dragon, who will now respond:
>
> Why we have kernel tarball at all, then? Just put URLs where you can
> download different pieces of kernel, and we are done. You finally
Actually, the kernel tarball is full of crap we dont need.
Sooner or later its going to get too big and be split up into
core kernel
drivers (drivers/net, drivers/video etc.)
arch specifics
documentation
all for seperate download.
On Monday 22 April 2002 20:01, Anton Altaparmakov wrote:
> At 18:17 21/04/02, Daniel Phillips wrote:
> >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.
>
> 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.
But they are instructions for CVS, you're just about to go to some effort to
download over the web. Bogus.
> 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.
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.
> If such disclaimer doesn't appease the anti-bitkeeper crew
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.
> 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.
Changing the documents for a url penalizes you exactly how?
--
Daniel
At 19:19 22/04/02, Ian Molton wrote:
>Petr Vandrovec Awoke this dragon, who will now respond:
>
> >
> > Why we have kernel tarball at all, then? Just put URLs where you can
> > download different pieces of kernel, and we are done. You finally
>
>Actually, the kernel tarball is full of crap we dont need.
>
>Sooner or later its going to get too big and be split up into
>
>core kernel
>drivers (drivers/net, drivers/video etc.)
>arch specifics
>documentation
>
>all for seperate download.
That is never going to happen, at least not as long as Linus is the kernel
maintainer. I believe he has said so more than once before...
One of the reasons being that such an act would make changing global APIs a
virtual impossiblity. And such changes happen often in Linux during the
unstable kernel series. And those changes are good changes... Otherwise we
will end up with Windows having backwards compatibility with DOS for
virtually all eternity...
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/
At 19:16 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 20:01, Anton Altaparmakov wrote:
> > At 18:17 21/04/02, Daniel Phillips wrote:
> > >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.
> >
> > 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.
>
>But they are instructions for CVS, you're just about to go to some effort to
>download over the web. Bogus.
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...
> > 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.
>
>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.
>
> > If such disclaimer doesn't appease the anti-bitkeeper crew
>
>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.
Oh I wasn't refering just to you. I was refering to the "silently seething"
kernel hackers you mentioned but refused to name...
> > 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.
>
>Changing the documents for a url penalizes you exactly how?
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/
Hi,
Could please someone have this patch applied instead of arguing all day
and all of the night?
Regards,
Thunder
--- bk-kernel-howto.txt~ Mon Apr 22 12:26:50 2002
+++ bk-kernel-howto.txt Mon Apr 22 12:26:11 2002
@@ -15,6 +15,14 @@
"bk help <command>" or in X "bk helptool <command>" for reference
documentation.
+ Also, 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.
BitKeeper Concepts
------------------
--
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.
Jeff,
The BK documentation constitutes an implicit advertisement and
endorsement of a product with a license which to many developers
violates the spirit of open source software. This is not to say that BK
is not an effective product, nor that the document in question is useful
for people who choose the tool, but to me it seems comparable to
including a closed source binary module in the kernel distribution.
Moving the document to the BK website would be nicer, and would
certainly assauge bad feelings regarding such an integral implicit
endorsement of a tool.
--Jonathan--
On Monday 22 April 2002 20:29, Anton Altaparmakov wrote:
> >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.
>
> Oh I wasn't refering just to you.
Don't refer to me at all in that context, thankyou.
> I was refering to the "silently seething"
> kernel hackers you mentioned but refused to name...
Indeed. Please get a clue a read the thread. Sheesh. No, I'm still not going
to name anybody, figure it out yourself.
> > > 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.
> >
> >Changing the documents for a url penalizes you exactly how?
>
> 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.
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).
> What part of that do you not understand?
I don't understand the part where you find clicking a url difficult. Please
tell me it ain't so.
> Perhaps you
> have a 24x7 internet connection, many people don't. Perhaps this is a
> surpise to you?
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
On Mon, Apr 22, 2002 at 01:37:19PM -0500, Jonathan A. George wrote:
> The BK documentation constitutes an implicit advertisement and
> endorsement of a product with a license which to many developers
> violates the spirit of open source software.
Agreed.
And the simple fact of Linus using BitKeeper does the
_exact_ _same_ _thing_.
Talk Linus out of using BitKeeper, and sure, I'll remove the doc.
> This is not to say that BK
> is not an effective product, nor that the document in question is useful
> for people who choose the tool, but to me it seems comparable to
> including a closed source binary module in the kernel distribution.
No, it is not comparable at all with that. There are no license
problems with the document -- it is GPL'd.
It describes the same thing as Documentation/SubmittingPatches does, and
is very relevant to kernel development.
> Moving the document to the BK website would be nicer, and would
> certainly assauge bad feelings regarding such an integral implicit
> endorsement of a tool.
Removing the doc from the kernel sources would be a token gesture only.
Some developers disagree violently with the use of non-open-source tools
at all, and that is a fundamental disagreement.
The majority of the "silently seething" developers, I imagine, are only
gonna be satisfied when (a) BitKeeper is GPL'd or (b) Linus stops using
BitKeeper. Both of these seem very remote possibilities at present.
Jeff
P.S. The doc is _not_ going on the BK website by my hand. (though I
have given BitMover permission to post the doc whereever they wish)
I can maintain my own docs much better than Larry can :)
Jeff Garzik wrote:
>On Mon, Apr 22, 2002 at 01:37:19PM -0500, Jonathan A. George wrote:
>
>
>>The BK documentation constitutes an implicit advertisement and
>>endorsement of a product with a license which to many developers
>>violates the spirit of open source software.
>>
>Agreed.
>
>And the simple fact of Linus using BitKeeper does the
>_exact_ _same_ _thing_.
>
Not quite. Linus uses BK as a tool to facilitate kernel development.
However, he has not made BK _part_ _of_ _the_ _kernel_. ;-) Obviously
anyone can use any tool ON the kernel, but integrating into the kernel
is something else.
>Talk Linus out of using BitKeeper, and sure, I'll remove the doc.
>
No need. His tools are his choice. The kernel itself is ours not his;
thus the distinction.
>>This is not to say that BK
>>is not an effective product, nor that the document in question is useful
>>for people who choose the tool, but to me it seems comparable to
>>including a closed source binary module in the kernel distribution.
>>
>No, it is not comparable at all with that. There are no license
>problems with the document -- it is GPL'd.
>
The GPL has a specific intent which (though use in the kernel is more
like the LGPL because binary modules are permitted) which doesn't
explicitly extend to such documentation. The spirit of the GPL which
causes us to exclude binary modules from the distribution very much does
apply. To a lawyer this might not matter, but I expect more from a top
free software contributor like you.
>It describes the same thing as Documentation/SubmittingPatches does, and
>is very relevant to kernel development.
>
In fact I effectively noted its usefulness above. Thus no argument here.
>>Moving the document to the BK website would be nicer, and would
>>certainly assauge bad feelings regarding such an integral implicit
>>endorsement of a tool.
>>
>Removing the doc from the kernel sources would be a token gesture only.
>
I strongly disagree for the reasons I have noted.
>Some developers disagree violently with the use of non-open-source tools
>at all, and that is a fundamental disagreement.
>
>The majority of the "silently seething" developers, I imagine, are only
>gonna be satisfied when (a) BitKeeper is GPL'd or (b) Linus stops using
>BitKeeper. Both of these seem very remote possibilities at present.
>
Note: you are not quoting me here ;-) However, I completely agree.
> Jeff
>
>P.S. The doc is _not_ going on the BK website by my hand. (though I
>have given BitMover permission to post the doc whereever they wish)
>I can maintain my own docs much better than Larry can :)
>
That is a minor detail (as you know). My suggestion was an attempt to
balance the value of your admittedly useful document with the nature of
the endorsement.
--Jonathan--
<cc list trimmed because this is getting silly>
At 19:47 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 20:29, Anton Altaparmakov wrote:
> > >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.
> >
> > Oh I wasn't refering just to you.
>
>Don't refer to me at all in that context, thankyou.
Ok, no problem.
> > I was refering to the "silently seething"
> > kernel hackers you mentioned but refused to name...
>
>Indeed. Please get a clue a read the thread. Sheesh. No, I'm still not
>going to name anybody, figure it out yourself.
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...
> > > > 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.
> > >
> > >Changing the documents for a url penalizes you exactly how?
> >
> > 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.
>
>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 didn't say anything stupid. You did. And your reply is out of context
because I am talking about disconnectedness.
> > What part of that do you not understand?
>
>I don't understand the part where you find clicking a url difficult. Please
>tell me it ain't so.
I click URL and wait and wait and I get "could not contact server". No
internet connection damn!
> > Perhaps you
> > have a 24x7 internet connection, many people don't. Perhaps this is a
> > surpise to you?
>
>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.
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/
Hi,
Thunder from the hill wrote:
> --- bk-kernel-howto.txt~ Mon Apr 22 12:26:50 2002
> +++ bk-kernel-howto.txt Mon Apr 22 12:26:11 2002
> @@ -15,6 +15,14 @@
I'd prefer this to be a separate document (e.g. README) and not
somewhere inbetween.
> + Also, 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
^^^^^^^^^^^
At that point it's already too late, the user must have the chance to
read this, before he installs bk.
> + not open source. If you feel strongly about 100% free software
> + tool chain, then don't use BitKeeper. Linus has repeatedly stated
^^^^^^^^^^^^^^^^^^^^^
That has a "for all these idiots, that don't want to understand"
aftertaste, I'm certain Linus doesn't want to imply that.
bye, Roman
On Mon, Apr 22, 2002 at 09:40:43PM +0200, Roman Zippel wrote:
> > + Also, 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
- to the licensing rules (bk help bkl will display them), but it is
+ to the licensing rules (http://www.bitkeeper.com/manpages/bk-bkl-1.html)
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
At 19:37 22/04/02, Jonathan A. George wrote:
>Jeff,
>
>The BK documentation constitutes an implicit advertisement and endorsement
>of a product with a license which to many developers violates the spirit
>of open source software. This is not to say that BK is not an effective
>product, nor that the document in question is useful for people who choose
>the tool, but to me it seems comparable to including a closed source
>binary module in the kernel distribution. Moving the document to the BK
>website would be nicer, and would certainly assauge bad feelings regarding
>such an integral implicit endorsement of a tool.
>
>--Jonathan--
I hereby publically endorse the use of bitkeeper. I think it's a great tool
and I think anyone who is not using it is missing out. Anyone who asks me
what a good SCM to use is will hear "bitkeeper" from me. And I shall not
change my mind until a better or at least as good tool becomes available.
Taking out the document only because it describes a non-free tool is
ridiculous. I don't object to the removal per se. I could live with that. I
object to the REASONS for removal.
And I am prepared to speak for that, in case you hadn't noticed. (-;
How about that?
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/
On Mon, 22 Apr 2002, Jonathan A. George wrote:
> Not quite. Linus uses BK as a tool to facilitate kernel development.
> However, he has not made BK _part_ _of_ _the_ _kernel_. ;-) Obviously
> anyone can use any tool ON the kernel, but integrating into the kernel
> is something else.
>
> >Talk Linus out of using BitKeeper, and sure, I'll remove the doc.
> >
> No need. His tools are his choice. The kernel itself is ours not his;
> thus the distinction.
Bullshit. His copy is his. Mine is mine. Yours is yours. Each of
us is perfectly within his rights when he adds whatever patches he
likes.
And that's _it_. Linus has absolute control over his copy, as long
as he doesn't run afoul of copyright restrictions. So do I. So do
you. GPL explicitly allows to modify and redistribute result of
modifications. As the matter of fact, as soon as you attempt to
limit such right, you are losing all rights granted to you by GPL.
"Official" tree is the copy placed by Linus on ftp.kernel.org. And
as long as ftp.kernel.org admins keep his account (and write permissions
on directory in question) that copy is controlled by Linus. Period.
End of story. Linus has exactly the same rights as anybody else and
_everyone_ has a right to modify his copy as he likes.
If you don't like it - take it with RMS and FSF, who happen to feel
very strongly about that right. That's what GPL is about. If you
don't like modifications done by somebody, you have only one
recourse - you are allowed to back them off _in_ _your_ _copy_
and distribute that copy.
It's fscking amazing that self-proclaimed GPL advocates happily
ignore the main stated goal of GPL - to ensure that everybody will be
able to hack on his copy as he wants and share results with
everybody else. The fact that your modifications are in there
does not allow you to stop anybody else from further modifications.
On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> How about a URL instead? Any objection?
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
On Mon, Apr 22, 2002 at 02:19:13PM -0500, Jonathan A. George wrote:
> Jeff Garzik wrote:
>
> >On Mon, Apr 22, 2002 at 01:37:19PM -0500, Jonathan A. George wrote:
> >
> >
> >>The BK documentation constitutes an implicit advertisement and
> >>endorsement of a product with a license which to many developers
> >>violates the spirit of open source software.
> >>
> >Agreed.
> >
> >And the simple fact of Linus using BitKeeper does the
> >_exact_ _same_ _thing_.
> >
> Not quite. Linus uses BK as a tool to facilitate kernel development.
> However, he has not made BK _part_ _of_ _the_ _kernel_. ;-) Obviously
> anyone can use any tool ON the kernel, but integrating into the kernel
> is something else.
That's a poor comparison, we are not integrating BitKeeper into the
kernel :)
Like or not, BK is used by several maintainers, including The Big
Penguin himself. There are plenty of good reasons why this doc
should be in the kernel source, only a single, lone reason against
it: some people don't like _talking_ about proprietary software in
the kernel sources.
> >Talk Linus out of using BitKeeper, and sure, I'll remove the doc.
> >
> No need. His tools are his choice. The kernel itself is ours not his;
> thus the distinction.
He is the gatekeeper. The kernel can be considered his, too, because it
is on his judgement that changes are accepted and rejected. If he uses
BitKeeper, and some maintainers find it easier to use BitKeeper, that's
a far stronger implicit advertisement for BitKeeper than some doc will
ever be. If Linus stopped using BitKeeper, that would provide incentive
for other maintainers to stop using BitKeeper, which in turn means there
is technical merit in the removal of the BK doc.
> >>This is not to say that BK
> >>is not an effective product, nor that the document in question is useful
> >>for people who choose the tool, but to me it seems comparable to
> >>including a closed source binary module in the kernel distribution.
> >>
> >No, it is not comparable at all with that. There are no license
> >problems with the document -- it is GPL'd.
> >
> The GPL has a specific intent which (though use in the kernel is more
> like the LGPL because binary modules are permitted) which doesn't
> explicitly extend to such documentation. The spirit of the GPL which
> causes us to exclude binary modules from the distribution very much does
> apply. To a lawyer this might not matter, but I expect more from a top
> free software contributor like you.
The doc is free by any standard. The _subject_ of the doc is not free.
There are plenty of documents talking about proprietary software
which are free, covered by the GNU FDL if not the GPL or some other
free license. Separate the licensing of the _subject_ of the doc,
from the doc itself.
I simply don't see a comparison at all. Closed source and binary
modules by definition hides IP from most. The doc is hiding nothing.
I don't think it will accomplish anything, but if it satisfies you or
others, I can change the doc's license to GNU FDL.
What matters to me is that other free software contributors are trying
to dictate what we can and cannot _talk about_ in the kernel sources.
> That is a minor detail (as you know). My suggestion was an attempt to
> balance the value of your admittedly useful document with the nature of
> the endorsement.
The nature of the endorsement is implicit when BK is used by kernel
developers, not when a doc is present.
I'm very open to suggestions about combatting the notion that BK
is required for kernel devel. Removing this doc may satisfy a few
people, but (a) it does not address the fundamental disagreement,
and (b) it is a slippery slope when we start removing docs because
we disagree with their subject on ideological grounds.
Even if I was completely anti-BitKeeper, pro-100%-open-source,
I would find Daniel's patch troubling because of "(b)"
Kernel source is no place to start drawing strict notions of what is
acceptable to discuss. I weigh that assertion above a token gesture to
the silently-seething developers that does nothing to change the real
status quo.
Jeff
On Mon, Apr 22, 2002 at 08:47:39PM +0100, Anton Altaparmakov wrote:
> Taking out the document only because it describes a non-free tool is
> ridiculous. I don't object to the removal per se. I could live with that. I
> object to the REASONS for removal.
Likewise. This is perhaps saying it better than I have been...
Jeff
Alexander Viro wrote:
>On Mon, 22 Apr 2002, Jonathan A. George wrote:
>
>>Not quite. Linus uses BK as a tool to facilitate kernel development.
>> However, he has not made BK _part_ _of_ _the_ _kernel_. ;-) Obviously
>>anyone can use any tool ON the kernel, but integrating into the kernel
>>is something else.
>>
>>>Talk Linus out of using BitKeeper, and sure, I'll remove the doc.
>>>
>>No need. His tools are his choice. The kernel itself is ours not his;
>> thus the distinction.
>>
>>
>
>Bullshit. His copy is his. Mine is mine. Yours is yours. Each of
>us is perfectly within his rights when he adds whatever patches he
>likes.
>
Both statements are true. Imagine that.
--Jonathan--
On Mon, 22 Apr 2002, Jonathan A. George wrote:
> Alexander Viro wrote:
> >On Mon, 22 Apr 2002, Jonathan A. George wrote:
> >>No need. His tools are his choice. The kernel itself is ours not his;
^^^^^^^^^^^^
> >> thus the distinction.
> >
> >Bullshit. His copy is his. Mine is mine. Yours is yours. Each of
> >us is perfectly within his rights when he adds whatever patches he
> >likes.
> >
> Both statements are true. Imagine that.
So where the hell do you or anybody else get the right to prohibit him adding
GPLed file to his copy?
RTFGPL. Again, if you don't like said additions - fucking tough,
they are explicitly allowed by the license.
On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > 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...
>
> Excellent point. If the BitKeeper advertising in the kernel source were
> held to that level, I would be satisfied.
<chuckle> -- and if that occurred, _I_ would fight to remove it as a
pointless advertisement.
Jeff
On Monday 22 April 2002 21:53, Doug Ledford wrote:
> On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > How about a URL instead? Any objection?
>
> Yes. Why should I have to cut and paste (assuming I'm in X) or
> write down
What??? What kind of system are you running? Err... redhat supports
cut and paste I thought. <-- funnny.
> and transpose some URL from a file that used to contain
> the exact instructions I need in order to get those instructions now
Bogus. You'd have to do the same to edit/list the file.
> 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".
Thanks for your story. It's exactly what I've suggested, put the BK docs
on a web site.
> 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,
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.
> 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,
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!)
> 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.
E) What is the license?
> 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.
Because you can't follow a url? Give me a break.
Bogus.
--
Daniel
On Sun, Apr 21, 2002 at 01:22:37PM -0700, Andrew Morton wrote:
> The reason why people do not express their disquiet is very plain - any
> time anyone dares comes out, they promptly get their head kicked in.
> Guys, this problem is permanent, and it's not going away.
Yeah, it's a problem with religious perspectives at this point, things
can occasionally get ugly :)
I'm really glad you are speaking up, though...
> Larry has stated that kernel's use of bitkeeper is not providing
> collateral sales, and nor was it intended for that. Fair enough.
> But it's inevitable that, in some people's eyes, kernel's very
> public use of bitkeeper be viewed as promotion of bitmover's
> product, and as endorsement of bitmover's licensing innovations.
Agreed -- but one can also see it just as real life, a compromise
with proven open source productivity gains. Linus, myself, and
others have repeatedly been saying that we would use a superior free
software tool...
At the end of the day, I think the open source cause is advanced by
this non-open-source tool, because Linux kernel development (or at
least the rate of patch application) is by all measures "faster."
By extension, discouraging use of BitKeeper when it is clearly useful
potentially harms the cause of open source.
> Linus took the work of others and used it in a way which they did
> not expect, without their permission, and contrary to their wishes.
> He knew what he was doing, and he knew that some wouldn't like it.
I think that's a bit unfair :( All Linus did was add an additional
method of patch transport... the source code is still the same
bitrotten hunk of poo we all know, love, and work on :)
> My take on Daniel's patch is that it is addressing the symptoms,
> not the problem. And the problem is unsolveable. The differences
> of opinion are irreconcilable. Both sides are populated by
> perfectly sensible people with perfectly legitimate points of view.
Pretty much my conclusion...
Jeff
On Sun, 21 Apr 2002, Daniel Phillips wrote:
> You seem to think I'm against Bitkeeper, or its use, or that I think
> Bitkeeper isn't helping linux. You're wrong. I am against carrying what
> *appears* to be a big advertisement for Bitkeeper itself in the Linux
> source tree. This I see as akin to putting up a commercial billboard in a
> public park. Would you be comfortable with that?
part of what i'm reacting to in this debate is what i perceive as a
different set of standards which people apply to software versus, say,
hardware.
linux-kernel (and the kernel itself, and the zillions of websites out
there with supporting documentation) are chock full of "advertisements"
for hardware. pro and con. i've made many hardware purchase decisions
based on stuff i read here, and stuff i find when searching for linux
documentation.
maybe someday we'll get scifi technology such as nanotech or replicators
(and "limitless" fusion energy) which can move us into a new economy in
which even open hardware is possible... but that's not the case today --
and i doubt many of you are using anything that could be considered open
hardware... almost certainly nobody is able to build an open hardware
platform with the same performance and quality standards as proprietary
hardware can achieve.
isn't there a bit of a double standard in place here?
i happen to put food on my table working at a hardware company; larry puts
food on his working at a software company. i happen to work at the same
hardware company as linus does: transmeta. every kernel for the past,
uh, 6 or 7 years, has included an advertisement for transmeta. could we
possibly conceive of removing all references to transmeta from the kernel,
mailing lists and archives? (oh i know if i go back that far in the
archives there was probably a big uproar when linus changed his email
address :)
-dean
On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > 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...
> >
> > Excellent point. If the BitKeeper advertising in the kernel source were
> > held to that level, I would be satisfied.
>
> <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> pointless advertisement.
You'd want to get rid of the url that points at your docs?
--
Daniel
On Sun, Apr 21, 2002 at 07:57:55PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:40, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> > > 1) It would be equally as useful as a URL
> >
> > Maybe 5% less useful or so. There are reasons we move other
> > (non-controversial) docs into the kernel source. 100% of these docs can
> > be URLs.
> >
> > > 2) It would not consume download bandwidth
> >
> > This is a silly argument that dean gaudet dismembered. It's 12K
> > compressed and not your main argument at all.
> >
> >
> > > 3) It would show some sensitivity to the concerns of those who are
> > > uncomfortable with the license.
> >
> > I agree.
> >
> > So, I believe points #1 and #2 are silly, and #3 is your core argument.
>
> I think you stated that #1 is only 5% silly, by implication, 95% unsilly.
> Two out of three ain't bad.
I will grant you that :) but clarify:
Making is a URL is no big deal and shouldn't be a point of discussion,
as I think #2 is no big deal and shouldn't be a point of discussion.
The real question, as I understand it, is whether or not the kernel doc
should be in the kernel source or not. If the answer is 'no', then I
fully support making it a URL, or printing it out the back of
phonebooks, or whatever means of distribution :)
But I am arguing that the answer 'no' has not been justified yet...
> > And I agree that it would show sensitivity towards those people who
> > dislike the BK license.
> >
> > That said, I still think removing the doc is a hideously wrong thing
> > to do.
>
> I agree. (/me listens for sound of garzik hitting floor) The doc was never
> to be removed, it was to be moved. Read the original mail please. I repeat:
> I *like* your docs, in fact I think they are excellent docs. I just don't
> like to see them sitting in Documentation, for reasons we've been over in
> some detail.
This is really a semantic argument... I shorten "removing from kernel
sources" as "removing", because (correct me here) we are discussing what
we want to see in the kernel sources, and what we do not want to see in
the kernel sources.
Even without an official web site, the BK doc would live on in kernel
archives if nowhere else.
If it makes things more clear, I can use my same arguments, and do a
search-n-replace of "remove from kernel sources" to "move from kernel
sources to elsewhere." To me, it's the same thing.
> > I see the action of BK doc removal as encouraging some strict
> > notion of what we can and cannot discuss, inside the kernel sources.
> > _That_ is the free speech aspect.
> >
> > I see enforcing a strict notion of acceptable speech in the kernel
> > sources as a very bad thing for the Linux project.
> >
> > I'm not asking you to agree -- but do you even understand my viewpoint here?
>
> I do. I don't agree with you that any of this has something to do with free
> speech, but I'm willing to accept that you view the kernel source as a kind of
> podium.
I conjecture, then, that moving the BK doc to satisfy sensitivies is
also acknowledge of the kernel sources as a podium :)
> > > I really don't see how changing out the files for a url qualifies as
> > > the "worst way" of addressing the issue. If Larry unretracts his offer
> > > to host the files - and I fully expect he will do that after some period
> > > of indulging in his wounded bird act - then by definition the documentation
> > > will always be available exactly when and where needed. Is there *anybody*
> > > here who'd have further license-related complaints about Bitkeeper if that
> > > were done? (Speak or forever hold your peace.)
> >
> > First, I can host the doc. And will, if there is justification.
> > I do not see a justification. Larry is irrelevant.
>
> To this discussion? Debatable. I'll go with you on that for now though, and
> see where it leads.
hehe
> > Second, I guarantee that license-related complaints about BitKeeper will
> > continue to exist, regardless of the doc's location. Moving the doc
> > does absolutely nothing to assauge bad feelings about the BK license.
>
> It would for me, others mileage may vary.
Interesting. And I will claim up-front that I don't understand this
one bit. BitKeeper would still be in use with its odious license,
and people will still say the "BitKeeper mafia" exists, even if the
document is moved.
Jeff
On Monday 22 April 2002 22:37, dean gaudet wrote:
> i happen to put food on my table working at a hardware company; larry puts
> food on his working at a software company. ?i happen to work at the same
> hardware company as linus does: ?transmeta. ?every kernel for the past,
> uh, 6 or 7 years, has included an advertisement for transmeta. ?could we
> possibly conceive of removing all references to transmeta from the kernel,
> mailing lists and archives?
How big is the Transmeta ad? Does it have its own file? Would you be
satisfied if Bitkeeper had the same size advertisement as Transmeta?
--
Daniel
On Monday 22 April 2002 22:47, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 07:57:55PM +0200, Daniel Phillips wrote:
> > I do. I don't agree with you that any of this has something to do with free
> > speech, but I'm willing to accept that you view the kernel source as a kind of
> > podium.
>
> I conjecture, then, that moving the BK doc to satisfy sensitivies is
> also acknowledge of the kernel sources as a podium :)
More like a monument. Currently, with a billboard on it.
--
Daniel
On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 21:53, Doug Ledford wrote:
> > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > How about a URL instead? Any objection?
> >
> > Yes. Why should I have to cut and paste (assuming I'm in X) or
> > write down
>
> What??? What kind of system are you running? Err... redhat supports
> cut and paste I thought. <-- funnny.
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.
> > and transpose some URL from a file that used to contain
> > the exact instructions I need in order to get those instructions now
>
> Bogus. You'd have to do the same to edit/list the file.
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 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
> ^^^^^^^^^^^
> Thanks for your story. It's exactly what I've suggested, put the BK docs
> on a web site.
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:
> > information so that the whole picture, from start to finish, was all
> > described in one easy to access place.
One place for relevant information, from start to finish.
> > 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".
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.
> 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.
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*.
> 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.
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.
> E) What is the license?
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.
> > 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.
>
> Because you can't follow a url? Give me a break.
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
At 21:42 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > > 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...
> > >
> > > Excellent point. If the BitKeeper advertising in the kernel source were
> > > held to that level, I would be satisfied.
> >
> > <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> > pointless advertisement.
>
>You'd want to get rid of the url that points at your docs?
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/
On Sun, Apr 21, 2002 at 10:42:46PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > > 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...
> > >
> > > Excellent point. If the BitKeeper advertising in the kernel source were
> > > held to that level, I would be satisfied.
> >
> > <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> > pointless advertisement.
>
> You'd want to get rid of the url that points at your docs?
"that level" was assuming you were referring to the URL-free printk
advertisement I quoted above.
Jeff
On Monday 22 April 2002 22:57, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 10:42:46PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> > > On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > > > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > > > 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...
> > > >
> > > > Excellent point. If the BitKeeper advertising in the kernel source were
> > > > held to that level, I would be satisfied.
> > >
> > > <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> > > pointless advertisement.
> >
> > You'd want to get rid of the url that points at your docs?
>
> "that level" was assuming you were referring to the URL-free printk
> advertisement I quoted above.
Oh, I was thinking "a few lines", regardless of content.
--
Daniel
On Monday 22 April 2002 22:53, Doug Ledford wrote:
> On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 21:53, Doug Ledford wrote:
> > > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > > How about a URL instead? Any objection?
> > >
> > > Yes. Why should I have to cut and paste (assuming I'm in X) or
> > > write down
> >
> > What??? What kind of system are you running? Err... redhat supports
> > cut and paste I thought. <-- funnny.
>
> 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.
Would everybody with no mouse on their system please stand up, and leave
the room.
Seriously, you're trolling.
> > > and transpose some URL from a file that used to contain
> > > the exact instructions I need in order to get those instructions now
> >
> > Bogus. You'd have to do the same to edit/list the file.
>
> 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.
lynx <url>
What's the difference?
> 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:
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.
> > > information so that the whole picture, from start to finish, was all
> > > described in one easy to access place.
>
> One place for relevant information, from start to finish.
Right. bitkeeper.com, any argument?
> > 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.
>
> 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*.
He agreed it was an advertisement.
--
Daniel
On Mon, 22 Apr 2002, Jonathan A. George wrote:
> The BK documentation constitutes an implicit advertisement and
> endorsement of a product with a license which to many developers
> violates the spirit of open source software.
Yeah right, just like having having drivers/bluetooth/ is
an implicit advertisement for bluetooth hardware ;)
Could you please get over the fact that people will always
include useful stuff into the kernel ?
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Sun, Apr 21, 2002 at 11:05:11PM +0200, Daniel Phillips wrote:
> Would everybody with no mouse on their system please stand up, and leave
> the room.
>
> Seriously, you're trolling.
No more so than your bandwidth argument...pot->kettle.
> > 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:
>
> 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.
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.
> 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.
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.
> > > > information so that the whole picture, from start to finish, was all
> > > > described in one easy to access place.
> >
> > One place for relevant information, from start to finish.
>
> Right. bitkeeper.com, any argument?
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.
> He agreed it was an advertisement.
>
> --
> Daniel
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
On Sun, Apr 21, 2002 at 11:05:11PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 22:53, Doug Ledford wrote:
> > On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> > > 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.
> >
> > 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*.
>
> He agreed it was an advertisement.
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
On Mon, Apr 22, 2002 at 05:25:37PM -0400, Jeff Garzik wrote:
> 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.
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
On Monday 22 April 2002 23:21, Doug Ledford wrote:
> On Sun, Apr 21, 2002 at 11:05:11PM +0200, Daniel Phillips wrote:
> > Would everybody with no mouse on their system please stand up, and leave
> > the room.
> >
> > Seriously, you're trolling.
>
> No more so than your bandwidth argument...pot->kettle.
I'll stick with the bandwidth argument. 99.99% of the people who download Linux
don't need the Bitkeeper docs at all. Waste of cycles. Think what happens to
the source if we don't care at all about extra bulk. Hint: I've got a 75 meg
compressed source file here from an embedded systems vendor that has about 5
meg that I actually use.
If Jeff wants to give me only 2.95 out of 3 points for my arguments, that's
his business.
> > > 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:
> >
> > 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.
>
> Right, nice personal attack to deflect the arguments I actually wrote.
It was fuhhhhhneee. Get a grip please.
> 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.
Well. Could always start now, and please count the places in the thread
where I say BitKeeper is a good thing for Linux. Commerical breaks in
in the source tree itself are considerably less good.
> > > > > information so that the whole picture, from start to finish, was all
> > > > > described in one easy to access place.
> > >
> > > One place for relevant information, from start to finish.
> >
> > Right. bitkeeper.com, any argument?
>
> 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.
Could have fooled me. I thought that getting Linux developers to endorse
BitKeeper was a key part of Larry's business plan, which, by the way, I
fully support. I just don't support the part that turns Documentation
into a billboard.
--
Daniel
Daniel Phillips wrote:
> On Monday 22 April 2002 22:53, Doug Ledford wrote:
>
>>On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
>>
>>>On Monday 22 April 2002 21:53, Doug Ledford wrote:
>>>
>>>>On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
>>>>
>>>>>How about a URL instead? Any objection?
>>>>
>>>>Yes. Why should I have to cut and paste (assuming I'm in X) or
>>>>write down
>>>
>>>What??? What kind of system are you running? Err... redhat supports
>>>cut and paste I thought. <-- funnny.
>>
>>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.
>
>
> Would everybody with no mouse on their system please stand up, and leave
> the room.
>
> Seriously, you're trolling.
>
>
>>>>and transpose some URL from a file that used to contain
>>>>the exact instructions I need in order to get those instructions now
>>>
>>>Bogus. You'd have to do the same to edit/list the file.
>>
>>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.
>
>
> lynx <url>
>
> What's the difference?
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.
>
>
>>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:
>
>
> 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.
>
>
>>>>information so that the whole picture, from start to finish, was all
>>>>described in one easy to access place.
>>>
>>One place for relevant information, from start to finish.
>
>
> Right. bitkeeper.com, any argument?
>
>
>>>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.
>>
>>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*.
>
>
> He agreed it was an advertisement.
>
[snip the drivel]
Daniel, if you will ever get a legitimate reason to send me mail -
try to convince somebody sane to forward it. I'm serious - taking
you out of killfile was a bad mistake and I'm not going to repeat
it.
*PLONK*
On Mon, 22 Apr 2002, Jeff Garzik wrote:
> The real question, as I understand it, is whether or not the kernel doc
> should be in the kernel source or not. If the answer is 'no', then I
> fully support making it a URL, or printing it out the back of
> phonebooks, or whatever means of distribution :)
i really tried to remain out of this. in theory, like Linus said, we
should not even know that he's using bk. it should be completely hidden.
the only method described inside the kernel tarbal should be the
old diff+patch one. main maintainers ( i mean the group of at most 10 that
are handling huge number of patches and that are highly interacting with
Linus ) will very likely get benefits from using bk instead of diff+patch,
but for these one no doc is necessary. either they know or Larry can
provide them with all the docs they need. for all the remaining crew, bk
adoption is simply a trend followup.
- Davide
Jeff Garzik wrote:
>On Mon, Apr 22, 2002 at 01:37:19PM -0500, Jonathan A. George wrote:
>
>
>>The BK documentation constitutes an implicit advertisement and
>>endorsement of a product with a license which to many developers
>>violates the spirit of open source software.
>>
<snip>
>>The majority of the "silently seething" developers, I imagine, are only
>>gonna be satisfied when (a) BitKeeper is GPL'd or (b) Linus stops using
>>BitKeeper. Both of these seem very remote possibilities at present.
>>
>> Jeff
>>
Pax. I think that Rik made a good point RE bluetooth support, and
obviously no one with cache in the kernel community cares enough about
the non-free implications of using BK (an admittedly good tool) to keep
the kernel source free of such endorsements. In conceding I appreciate
but disagree with your position. Oh, and of course Al showed his ass on
your behalf thus proving that intelligence and politeness are not related.
Respectfully,
Jonathan
On Sun, Apr 21, 2002 at 11:37:29PM +0200, Daniel Phillips wrote:
> Well. Could always start now, and please count the places in the thread
> where I say BitKeeper is a good thing for Linux. Commerical breaks in
> in the source tree itself are considerably less good.
Establishing that something is a commercial break requires more than
saying "Hey, that talks about features of X commercial product". It
involves *also* establishing that the commercial break doesn't apply those
features to linux kernel programming in an instructional manner. If you
haven't done both, then you haven't done enough to justify removing said
"commercial break" from the kernel archive. As long as the "commercial
break" is an instructional document I'll advocate that it stays where it
is. The *most* you will ever get me to agree to is the possible removal
of obviously superflous and advocacy related statements that don't
contribute to the instructional nature of the document.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> On Mon, 22 Apr 2002, Jeff Garzik wrote:
>
> > The real question, as I understand it, is whether or not the kernel doc
> > should be in the kernel source or not. If the answer is 'no', then I
> > fully support making it a URL, or printing it out the back of
> > phonebooks, or whatever means of distribution :)
>
> i really tried to remain out of this. in theory, like Linus said, we
> should not even know that he's using bk. it should be completely hidden.
> the only method described inside the kernel tarbal should be the
> old diff+patch one. main maintainers ( i mean the group of at most 10 that
> are handling huge number of patches and that are highly interacting with
> Linus ) will very likely get benefits from using bk instead of diff+patch,
> but for these one no doc is necessary. either they know or Larry can
> provide them with all the docs they need. for all the remaining crew, bk
> adoption is simply a trend followup.
Nope, the kernel doc was created precisely for the kernel maintainers,
cuz most of them (like me) had no clue about how to use BK nicely
for the kernel. Honestly, we were all lazy (except the PPC guys
and GregKH, I guess :)) and let Linus figure out kernel development
under BK.
If we attempt to pretend that BK is not widely usage, you do a
dissservice to other kernel developers, sysadmins, and power users --
and possibly _increase_ the barrier to entry of the "group of at most
10" you describe above.
That "10" does not need do, and should never be, an exclusive club...
it just sorta evolved over time as the people who work best with
Linus. I want to spread knowledge about working well with Linus
as far and as wide as possible -- that benefits all Linux users,
and open source overall.
I think I have proven that I am working towards that goal, of
publishing "Linus knowledge" -- I wrote not only the BK version of
Doc/SubmittingPatches, but also Doc/SubmittingPatches itself.
Let the knowledge out there, and let people make their own decisions...
Jeff
On Sun, Apr 21, 2002 at 11:37:29PM +0200, Daniel Phillips wrote:
> I just don't support the part that turns Documentation
> into a billboard.
Can we agree, that this is a fundamental disagreement you and I (and
others) will never agree on?
I see helpful documentation was added to the kernel sources to be more helpful.
You see an advertisement.
Would that be an accurate assessment of a main point of this thread?
Jeff
Hi,
Sorry, I haven't checked email for a while. Putting this into an
external readme file might still leave some people complaining,
but if you wish I could do that either.
The last version was more or less a cut and paste from Larry, this one is
a little edited...
Regards,
Thunder
diff -u bk-kernel-howto.txt~ bk-kernel-howto.txt
--- bk-kernel-howto.txt~ Mon Apr 22 16:11:37 2002
+++ bk-kernel-howto.txt Mon Apr 22 16:15:35 2002
@@ -15,6 +15,15 @@
"bk help <command>" or in X "bk helptool <command>" for reference
documentation.
+ Also notice that BitKeeper is not free software. You may use it
+ for free, subject to the licensing rules you can download from
+ <URL:http://www.bitkeeper.com/manpages/bk-blk-1.html>, but it is
+ not open source. If you feel strongly about 100% free software
+ tool chain, then don't use BitKeeper. Linus has made very clear
+ 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.
BitKeeper Concepts
------------------
--
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.
On Mon, Apr 22, 2002 at 04:31:15PM -0600, Thunder from the hill wrote:
> Hi,
>
> Sorry, I haven't checked email for a while. Putting this into an
> external readme file might still leave some people complaining,
> but if you wish I could do that either.
> The last version was more or less a cut and paste from Larry, this one is
> a little edited...
What I'll do is take this and some of stuff sent to me privately
(spelling correction, peer review stuff) and update that. I will
probably reword your intro here.
A README in that dir might not be a bad idea, but it (like the other
docs) will actually be useful. It will include the "BK disclaimer" as
well as other stuff.
Jeff
On Mon, Apr 22, 2002 at 05:45:41PM -0400, Alexander Viro wrote:
> Daniel, if you will ever get a legitimate reason to send me mail -
> try to convince somebody sane to forward it. I'm serious - taking
> you out of killfile was a bad mistake and I'm not going to repeat
> it.
In 19 years of being on mailing lists, this is the first and
only time I've actually implemented a killfile. Kind of sad,
but I can't say that I (or anyone else) am/is going to miss
me rising to Daniel's baiting.
> *PLONK*
Indeed.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 22 Apr 2002, Jeff Garzik wrote:
> On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> > On Mon, 22 Apr 2002, Jeff Garzik wrote:
> >
> > > The real question, as I understand it, is whether or not the kernel doc
> > > should be in the kernel source or not. If the answer is 'no', then I
> > > fully support making it a URL, or printing it out the back of
> > > phonebooks, or whatever means of distribution :)
> >
> > i really tried to remain out of this. in theory, like Linus said, we
> > should not even know that he's using bk. it should be completely hidden.
> > the only method described inside the kernel tarbal should be the
> > old diff+patch one. main maintainers ( i mean the group of at most 10 that
> > are handling huge number of patches and that are highly interacting with
> > Linus ) will very likely get benefits from using bk instead of diff+patch,
> > but for these one no doc is necessary. either they know or Larry can
> > provide them with all the docs they need. for all the remaining crew, bk
> > adoption is simply a trend followup.
>
> Nope, the kernel doc was created precisely for the kernel maintainers,
> cuz most of them (like me) had no clue about how to use BK nicely
> for the kernel. Honestly, we were all lazy (except the PPC guys
> and GregKH, I guess :)) and let Linus figure out kernel development
> under BK.
>
> If we attempt to pretend that BK is not widely usage, you do a
> dissservice to other kernel developers, sysadmins, and power users --
> and possibly _increase_ the barrier to entry of the "group of at most
> 10" you describe above.
>
> That "10" does not need do, and should never be, an exclusive club...
> it just sorta evolved over time as the people who work best with
> Linus. I want to spread knowledge about working well with Linus
> as far and as wide as possible -- that benefits all Linux users,
> and open source overall.
Jeff, did you really mean this ?
"If we attempt to pretend that BK is not widely usage ..."
It did not seem to me that Linus required BK to interact with him. So to
be or not to be inside the above group does not depend at all from BK
usage. BK can make life a lot easier for guys handling huge number of
patches with complex hierarchies, but forcing the one working with 1-5
patches to use it, it reflects the "trend followup" i was talking about.
- Davide
On Mon, Apr 22, 2002 at 04:22:29PM -0700, Davide Libenzi wrote:
> On Mon, 22 Apr 2002, Jeff Garzik wrote:
>
> > On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> > > On Mon, 22 Apr 2002, Jeff Garzik wrote:
> > >
> > > > The real question, as I understand it, is whether or not the kernel doc
> > > > should be in the kernel source or not. If the answer is 'no', then I
> > > > fully support making it a URL, or printing it out the back of
> > > > phonebooks, or whatever means of distribution :)
> > >
> > > i really tried to remain out of this. in theory, like Linus said, we
> > > should not even know that he's using bk. it should be completely hidden.
> > > the only method described inside the kernel tarbal should be the
> > > old diff+patch one. main maintainers ( i mean the group of at most 10 that
> > > are handling huge number of patches and that are highly interacting with
> > > Linus ) will very likely get benefits from using bk instead of diff+patch,
> > > but for these one no doc is necessary. either they know or Larry can
> > > provide them with all the docs they need. for all the remaining crew, bk
> > > adoption is simply a trend followup.
> >
> > Nope, the kernel doc was created precisely for the kernel maintainers,
> > cuz most of them (like me) had no clue about how to use BK nicely
> > for the kernel. Honestly, we were all lazy (except the PPC guys
> > and GregKH, I guess :)) and let Linus figure out kernel development
> > under BK.
> >
> > If we attempt to pretend that BK is not widely usage, you do a
> > dissservice to other kernel developers, sysadmins, and power users --
> > and possibly _increase_ the barrier to entry of the "group of at most
> > 10" you describe above.
> >
> > That "10" does not need do, and should never be, an exclusive club...
> > it just sorta evolved over time as the people who work best with
> > Linus. I want to spread knowledge about working well with Linus
> > as far and as wide as possible -- that benefits all Linux users,
> > and open source overall.
>
> Jeff, did you really mean this ?
>
> "If we attempt to pretend that BK is not widely usage ..."
>
> It did not seem to me that Linus required BK to interact with him. So to
> be or not to be inside the above group does not depend at all from BK
> usage. BK can make life a lot easier for guys handling huge number of
> patches with complex hierarchies, but forcing the one working with 1-5
> patches to use it, it reflects the "trend followup" i was talking about.
If you read that from what I wrote, you are mistaken...
I'm saying that removing the BK doc from the kernel sources removes
description of one, _optional_ avenue to Linus. That is denying
people information.
Which is completely contrary to one of my goals, spreading knowledge
about working with Linus to decrease the barrier of entry.
BK is not a requirement, even for regular submittors. Optional.
Jeff
Once upon a time, Daniel Phillips <[email protected]> said:
>Would everybody with no mouse on their system please stand up, and leave
>the room.
>
>Seriously, you're trolling.
Would everyone that complains about 11Kb (4683 bytes bzip2 compressed)
when downloading 144Mb (26Mb bzip2 compressed) please stand up, and leave
the room.
Seriously, you're trolling.
BTW: why no rightous indignation about the "Hideous Commercial Pitch" in
fs/reiserfs/README? Code in that directory is dual licensed under the
GPL and a strictly commercial license, similar to BK, and is actually
_included_ with the kernel, as opposed to BK which is merely useful with
the kernel.
--
Chris Adams <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
On Sun, Apr 21, 2002 at 08:16:28PM +0200, Daniel Phillips wrote:
> 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.
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
On Apr 23, 2002 14:57 +1000, Andre Pang wrote:
> 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:
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/
Daniel Phillips wrote:
> 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.
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
On Tuesday 23 April 2002 08:04, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > 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.
>
> 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?
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.
> That would be pretty useful.
>
> An uber-feature would be "notify me if the VFS interface or locking
> rules change", for version 2 perhaps ;-)
Challenging, but doable. It's a database + command interface problem, and of
course, coding resource problem. Did you have a framework in mind?
--
Daniel
On Tuesday 23 April 2002 08:04, Jamie Lokier wrote:
> An uber-feature would be "notify me if the VFS interface or locking
> rules change", for version 2 perhaps ;-)
I see Rasmus is on the job, I'll defer.
--
Daniel
On Mon, Apr 22, 2002 at 12:47:08PM +0200, Daniel Phillips wrote:
> On Tuesday 23 April 2002 08:04, Jamie Lokier wrote:
> > An uber-feature would be "notify me if the VFS interface or locking
> > rules change", for version 2 perhaps ;-)
>
> I see Rasmus is on the job, I'll defer.
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
On Tuesday 23 April 2002 06:57, Andre Pang wrote:
> On Sun, Apr 21, 2002 at 08:16:28PM +0200, Daniel Phillips wrote:
> 11. Pulling BK doc in the tree would make less users aware of
> BK and thus solve most of these problems
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.
> 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.
Yes, that would help.
> 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.
Too much 'automatic' traffic for lkml, however something similar is
being worked on by the patchbot group.
> 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.
Yes.
> 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.
Right, linux-patches, with a view to providing notification of
*proposed* patches before they become formally part of a tree.
> 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.
Probably. A deeper fix is needed, indeed.
> 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.
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.
> 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.
Thanks for your advice.
Hopefully this is the end of the thread.
--
Daniel
>>>>> "Larry" == Larry McVoy <[email protected]> writes:
Larry> On Sun, Apr 21, 2002 at 01:48:51PM -0400, Jeff Garzik wrote:
>> Can you get the bkbits.net interface to spit out text/plain
>> GNU-style patches?
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
Hi,
On Mon, 22 Apr 2002, Jeff Garzik wrote:
> I have my terminology straight. Everyone have some amount of core
> ideology, I imagine. I was illustrating cause and effect, with the
> above statement.
>
> Ideology is a good thing. If you believe in something, fight for it.
~$ dict ideology
2 definitions found
>From The Collaborative International Dictionary of English v.0.44
[gcide]:
[...]
3. A set or system of theories and beliefs held by an
individual or group, especially about sociopolitical goals
and methods to attain them; in common usage, ideology is
such a set of beliefs so strongly held by their adherents
as to cause them to ignore evidence against such beliefs,
and thus fall into error -- in this sense it is viewed as
a negative trait; contrasted to {pragmatism}, and distinct
from idealism.
[PJC]
[...]
What you're talking about are believes and idealism.
> Read up on censorship. It doesn't have to be private to be censorship.
> In fact, it usually isn't.
>
> Fact: GPL'd BK document contains speech Daniel doesn't like
> Fact: Daniel tried to remove doc because he dislikes its contents
>
> Interpret the facts however you wish.
dict censor
2 definitions found
[...]
censor
n : a person who is authorized to read publications or
correspondence or to watch theatrical performances and
suppress in whole or in part anything considered obscene
or politically unacceptable
v 1: forbid the public distribution of; as of movies or
newspapers [syn: {ban}]
2: subject to political, religious, or moral censorship; "This
magazine is censored by the government"
Daniel did clearly state that he wants the documents to be moved, not to
be banned completely.
I grew up in a country, where censorship was very real. I know how it
feels to learn only afterwards what really happened. Believe I'm very
sensitive when it comes to censorship, but Daniels action comes nowhere
close.
> Nobody should feel forced or coerced into using BK, and we should
> actively combat this notion.
>
> I wonder if we can agree, as well, that no one should feel forced or
> coerced into _not_ using BK, also. Do you agree?
I have no problem with that and nobody is demanding that.
> But to be honest, I _do_ feel that Daniel was being a fanatic.
> That's an opinion, and I'm sure some people disagree.
Daniel got lost in defending mutiple position, what is already difficult
enough in a calm discussion. On the other hand you and Larry were pushing
him into a specific corner with hardly let him a chance to get out of it
(especially Larry has a talent for that, as I know from my own
experience). Daniel has some very important points, but his argumentation
was just lousy.
> Free speech is all about letting someone else that you _disagree_ with
> air their opinion. Daniel's patch was not about that principle at all.
Free speech is really not at danger here. The problem is something
completely different. Linux is still a free software project and the
question is how seriously do we take this? Do we want to promote free
software or nonfree software? I assume that most people here enjoy working
on Linux and the free exchange of ideas and the GPL ensures that it stays
that way. So how does an endorsement for nonfree software fit in here? You
promote a software, which you can't simply modify to your needs and where
any improvement you make, is owned by someone else.
What Larry does with the result of his work is alone his decision, what
tools you use is also your decision, but what position should we take as a
Linux community? What is more important, freedom or convenience?
bye, Roman
On Tue, Apr 23, 2002 at 03:49:50PM +0200, Roman Zippel wrote:
> Free speech is really not at danger here. The problem is something
> completely different. Linux is still a free software project and the
> question is how seriously do we take this?
You might stop and ask yourself how the people who work on this free
software project pay the bills. I remember a recent converation with
Daniel where I said "if you work there, your work won't be GPLed" and
he replied "No problem". It's interesting how quickly he lost his GPL
rules when he wanted a job. Are you any different? Is anyone any
different? Obviously, everyone needs to eat. So how many people are
doing development on something which is not GPLed in order to pay the
bills so they can eat and still contribute to something which is GPLed?
Most of the people here, right?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Tue, Apr 23, 2002 at 08:10:28AM -0400, Jes Sorensen wrote:
> >>>>> "Larry" == Larry McVoy <[email protected]> writes:
>
> Larry> On Sun, Apr 21, 2002 at 01:48:51PM -0400, Jeff Garzik wrote:
> >> Can you get the bkbits.net interface to spit out text/plain
> >> GNU-style patches?
>
> 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?
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
On Tue, 23 Apr 2002, Roman Zippel wrote:
> Free speech is really not at danger here. The problem is something
> completely different. Linux is still a free software project and the
> question is how seriously do we take this?
IMHO Linux would stop being a free software project the moment
we start telling Linus what he can and can't distribute in his
copy of the kernel.
Freedom includes the freedom for people to promote an opinion
that isn't the same as yours.
regards,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
>>>>> "Larry" == Larry McVoy <[email protected]> writes:
Larry> On Tue, Apr 23, 2002 at 08:10:28AM -0400, Jes Sorensen wrote:
>> 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?
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
On Tue, Apr 23, 2002 at 11:07:28AM -0400, Jes Sorensen wrote:
> 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.
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
Hi,
On Tue, 23 Apr 2002, Larry McVoy wrote:
> > Free speech is really not at danger here. The problem is something
> > completely different. Linux is still a free software project and the
> > question is how seriously do we take this?
>
> You might stop and ask yourself how the people who work on this free
> software project pay the bills.
That's a decision everyone has to do for himself. Nobody blames you for
working on nonfree software, but everyone working on Linux should be aware
of what it stands for.
bye, Roman
On Tue, Apr 23, 2002 at 05:13:25PM +0200, Roman Zippel wrote:
> > > Free speech is really not at danger here. The problem is something
> > > completely different. Linux is still a free software project and the
> > > question is how seriously do we take this?
> >
> > You might stop and ask yourself how the people who work on this free
> > software project pay the bills.
>
> That's a decision everyone has to do for himself. Nobody blames you for
> working on nonfree software, but everyone working on Linux should be aware
> of what it stands for.
You're missing the point. Most of the people here do exactly what I do,
they work on something else in order to be able to contribute to Linux.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Tuesday 23 April 2002 16:51, Larry McVoy wrote:
> On Tue, Apr 23, 2002 at 03:49:50PM +0200, Roman Zippel wrote:
> > Free speech is really not at danger here. The problem is something
> > completely different. Linux is still a free software project and the
> > question is how seriously do we take this?
>
> You might stop and ask yourself how the people who work on this free
> software project pay the bills. I remember a recent converation with
> Daniel where I said "if you work there, your work won't be GPLed" and
> he replied "No problem". It's interesting how quickly he lost his GPL
> rules when he wanted a job.
Larry, it's a low blow and I resent it. Retraction please.
Since you are smug about that, please inquire what my actual position is
with regard to upholding the GPL. You know who to ask.
--
Daniel
Hi,
On Tue, 23 Apr 2002, Rik van Riel wrote:
> > Free speech is really not at danger here. The problem is something
> > completely different. Linux is still a free software project and the
> > question is how seriously do we take this?
>
> IMHO Linux would stop being a free software project the moment
> we start telling Linus what he can and can't distribute in his
> copy of the kernel.
We are telling him that all the time, it's another question whether he
listens to us and so far he was very good at listening to us. If Linus
would stop doing this, he would risk a fork. If that happened, the project
would continue, although weakened.
> Freedom includes the freedom for people to promote an opinion
> that isn't the same as yours.
Do you have to promote the opinion of other people? What happens if you
promote an opinion, which conflicts with your action?
bye, Roman
Hi,
On Tue, 23 Apr 2002, Larry McVoy wrote:
> > That's a decision everyone has to do for himself. Nobody blames you for
> > working on nonfree software, but everyone working on Linux should be aware
> > of what it stands for.
>
> You're missing the point. Most of the people here do exactly what I do,
> they work on something else in order to be able to contribute to Linux.
Then you should ask yourself, why you are doing it.
bye, Roman
On Tue, Apr 23, 2002 at 05:35:40PM +0200, Roman Zippel wrote:
> > > That's a decision everyone has to do for himself. Nobody blames you for
> > > working on nonfree software, but everyone working on Linux should be aware
> > > of what it stands for.
> >
> > You're missing the point. Most of the people here do exactly what I do,
> > they work on something else in order to be able to contribute to Linux.
>
> Then you should ask yourself, why you are doing it.
Just out of curiousity, how do you make a living Roman?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hi,
On Tue, 23 Apr 2002, Larry McVoy wrote:
> > > You're missing the point. Most of the people here do exactly what I do,
> > > they work on something else in order to be able to contribute to Linux.
> >
> > Then you should ask yourself, why you are doing it.
>
> Just out of curiousity, how do you make a living Roman?
How is that important? Am I to be judged now?
bye, Roman
PS: If you would be just curious, you could have also asked privately and
then I would have told you.
On Tue, Apr 23, 2002 at 08:12:39AM -0700, Larry McVoy wrote:
> 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.
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.
On Mon, 22 Apr 2002, Daniel Phillips wrote:
> On Tuesday 23 April 2002 16:51, Larry McVoy wrote:
> > You might stop and ask yourself how the people who work on this free
> > software project pay the bills. I remember a recent converation with
> > Daniel where I said "if you work there, your work won't be GPLed" and
> > he replied "No problem". It's interesting how quickly he lost his GPL
> > rules when he wanted a job.
>
> Larry, it's a low blow and I resent it. Retraction please.
Come on, you've already shown in this thread that you retract
your own statements every time the thread takes a turn.
I guess I'll state for the record that I don't object to idealists,
it's armchair idealists I resent.
The kind of people who want to impose a view of the world on
others that they'd never impose on themselves, the kind of
people who preach free software but work for a distro that
includes non-free software, the kind of people who want to
retroactively change their statements whenever they are
inconvenienced by them.
You know who you are.
regards,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
On Tue, 23 Apr 2002, Roman Zippel wrote:
> On Tue, 23 Apr 2002, Larry McVoy wrote:
>
> > > > You're missing the point. Most of the people here do exactly what I do,
> > > > they work on something else in order to be able to contribute to Linux.
> > >
> > > Then you should ask yourself, why you are doing it.
> >
> > Just out of curiousity, how do you make a living Roman?
>
> How is that important? Am I to be judged now?
If you're not willing to be judged according to the standards
you try to impose on Larry, how serious do you expect us to
take you ?
regards,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
Hi,
On Tue, 23 Apr 2002, Rik van Riel wrote:
> If you're not willing to be judged according to the standards
> you try to impose on Larry, how serious do you expect us to
> take you ?
Huh? What standards do I try to impose on him???
bye, Roman
Hi,
On Tue, 23 Apr 2002, Rik van Riel wrote:
> I guess I'll state for the record that I don't object to idealists,
> it's armchair idealists I resent.
>
> The kind of people who want to impose a view of the world on
> others that they'd never impose on themselves, the kind of
> people who preach free software but work for a distro that
> includes non-free software,
Are you trying to start some sort of PC-contest "Who is the real
idealists?" here?
bye, Roman
Hi!
> > How about a URL instead? Any objection?
>
> 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
And why should I waste my disk space with BK docs?
When they are on website, they can be easily updated, and they don't waste
space/bandwidth for people that do not care. As BK only makes sense if you
have good connection to the Net, its more easily put on web page than other
docs (other docs is mostly usefull even for people without net).
So IMO bk docs should go to website somewhere.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> > The well-defined resync points are the 2.5.N releases. If -pre goes away,
> > then the dot-releases might need to come a little closer together, that's all.
>
> I agree.
>
> I've told myself that I shouldn't have done "-preX" releases at all in
> 2.5.x - the "real" numbers have become diluted by them, and I suspect the
> -pre's are really just because I got used to making them during the
> over-long 2.4.x time.
I believe -pre's are still important. Daily snapshots are too likely to be
broken, and "real" releases are different from -pre ones (with *usefull*
difference): you can ignore -pre release, but you can't ignore real release
(because real releases are relative to each other).
Having slightly more frequent real releases would be nice, but I believe
it is not feasible to make them as common as pre- patches.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Sun, 21 Apr 2002, Pavel Machek wrote:
> > > How about a URL instead? Any objection?
> >
> > 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
>
> And why should I waste my disk space with BK docs?
Because they're useful for many people.
It's easy to rephrase that question to:
"Why should I waste my disk space with SCSI drivers?"
"Why should I waste my disk space with MIPS support?"
"Why should I waste my disk space with bluetooth drivers?"
In each of these cases you'll get the same answer that I gave
to your question.
regards,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
>> > The well-defined resync points are the 2.5.N releases. If -pre goes away,
>> > then the dot-releases might need to come a little closer together, that's all.
>>
>> I agree.
>>
>> I've told myself that I shouldn't have done "-preX" releases at all in
>> 2.5.x - the "real" numbers have become diluted by them, and I suspect the
>> -pre's are really just because I got used to making them during the
>> over-long 2.4.x time.
>
> I believe -pre's are still important. Daily snapshots are too likely to be
> broken, and "real" releases are different from -pre ones (with *usefull*
> difference): you can ignore -pre release, but you can't ignore real release
> (because real releases are relative to each other).
Pavel, I think it is an delusion. In practical terms we have
a string of -pre and traditional releases which differ really
little in terms of reliability. I number of 2.5.x without -pre
fail to compile different non-core modules. 2.5.9 hangs on boot
on my machine, while -preX worked.
Marcelo pays more attention to stabilizing suffixless releases,
and as well he should. However, I do not see how this can
be meaningfuly done in 2.5.x. I am not going to shed any tears
over the demise of -pre in unstable series, provided that
releases get spaced tighter, with smaller patch size between them.
-- Pete
On Sun, 21 Apr 2002, Pavel Machek wrote:
>
> I believe -pre's are still important. Daily snapshots are too likely to be
> broken, and "real" releases are different from -pre ones (with *usefull*
> difference): you can ignore -pre release, but you can't ignore real release
> (because real releases are relative to each other).
Considering how even real releases in the development tree are likely to
be broken (never mind the _trivial_ brokenness of applying the same patch
to init/main.c twice, I'm talking about the more fundamental brokenness of
just broken drivers and filesystems due to development), I'm not sure how
big a deal that is.
And I do make full tar-files of real releases, so that people can skip a
few (although unless you have a fast connection it usually only makes
sense after 10 full releases or so).
> Having slightly more frequent real releases would be nice, but I believe
> it is not feasible to make them as common as pre- patches.
I'll try to keep them coming a bit more often.
Linus
[email protected] said:
> 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.
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
On Wed, Apr 24, 2002 at 10:03:31AM +0100, David Woodhouse wrote:
> 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.
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
Rik van Riel Awoke this dragon, who will now respond:
>
> "Why should I waste my disk space with SCSI drivers?"
> "Why should I waste my disk space with MIPS support?"
> "Why should I waste my disk space with bluetooth drivers?"
>
> In each of these cases you'll get the same answer that I gave
> to your question.
Actually, I dont get that.
Why SHOULD I download ten different architectures when I only want two (ARM
and X86).?
Why SHOULD I download SCSI when I dont use anything but IDE? (cost reasons)
Why SHOULD I download bluetooth stuff when I will probably wont own a
bluetooth device in the near future?
Why dont you try to provide a satisfactory answer to those questions
instead of avoiding them and turning them around?
Here is my answer for the record:
I shouldnt. its a pointless waste of bandwidth.
Now, whats YOUR answer?
Especially in light of the 2.5 kernel becomming ever more modular.
On Thu, Apr 25, 2002 at 04:51:20AM +0100, Ian Molton wrote:
>[usual I-want-to-download-only-what-I-use rant]
> Here is my answer for the record:
>
> I shouldnt. its a pointless waste of bandwidth.
>
> Now, whats YOUR answer?
Developpers need complete sources. No questions about that. If they
don't have the complete sources, they'll fuck things up. So the
developpers have zero use for partial downloadings.
Some users may like to be able to download only the core code and
drivers/filesystems/architectures they use. Ignoring the obvious
version drift problems that will happen, proposing such a service
requires work and a large amount of bandwidth. Do you volunteer?
OG.
Olivier Galibert Awoke this dragon, who will now respond:
> > I shouldnt. its a pointless waste of bandwidth.
> >
> > Now, whats YOUR answer?
>
> Developpers need complete sources. No questions about that. If they
> don't have the complete sources, they'll fuck things up. So the
> developpers have zero use for partial downloadings.
Sorry, that doesnt fly. If I dont work on SCSI, only on networking, I
/dont/ need the SCSI code. Even if I had it, I wouldnt read it.
I deleted all the arch directories except ARM and X86 on my machine to
speed up grepping the kernel.
so, not having all the source can speed thigs up.
> Some users may like to be able to download only the core code and
> drivers/filesystems/architectures they use.
This developer would too.
> Ignoring the obvious
> version drift problems that will happen,
Why would they happen?
> proposing such a service
> requires work and a large amount of bandwidth. Do you volunteer?
Surely it requires LESS bandwidth than if people are sucking the WHOLE
kernel ?
[email protected] said:
> Why SHOULD I download ten different architectures when I only want two
> (ARM and X86).? Why SHOULD I download SCSI when I dont use anything
> but IDE? (cost reasons) Why SHOULD I download bluetooth stuff when I
> will probably wont own a bluetooth device in the near future?
> Why dont you try to provide a satisfactory answer to those questions
> instead of avoiding them and turning them around?
Linus has categorically stated that he will not split up the kernel sources.
The GPL gives you the freedom to fork the kernel and do so if you wish.
Please do not continue this pointless debate here. You will not achieve
anything which was not achieved in all the other numerous times some troll
has brought it up.
Do, or do not. There is no troll.
--
dwmw2
> [email protected] said:
> > Why SHOULD I download ten different architectures when I only want two
> > (ARM and X86).? Why SHOULD I download SCSI when I dont use anything
> > but IDE? (cost reasons) Why SHOULD I download bluetooth stuff when I
> > will probably wont own a bluetooth device in the near future?
>
> > Why dont you try to provide a satisfactory answer to those questions
> > instead of avoiding them and turning them around?
Why don't you Read The Fucking FAQ???!!!???
http://www.tux.org/lkml/#s7-7
For someone who's so concerned about bandwidth, why didn't you read
the FAQ first? You would have seen that this question is already
answered and should not be asked on the list, and you would have saved
developer bandwidth. With your post, a large number of busy people had
to download your email, read it, process it and reach the conclusion
"Luser asking repeat, dumb and useless question. Remember to ignore in
future". That wastes people's time. And it's not even in your best
interests.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Thu, 25 Apr 2002, Ian Molton wrote:
> Rik van Riel Awoke this dragon, who will now respond:
>
> >
> > "Why should I waste my disk space with SCSI drivers?"
> > "Why should I waste my disk space with MIPS support?"
> > "Why should I waste my disk space with bluetooth drivers?"
> >
> > In each of these cases you'll get the same answer that I gave
> > to your question.
>
> Actually, I dont get that.
[snip "Couldn't the kernel be split in various tarballs?"]
> Here is my answer for the record:
>
> I shouldnt. its a pointless waste of bandwidth.
>
> Now, whats YOUR answer?
You'll find the answer in the lkml FAQ:
http://www.tux.org/lkml/#s7-7
cheers,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
[email protected] (Doug Ledford) wrote on 22.04.02 in <[email protected]>:
> On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 21:53, Doug Ledford wrote:
> > > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > > How about a URL instead? Any objection?
> > >
> > > Yes. Why should I have to cut and paste (assuming I'm in X) or
> > > write down
> >
> > What??? What kind of system are you running? Err... redhat supports
> > cut and paste I thought. <-- funnny.
>
> 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.
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.
> real docs, switch to X or install lynx on my system, go to URL. It's a
You don't have lynx installed on a development machine?! *boggle*
How about links? W3m? Hell, wget?
> 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.
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
On Mon, 22 Apr 2002, Ian Molton wrote:
> Jeff Garzik Awoke this dragon, who will now respond:
>
> > If Linus had applied your patch, there would be a lag time during which
> > the doc would have no home at all.
>
> He merely provided the patch. he didnt try to force it through in a
> hurry, which left plenty of time for relocation in the meantime.
You're volunteering ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Larry McVoy writes:
> On Sun, Apr 21, 2002 at 06:21:27PM +0200, Daniel Phillips wrote:
> > > It's not my call to make.
> >
> > I know that. I was wondering if *you personally* would have any objection.
>
> 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.
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,
On Sat, 27 Apr 2002, Richard Gooch wrote:
> I've added two subsections to the FAQ about this, which I hope will
> avoid some future flamewars:
> http://www.tux.org/lkml/#s1-21
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
On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> 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
> it's better that those who feel stronly about it
^^^^^^^--------- typo
--
Daniel
On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> 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
Perhaps the message would be more credible if this were toned down:
no matter how loud or how many times you scream,
--
Daniel
On Sat, Apr 27, 2002 at 12:59:17PM -0600, Richard Gooch wrote:
> 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
Looks good, nice addition, thanks.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Roman Zippel writes:
> Hi,
>
> On Sat, 27 Apr 2002, Richard Gooch wrote:
>
> > I've added two subsections to the FAQ about this, which I hope will
> > avoid some future flamewars:
> > http://www.tux.org/lkml/#s1-21
>
> You should fix the first paragraph, read
You should learn to not say "you should" but instead "I suggest".
> http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
> free software is.
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.
> "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.
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]
Daniel Phillips writes:
> On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> > 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
>
>
> > it's better that those who feel stronly about it
> ^^^^^^^--------- typo
Bugger! Thanks.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Daniel Phillips writes:
> On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> > 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
>
> Perhaps the message would be more credible if this were toned down:
>
> no matter how loud or how many times you scream,
Actually, those words were carefully chosen. There *has* been a lot of
repeated shouting about this topic. I want to highlight the stupidity
and futility of dragging the list through another pointless flamewar.
I've used similar language elsewhere in the FAQ for other repeat
flamewars or pointless debates.
The bottom line is: no matter how many times you scream, Linus won't
change his mind because of the BK licence. The FAQ entry is accurate.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sun, 28 Apr 2002, Richard Gooch wrote:
>
> > http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
> > free software is.
>
> OK, I'll add this link
Please don't.
I don't want a kernel howto quoting the FSF.
Linus
Linus Torvalds writes:
>
>
> On Sun, 28 Apr 2002, Richard Gooch wrote:
> >
> > > http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
> > > free software is.
> >
> > OK, I'll add this link
>
> Please don't.
>
> I don't want a kernel howto quoting the FSF.
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]
28/4/2002 15:47:43, Richard Gooch <[email protected]> wrote:
>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.
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.
On Sun, 28 Apr 2002, Kiss The Blade wrote:
> 28/4/2002 15:47:43, Richard Gooch <[email protected]> wrote:
>
> >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.
>
> I think Linus actually does not want to endorse the FSF stance about how
> software must be ethically correct.
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
28/4/2002 16:27:09, Linus Torvalds <[email protected]> wrote:
>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.
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.
Linus Torvalds writes:
>
>
> On Sun, 28 Apr 2002, Kiss The Blade wrote:
> > 28/4/2002 15:47:43, Richard Gooch <[email protected]> wrote:
> >
> > >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.
> >
> > I think Linus actually does not want to endorse the FSF stance about how
> > software must be ethically correct.
>
> 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.
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.
> 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.
No, we're the Libertarian Front for the People of Judea. Get it right.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Kiss The Blade writes:
> 28/4/2002 16:27:09, Linus Torvalds <[email protected]> wrote:
>
> >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.
>
> 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 ;)
Just nuke him from orbit. It's the only way to be sure.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
> 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.
"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,
Richard Gooch wrote:
> 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.
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
Hi,
Linus Torvalds wrote:
> I don't want a kernel howto quoting the FSF.
Would you please explain then, what you want?
bye, Roman
28/4/2002 17:11:05, Roman Zippel <[email protected]> wrote:
>Linus Torvalds wrote:
>
>> I don't want a kernel howto quoting the FSF.
>
>Would you please explain then, what you want?
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>:
> 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.
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>:
> 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.
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
Linus Torvalds <[email protected]> writes:
> 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".
Some might call that an ideology itself...
--
greg