Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Andi Kleen]

Andrew Morton <akpm@zip.com.au> writes:

> The Open Source Club at The Ohio State University wrote:
> > 
> > [ succinctness ]
> >
> 
> fwiw, I prefer to not use bitkeeper, for the reasons which
> you outline.

I also prefer not to use Bitkeeper as long as possible for similar reasons 
and because it is too slow and clumpsy 
(although it is already very hard because often source is only available 
through it, e.g. for ppc or for 2.5 pre patches now -- hopefully this trend
does not continue)

-Andi

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Dave Jones]

On Wed, Mar 06, 2002 at 10:40:44AM +0100, Andi Kleen wrote:
 > I also prefer not to use Bitkeeper as long as possible for similar reasons 
 > and because it is too slow and clumpsy 
 > (although it is already very hard because often source is only available 
 > through it, e.g. for ppc or for 2.5 pre patches now -- hopefully this trend
 > does not continue)

 Something I've not yet worked out is why none of the proponents of
 arch, subversion etc are offering to run a mirror of Linus'
 bitkeeper tree for those who don't want to use bk, but
 "must have 0-day kernels".

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Paul P Komkoff Jr]

Replying to Dave Jones:
>  Something I've not yet worked out is why none of the proponents of
>  arch, subversion etc are offering to run a mirror of Linus'
>  bitkeeper tree for those who don't want to use bk, but
>  "must have 0-day kernels".

Because they do not want bitkeeper, and do not know how to bk pull & export
WITHOUT bk itself :)

-- 
Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar
  PPKJ1-RIPE // (smtp)i@stingr.net // (http)stingr.net // (pgp)0xA4B4ECA4

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[yodaiken]

On Wed, Mar 06, 2002 at 05:48:49PM +0300, Paul P Komkoff Jr wrote:
> Replying to Dave Jones:
> >  Something I've not yet worked out is why none of the proponents of
> >  arch, subversion etc are offering to run a mirror of Linus'
> >  bitkeeper tree for those who don't want to use bk, but
> >  "must have 0-day kernels".
> 
> Because they do not want bitkeeper, and do not know how to bk pull & export
> WITHOUT bk itself :)

Really, that's too stupid for words. Let them first figure out how to
keep the data from passing through any proprietary routers in the Internet.

The real answer is that they can't do it. 



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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Geert Uytterhoeven]

On 6 Mar 2002, Andi Kleen wrote:
> Andrew Morton <akpm@zip.com.au> writes:
> > The Open Source Club at The Ohio State University wrote:
> > > 
> > > [ succinctness ]
> > >
> > 
> > fwiw, I prefer to not use bitkeeper, for the reasons which
> > you outline.
> 
> I also prefer not to use Bitkeeper as long as possible for similar reasons 
> and because it is too slow and clumpsy 
> (although it is already very hard because often source is only available 
> through it, e.g. for ppc or for 2.5 pre patches now -- hopefully this trend
> does not continue)

The PPC trees are available through rsync as well.

    http://www.penguinppc.org/dev/kernel.shtml

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Roman Zippel]

Hi,

On Wed, 6 Mar 2002, Geert Uytterhoeven wrote:

> > I also prefer not to use Bitkeeper as long as possible for similar reasons 
> > and because it is too slow and clumpsy 
> > (although it is already very hard because often source is only available 
> > through it, e.g. for ppc or for 2.5 pre patches now -- hopefully this trend
> > does not continue)
> 
> The PPC trees are available through rsync as well.
> 
>     http://www.penguinppc.org/dev/kernel.shtml

With rsync you get only the latest version, but not any previous
version. For APUS I have to use bk to extract the ppc tree version I want
to import, for m68k I only have to go to ftp.kernel.org and grab the right
patch.

bye, Roman

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Larry McVoy]

On Wed, Mar 06, 2002 at 03:30:03PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 6 Mar 2002, Geert Uytterhoeven wrote:
> 
> > > I also prefer not to use Bitkeeper as long as possible for similar reasons 
> > > and because it is too slow and clumpsy 
> > > (although it is already very hard because often source is only available 
> > > through it, e.g. for ppc or for 2.5 pre patches now -- hopefully this trend
> > > does not continue)
> > 
> > The PPC trees are available through rsync as well.
> > 
> >     http://www.penguinppc.org/dev/kernel.shtml
> 
> With rsync you get only the latest version, but not any previous
> version. For APUS I have to use bk to extract the ppc tree version I want
> to import, for m68k I only have to go to ftp.kernel.org and grab the right
> patch.

Is the problem that you can't figure out how to extract all the patches
from BK so you can put them up for FTP?  Here, I'll do it for you:

	# extract all the patches from 2.5.0 onward.
	bk prs -hrv2.5.0.. |  while read x
	do	bk export -tpatch -r$i > ~ftp/patches/patch-$i
	done

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Roman Zippel]

Hi,

Larry McVoy wrote:

> Is the problem that you can't figure out how to extract all the patches
> from BK so you can put them up for FTP?  Here, I'll do it for you:

Do it for the ppc guys, not me.

bye, Roman

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Troy Benjegerdes]

On Wed, Mar 06, 2002 at 07:11:54PM +0100, Roman Zippel wrote:
> Hi,
> 
> Larry McVoy wrote:
> 
> > Is the problem that you can't figure out how to extract all the patches
> > from BK so you can put them up for FTP?  Here, I'll do it for you:
> 
> Do it for the ppc guys, not me.
> 
> bye, Roman

You really don't want every changeset as a patch :-/

Please talk to Jeramy, or someone else running penguinppc.org. At one 
point we had patches being generated for every changesets. It got to be 
too much of a headache.

Write some scripts to generage a patch every week or so, and we'll put it 
up.

What I'd really like is some kind of one-way bk->$OTHER_SCM mirror setup 
simply so people can pull stuff out without BK.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Henning P. Schmiedehausen]

Larry McVoy <lm@bitmover.com> writes:

>	# extract all the patches from 2.5.0 onward.
>	bk prs -hrv2.5.0.. |  while read x
>	do	bk export -tpatch -r$i > ~ftp/patches/patch-$i
>	done

[henning@henning henning]$ bk prs -hrv2.5.0.. |  while read x
while: Expression Syntax.

You obviously just _underlined_ the point, Larry.

	Regards
		Henning

It's tcsh; before you ask.
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Mark Mielke]

On Thu, Mar 07, 2002 at 04:51:56PM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <lm@bitmover.com> writes:
> >	# extract all the patches from 2.5.0 onward.
> >	bk prs -hrv2.5.0.. |  while read x
> >	do	bk export -tpatch -r$i > ~ftp/patches/patch-$i
> >	done
> [henning@henning henning]$ bk prs -hrv2.5.0.. |  while read x
> while: Expression Syntax.
> You obviously just _underlined_ the point, Larry.
> ...
> It's tcsh; before you ask.

If you know that the above works only with [zk(ba)]sh, I don't know
what point you would be making by stating that it doesn't work with
tcsh. Put it in a script, and put #!/bin/bash on the top. Now wasn't
that fun?

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Rik van Riel]

On Thu, 7 Mar 2002, Mark Mielke wrote:

> > [henning@henning henning]$ bk prs -hrv2.5.0.. |  while read x
> > while: Expression Syntax.
> > You obviously just _underlined_ the point, Larry.
> > ...
> > It's tcsh; before you ask.
>
> If you know that the above works only with [zk(ba)]sh, I don't know
> what point you would be making by stating that it doesn't work with
> tcsh.

Shhhh, you're ruining the free-software-fans-bash-Larry show.

cheers,

Rik
-- 
<insert bitkeeper endorsement here>

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Matthias Andree]

On Thu, 07 Mar 2002, Henning P. Schmiedehausen wrote:

> [henning@henning henning]$ bk prs -hrv2.5.0.. |  while read x
> while: Expression Syntax.
> 
> You obviously just _underlined_ the point, Larry.
> 
> 	Regards
> 		Henning
> 
> It's tcsh; before you ask.

Flame attractor: No sane person works with [t]csh.

Re: [lkml] Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Ian Soboroff]

Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

> Flame attractor: No sane person works with [t]csh.

Let's see... we've had a SCM flamewar, a license flamewar, an Emacs/VI
taunt or two, a csh/sh taunt, and even Hitler.  Add this to the ESR
flamewar, the devfs flamewar, the odd microkernel LART, and a spam or
three.

If we only had kibo, LKML would be USENET.

(ducks)

ian 
(a fried of whose once sig'ed: "Unencumbered with facts as I am, I
will now comment." -- USENET motto)

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Nicholas Berry]

> tss ..

> by the way, shouldn't it be "$x" in the second line ?
> or am I missing something ?

The latter.

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Jean-Luc Leger]

On Thu, Mar 07, 2002 at 04:51:56PM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <lm@bitmover.com> writes:
> >	# extract all the patches from 2.5.0 onward.
> >	bk prs -hrv2.5.0.. |  while read x
> >	do	bk export -tpatch -r$i > ~ftp/patches/patch-$i
> >	done
> [henning@henning henning]$ bk prs -hrv2.5.0.. |  while read x
> while: Expression Syntax.
> You obviously just _underlined_ the point, Larry.
> ...
> It's tcsh; before you ask.

tss ..

by the way, shouldn't it be "$x" in the second line ?
or am I missing something ?

	JL

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Cort Dougan]

Actually, Larry, you should have been written in python.

} On Thu, Mar 07, 2002 at 04:51:56PM +0000, Henning P. Schmiedehausen wrote:
} > Larry McVoy <lm@bitmover.com> writes:
} > >	# extract all the patches from 2.5.0 onward.
} > >	bk prs -hrv2.5.0.. |  while read x
} > >	do	bk export -tpatch -r$i > ~ftp/patches/patch-$i
} > >	done
} > [henning@henning henning]$ bk prs -hrv2.5.0.. |  while read x
} > while: Expression Syntax.
} > You obviously just _underlined_ the point, Larry.
} > ...
} > It's tcsh; before you ask.
} 
} tss ..
} 
} by the way, shouldn't it be "$x" in the second line ?
} or am I missing something ?
} 
} 	JL
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at  http://www.tux.org/lkml/

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[rddunlap]

| The Open Source Club at The Ohio State University wrote:
| >
| > [ succinctness ]
| > 

| fwiw, I prefer to not use bitkeeper, for the reasons which
| you outline. 

| That's my choice.  Others have made a different one.   I ask that
| they ensure that their choice not inhibit my ability to contribute
| to Linux. 

Well said, Andrew.  And I agree completely. 

 ~Randy 

Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[The Open Source Club at The Ohio State University]

Petition Against Official Endorsement of BitKeeper by Linux Maintainers

We, the undersigned members and officers of the Open Source Club at
the Ohio State University, are unhappy with the advocacy of the
proprietary[1] BitKeeper software for use in maintaining the Linux
kernel.  The Linux kernel is an important symbol of Open Source and
Free Software for many people, and a project in which many thousands
have participated in active development.  It is fine if some kernel
developers choose to use BitKeeper on their own machines, but
officially endorsing proprietary software as the means of working on
the kernel is a large step backwards for Linux, and for the Open
Source and Free Software communities.

If the core Linux maintainers begin to advocate using BitKeeper, then
there will be strong pressure on these peripheral developers to use
BitKeeper too, since it would likely be easier than browsing the
web-exported changelogs or fetching the latest diff from kernel.org.

Using a closed-source, proprietary source control system for the
kernel is even worse than using other forms of proprietary software
such as source code analysis systems, because the revision control
metadata (version numbers, branches, changelog comments, etc.), would
be stored in a format defined by the proprietary software.  This
metadata is really a part of Linux, because people will want to use it
when talking about the kernel.  Those who can't[2] or don't want to
use BitKeeper are left out in the cold.  One of the most important
parts of Open Source and Free Software is that we, the community, are
in control.  But by using and advocating BitKeeper, we would lose part
of that control.

In summary, please do not advocate BitKeeper for use by the general
community.  The Linux development process seems to have worked up till
now, and we can wait a little longer until Arch[3] or Subversion[4]
are completed.  Moreover, full-featured, completely functional free 
versioning sytems are currently available, such as PRCS[5] and CVS[6].
We respect the kernel maintainer's freedom to use proprietary software 
for their own purposes.  And we ask the kernel maintainers to respect 
the community's freedom from entrapment by proprietary software.

-- The Open Source Club at The Ohio State University
Signed by:
Michael Benedict <zosima@zosima.org>
Colin Walters <walters@debian.org>
Matt Curtin <cmcurtin@interhack.net>
Martin Jansche <jansche@ling.ohio-state.edu>
Balbir Thomas <thomas.1037@osu.edu>
Nicholas Hurley <hurley@cis.ohio-state.edu>
Ryan McCormack <mccormac@cis.ohio-state.edu>
Shaun Rowland <rowland@cis.ohio-state.edu>

[1] http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html
[2] Perhaps they aren't connected to the internet regularly enough,
    for instance.
[3] http://www.regexps.com/#arch
[4] http://subversion.tigris.org
[5] http://prcs.sourceforge.net
[6] http://www.cvshome.org

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Andrew Morton]

The Open Source Club at The Ohio State University wrote:
> 
> [ succinctness ]
>

fwiw, I prefer to not use bitkeeper, for the reasons which
you outline.

That's my choice.  Others have made a different one.   I ask that
they ensure that their choice not inhibit my ability to contribute
to Linux.

-

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Troy Benjegerdes]

> In summary, please do not advocate BitKeeper for use by the general
> community.  The Linux development process seems to have worked up till
> now, and we can wait a little longer until Arch[3] or Subversion[4]
> are completed.  Moreover, full-featured, completely functional free 
> versioning sytems are currently available, such as PRCS[5] and CVS[6].
> We respect the kernel maintainer's freedom to use proprietary software 
> for their own purposes.  And we ask the kernel maintainers to respect 
> the community's freedom from entrapment by proprietary software.


First, CVS is COMPLETELY inadequate for the kind of distributed, 
non-centralized development that goes on for the kernel.

Bitkeeper solves some rather difficult problems that *NOTHING ELSE SOLVES* 
right now. This is why I've continued to use it for the last 2 years, even 
though I occasionally get annoyed that it's not free software.

Your efforts on this petition would be FAR better spent (and appreciated) 
by attempting to mirror several BK kernel trees with Arch or Subversion. 
You will soon find out the limitations of both, and maybe even improve 
both projects to the point that they will be useable instead of bitkeeper.

Instead of whining about developers using BK, go out and give us an
alternative. Maybe then we will listen.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Larry McVoy]

On Tue, Mar 05, 2002 at 04:38:09PM -0600, Troy Benjegerdes wrote:
> First, CVS is COMPLETELY inadequate for the kind of distributed, 
> non-centralized development that goes on for the kernel.
> 
> Bitkeeper solves some rather difficult problems that *NOTHING ELSE SOLVES* 
> right now. This is why I've continued to use it for the last 2 years, even 
> though I occasionally get annoyed that it's not free software.
> 
> Your efforts on this petition would be FAR better spent (and appreciated) 
> by attempting to mirror several BK kernel trees with Arch or Subversion. 
> You will soon find out the limitations of both, and maybe even improve 
> both projects to the point that they will be useable instead of bitkeeper.
> 
> Instead of whining about developers using BK, go out and give us an
> alternative. Maybe then we will listen.

This is great, I was about to type in what Troy said.  I had the same
reaction, if CVS/Subversion/Arch were good enough, BitKeeper wouldn't
exist.  The BitKeeper team is about 75% kernel hackers, not SCM people.
If CVS had been good enough, we would all be doing Linux clusters of
some sort, something we hope to get back some day in the distant future.

Troy is right, instead of writing petitions, spend your time by providing
people with options.  Do what he said, mirror the tree into CVS/etc
and you will very quickly learn why CVS/etc have serious problems.
By learning about those problems, you'll either develop some insight
which will aid you in making CVS/etc better, and you'll develop a healthy
respect for what BitKeeper can do.

As for the replacements mentioned, Subversion in particular, the SVN team
admitted before they started that SVN would certainly not be able to do
what BK can do anytime soon, in fact, they admitted it was unlikely to
ever do so.  The reason for that is that they started with a centralized
design and when you try and distribute that, you learn about the zillions
of places where you needed to make a different choice.  It's virtually
impossible to take a centralized SCM system and make it truly distributed
(a TCP connection back to the one CVS server is *not* distributed).

While you are thinking about replacements, it might help to know the
magnitude of what you are discussing.  BitKeeper is a non-trivial project,
it has:
	* close to 200 commands, with about 800 different options.
	* 25,000 lines of regressions, running the full suite wraps
	  16 bit process ids almost twice.
	* more source code written by the BitMover team than all of
	  Version 7 Unix, kernel and userland combined.
	* a dedicated team of full time professional programmers.

More than a year ago, we had some research done to see what it would cost
to reproduce BitKeeper from scratch.  At that point, it was estimated
to be about $12,000,000 and at least 3.5 years from the time a good
team started.

Anyone and everyone is welcome to try and build a better SCM system, just
don't be naive about what it is you are trying to do.  It's a constant
source of frustration and amusement that people think this space is easy.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Kent Borg]

On Tue, Mar 05, 2002 at 04:51:23PM -0800, Larry McVoy wrote:
> BitKeeper is a non-trivial project, it has:
> 	* close to 200 commands, with about 800 different options.

When I was recently doing some PPC work I used Bitkeeper (because PPC
folks do) and I didn't like it.  It was so complicated to use, hell,
seemed like there were 200 commands with 800 options.  And when I
couldn't get it to correctly export a tree I couldn't tell if I was
doing it wrong or it was a bug.

I can appreciate that the problem BK tries to solve is a big one with
subtleties that have to get done right, and, as I type this on my
notebook sitting in front of my work computer, I wish CVS were
distributed.  But I am not convinced BK is as elegant in its design as
it could be, I *know* it is not as elegant in its user interface as it
could be.

I also dislike the irony of BK being proprietary.  Sure, they might
have an enlightened and generous attitude not, but PGP used to be
free, then it became kinda free and then it became orphaned.  Luckily
GPG came along, luckily PGP didn't have a monoploy on our history.


-kb

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Larry McVoy]

On Wed, Mar 06, 2002 at 09:54:34AM -0500, Kent Borg wrote:
> On Tue, Mar 05, 2002 at 04:51:23PM -0800, Larry McVoy wrote:
> > BitKeeper is a non-trivial project, it has:
> > 	* close to 200 commands, with about 800 different options.
> 
> When I was recently doing some PPC work I used Bitkeeper (because PPC
> folks do) and I didn't like it.  It was so complicated to use, hell,
> seemed like there were 200 commands with 800 options.  And when I
> couldn't get it to correctly export a tree I couldn't tell if I was
> doing it wrong or it was a bug.

And apparently you didn't file a bug because I just looked in the bug
database.  Was typing "bk sendbug" too difficult?

> I can appreciate that the problem BK tries to solve is a big one with
> subtleties that have to get done right, and, as I type this on my
> notebook sitting in front of my work computer, I wish CVS were
> distributed.  But I am not convinced BK is as elegant in its design as
> it could be, I *know* it is not as elegant in its user interface as it
> could be.

There are *lots* of things in BK that aren't as good as they could be.
If you want them better, you need to complain about them.

> I also dislike the irony of BK being proprietary.  Sure, they might
> have an enlightened and generous attitude not, but PGP used to be
> free, then it became kinda free and then it became orphaned.  Luckily
> GPG came along, luckily PGP didn't have a monoploy on our history.

PGP didn't have a business model, we do, and part of our business model
is to give it away to some of the world.  It's a good business model,
BK is dramatically better because the PPC team used it and Cort went
through all sorts of stuff as BK improved.  BK would easily be a year
back in terms of usefulness if it weren't for Cort and there is no way
he would have been using it if we charged for it.  We get something by
letting people use it for free.  It's part of our business model and
it works.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Pavel Machek]

Hi!

> > I also dislike the irony of BK being proprietary.  Sure, they might
> > have an enlightened and generous attitude not, but PGP used to be
> > free, then it became kinda free and then it became orphaned.  Luckily
> > GPG came along, luckily PGP didn't have a monoploy on our history.
> 
> PGP didn't have a business model, we do, and part of our business model
> is to give it away to some of the world.  It's a good business model,
> BK is dramatically better because the PPC team used it and Cort went
> through all sorts of stuff as BK improved.  BK would easily be a
> year

So you basically give bk for free because it is good for you. What if
it will stop being good for you ten years from now?

Also it would be nice to apt-get install bk, but your license probably
means we'll not see it in debian any time soon. (Should check, but do
other vendors distribute bk?)
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Troy Benjegerdes]

On Wed, Mar 06, 2002 at 11:13:05PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I also dislike the irony of BK being proprietary.  Sure, they might
> > > have an enlightened and generous attitude not, but PGP used to be
> > > free, then it became kinda free and then it became orphaned.  Luckily
> > > GPG came along, luckily PGP didn't have a monoploy on our history.
> > 
> > PGP didn't have a business model, we do, and part of our business model
> > is to give it away to some of the world.  It's a good business model,
> > BK is dramatically better because the PPC team used it and Cort went
> > through all sorts of stuff as BK improved.  BK would easily be a
> > year
> 
> So you basically give bk for free because it is good for you. What if
> it will stop being good for you ten years from now?

Then we move on to another system. This is why I think we need some kind
of gateway to another SCM. If BK goes away, we could export everything to
tarballs and patches or whatever, but it would be a large PITA, and stop
lots of people's development for awhile. (I've done bk->cvs this way once
before, it was really ugly, and I never want to do it again given the
choice).

I'd really like everyone that's bitching about BK to shut the hell up and
go work on some scripts to allow a maintainer to easily manage a
BK<->$OTHER_SCM gateway. Either give me a working alternative to BK or go
run for political office. Until I see an alternative, I'm going to
continue advocating for real developers to use BK, and complainers to show
me an alternative.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Andrew Morton]

Troy Benjegerdes wrote:
> 
> I'd really like everyone that's bitching about BK to shut the hell up and
> go work on some scripts to allow a maintainer to easily manage a
> BK<->$OTHER_SCM gateway.

ie: "We broke it.  You fix it".

It's not reasonable to expect people who shall not be using bitkeeper
to go off and perform enhancements to bitkeeper so that they can
continue to be effective kernel developers.

If bitkeeper proves to be significantly disadvantageous to non-bitkeeper
developers then it simply is not appropriate that bitkeeper be used
for kernel development at all.

If additional development around bitkeeper is needed then the onus
is upon the bitkeeper side to do that work.  (And yes, there are
sides now).

That being said, I don't see any need for additional development, 
unless people actually want increased functionality over that
which we've traditionally had.  Things generally will appear to
be unchanged for non-bitkeeper users because Linus will continue
to push out the regular prepatches.  This *has* to be done anyway,
so the testers can get at the tree promptly.

Also. The things being discussed here *matter* to some people.  Some
of the comments made by Larry, David, Cort, Rik and others have
coarsely sought to deligitimise the very reasons why a significant number
of kernel contributors and users are here at all.  Those comments
are monumentally insulting.

-

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Larry McVoy]

On Thu, Mar 07, 2002 at 11:54:43AM -0800, Andrew Morton wrote:
> That being said, I don't see any need for additional development, 
> unless people actually want increased functionality over that
> which we've traditionally had.  Things generally will appear to
> be unchanged for non-bitkeeper users because Linus will continue
> to push out the regular prepatches.  This *has* to be done anyway,
> so the testers can get at the tree promptly.
> 
> Also. The things being discussed here *matter* to some people.  Some
> of the comments made by Larry, David, Cort, Rik and others have
> coarsely sought to deligitimise the very reasons why a significant number
> of kernel contributors and users are here at all.  Those comments
> are monumentally insulting.

It's also "monumentally insulting" to be asking for BitKeeper to be able
to do what it already can do, exactly for the reasons you outlined.
We have done piles and piles of work to make sure that we can export
and import patches, so that if you want, your work habits do not change
one iota.  We did all that work.  It's done.  It's in the system.
Linus uses both import and export.  And we continue to fix things as it
becomes apparent that they need to be fixed.  We're busting our asses to
keep you happy and we get flamed.  And the flamers seem to think that
we are getting some great financial benefit by having the kernel crowd
use BK.  It's certainly true that BK is improving because the kernel
crowd demands enhancements.  It's not true that that has turned into
any financial benefit to us, we haven't made a single sale as a result
of Linus using BK.  That's OK, that's not why we did it.  But don't use
that as a justification to beat us up, it's simply not true.

The thing that seems to escape you is that BK came into existence because
I was scared to death of Linus burning out.  I still am.  I see no Linus
replacement on the horizon.  BK exists because I hope it will make him
able to last longer as the leader here, I do not foresee good things
happening if he goes away.  Our goal is to get him more relaxed.  Try and
remember that we are trying to help.  You can hate the fact that BK isn't
open source, I don't blame you one bit.  If I had stayed at Cobalt and
cashed out my millions, BitKeeper would be open source.  But I didn't.
So it isn't.  Get over it.  It can help now, we're trying to help now,
we make it easy to get out of BK, so if/when a better open source answer
arrives, you can get out.  What more can you possibly ask for?  I'm giving
you an answer which helps, with no lock in, and the most extensive set of
tools designed to make it so you can get out with all of your data intact.
And you say you are insulted.  I'm not sure it is you who should be insulted.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[yodaiken]

On Thu, Mar 07, 2002 at 12:15:09PM -0800, Larry McVoy wrote:
> Our goal is to get him more relaxed.  Try and

This is not a problem that bitkeeper can address. Torvalds' guilt
for having stiffed me on the $5 bet he lost probably preys on his mind.
Just pay, Torvalds. I'll donate the money to charity. 



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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Troy Benjegerdes]

On Thu, Mar 07, 2002 at 11:54:43AM -0800, Andrew Morton wrote:
> Troy Benjegerdes wrote:
> > 
> > I'd really like everyone that's bitching about BK to shut the hell up and
> > go work on some scripts to allow a maintainer to easily manage a
> > BK<->$OTHER_SCM gateway.
> 
> ie: "We broke it.  You fix it".
> 
> It's not reasonable to expect people who shall not be using bitkeeper
> to go off and perform enhancements to bitkeeper so that they can
> continue to be effective kernel developers.

No. Try:
"You're whining, here's how fix it, because I don't have time or
motivation"

Larry went to a lot of trouble to listen to what kernel developers 
wanted, and a lot of work to implement some of it. I expect same courtesy 
of everyone who is complaining.

I am not expecting any 'enhancements to bitkeeper'.. that is Larry's job. 

> If additional development around bitkeeper is needed then the onus
> is upon the bitkeeper side to do that work.  (And yes, there are
> sides now).

If Larry can make good on his 'threat' to write a read-only cvs pserver 
interface to BK, I think he's done his part. (BK -> $OTHER_SCM)

Then I'd really like to see scripts to make it easy to go from
$YOUR_FAVORITE_SCM -> patch -> BK, while keeping important metadata, like,
oh, say, comments. The patch->BK part is already done. It's up to the
other 'side' now to get changes from $YOUR_FAVORITE_SCM into BK without
either losing lots of information, or taking lots of time.

Various people have probably already done all of this. Now can someone 
bother to spend some time to find the best methods for this and integrate
it into a nice 'packaged' setup? (along with a 'HOWTO')

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Schulz

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Larry McVoy]

> Then I'd really like to see scripts to make it easy to go from
> $YOUR_FAVORITE_SCM -> patch -> BK, while keeping important metadata, like,
> oh, say, comments. 

We already have an interface for this, Linus asked for it.  It will be in
the next release and it is in the download/test release.  You import your
patch and then stomp on the default comments with a comments file in the
format below.  If this isn't what you had in mind, let me know.

--lm

bk comments(1)       BitKeeper User's Manual       bk comments(1)

NAME
       bk comments - change checkin comments

SYNOPSIS
       bk   comments   [-p]   [-C<csetrev>]  [-r<rev>]  [-y<cmt>]
       [-Y<file>] [file ...] [-]

DESCRIPTION
       The comments command changes the  stored  comments  for  a
       revision  controlled  file.  The comments may be specified
       on the command line, or if  they  are  not,  you  will  be
       placed in your editor to type in the comments.

       If  given - for a file argument, then comments will read a
       list of files and comments to be  edited  in  batch.   The
       format is like:

           ### Comments for file.c|1.23
           this is a sample comment
           ### Comments for file2.h|1.2.3.4
           these are
           other comments

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Andrew Morton]

Troy Benjegerdes wrote:
> 
> On Thu, Mar 07, 2002 at 11:54:43AM -0800, Andrew Morton wrote:
> > Troy Benjegerdes wrote:
> > >
> > > I'd really like everyone that's bitching about BK to shut the hell up and
> > > go work on some scripts to allow a maintainer to easily manage a
> > > BK<->$OTHER_SCM gateway.
> >
> > ie: "We broke it.  You fix it".
> >
> > It's not reasonable to expect people who shall not be using bitkeeper
> > to go off and perform enhancements to bitkeeper so that they can
> > continue to be effective kernel developers.
> 
> No. Try:
> "You're whining, here's how fix it, because I don't have time or
> motivation"

Let's be clearer:

- If bitkeeper makes non-bitkeeper developers less effective than
  they traditionally have been then Larry gets to fix that.

- If non-bitkeeper users want *additional* functionality over what
  has traditionally been available then they get to implement it.

And Linus will keep pushing prepatches in the time-honoured
manner, so there's no loss in non-bk users effectiveness.

> Larry went to a lot of trouble to listen to what kernel developers
> wanted, and a lot of work to implement some of it. I expect same courtesy
> of everyone who is complaining.

I don't think anyone has been criticising bk featureset or reliability.
A few performance mumblings, maybe. It seems to be a fantastic piece
of software.

But that's not the point!   Nobody, repeat nobody is happy with the
licensing thing.  For some people, the day-to-day benefits outweigh
the philosophical concerns.  For others they do not.  That is what is
being discussed here.

I see two things being discussed here:

1: I don't want bitkeeper use to *decrease* my ability to do Linux
   work.  Linus will continue to push patches at the same rate, so
   I have no problem.  I'm OK with others using bitkeeper.  EOT.

2: Kernel has a leading role in free software development. Other
   people do not want kernel's use of bitkeeper to weaken that
   movement.

   Me, I don't think the "movement" is weak enough for damage to
   come about.  And SCM is a space where the free tools are weak.  
   It's a once-off special-case and it's hard to see how anything
   bad will come about from it.

> If Larry can make good on his 'threat' to write a read-only cvs pserver
> interface to BK, I think he's done his part. (BK -> $OTHER_SCM)

Well that would be icing on the cake.  But I don't believe it's
reasonable to expect bitmover to provide non-bitkeeper users
with *more* stuff than they have traditionally had.

That being said, the adoption of bitkeeper does reduce the
chances of non-bitkeeper users from ever getting more features,
but realistically, that would never have happened anyway.

And the non-bitkeeper users *do* have more than they used to
have - the web logs and changelogs.  That's nice.  It'd be
nicer if the web interface was more up-to-date, but I am told
that's a person thing, not a tool thing.

-

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Rik van Riel]

On Thu, 7 Mar 2002, Andrew Morton wrote:

> - If bitkeeper makes non-bitkeeper developers less effective than
>   they traditionally have been then Larry gets to fix that.

Since bitkeeper makes it easier for Linus to merge code
and the speed at which Linus is merging code seems to
have gone up, I'd say that bitkeeper has made life easier
even for those developers that aren't using it.

> - If non-bitkeeper users want *additional* functionality over what
>   has traditionally been available then they get to implement it.
>
> And Linus will keep pushing prepatches in the time-honoured
> manner, so there's no loss in non-bk users effectiveness.

Indeed.


> That being said, the adoption of bitkeeper does reduce the
> chances of non-bitkeeper users from ever getting more features,
> but realistically, that would never have happened anyway.

Actually, I like to think bitkeeper has given all of the
free software version control people a nice challenge.

Raising the bar by providing better software quality is
never a bad thing, IMHO.

regards,

Rik
-- 
<insert bitkeeper endorsement here>

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Anton Altaparmakov]

At 21:23 07/03/02, Andrew Morton wrote:
>It'd be nicer if the web interface was more up-to-date, but I am told
>that's a person thing, not a tool thing.

Perhaps it could be made a tool thing though. If a cron job could be setup 
on  Linus' master bk repository to do periodic pushes to the web interface 
or the other way round, if Larry would be given access to Linus' master 
repository so he can setup periodic pulls to bkbits.net web repository it 
would become a tool thing, no?

Anton - only starting to use bitkeeper but already signed onto the bk fan 
club (-:


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Cort Dougan]

We're here to discuss kernel development, right?  Not debate software
ideologies.

I move the PPC tree over to BitKeeper and it was worthwhile.  I made
rsync updates and plain old 'diff' patches against Linus' tree available
nightly.  It was easy and very quick to do that, I had it running for
nearly 2 years very well.  In fact, you can still grab the patches from
ftp://ftp.kernel.org/pub/linux/kernel/people/cort/.  What is your problem with BK
apart from the license religion?  Linus has made it clear he'll provide
patches in the same old style.  I don't see what you think you lose here.
The gain for people who ship him patches is well worth it.  Before I handed
the PPC tree over to Paul I would have killed to get Linus to use BK so
shipping him patches would be easier for everyone involved.  If I were
still a maintainer my response would be a lot less mild to those people
that fight against BK on something so intangible as "feelings" about the
license.  I put in a lot of hours shipping patches that were for nothing,
BK is helping avoid that for the current crew.

Seriously, what is your problem with BK?  What do you feel that you lose?

} Also. The things being discussed here *matter* to some people.  Some
} of the comments made by Larry, David, Cort, Rik and others have
} coarsely sought to deligitimise the very reasons why a significant number
} of kernel contributors and users are here at all.  Those comments
} are monumentally insulting.
} 
} -
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at  http://www.tux.org/lkml/

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Rik van Riel]

On Thu, 7 Mar 2002, Cort Dougan wrote:

> We're here to discuss kernel development, right?  Not debate software
> ideologies.
>
> I move the PPC tree over to BitKeeper and it was worthwhile.

The development speed and code quality of -rmap have also gone
up as a consequence of moving over to bitkeeper.

Merging patches up to a new version of the kernel has gone from
tiring (with patch and vi) to almost relaxing (with bitkeeper's
automatic and graphical 2-way merge tools)...

This in turn has allowed me to spend my time and energy on
improving the code, without having to fear large patches and
the maintenance those require.

regards,

Rik
-- 
<insert bitkeeper endorsement here>

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Cort Dougan]

I'm a big fan of doing a given merge ONLY ONE TIME rather than every time
there's a contextual diff.  Man, that is definitely something worth being
grateful for.  Especially with the number of changes that come down in the
linux tree.

Rik, care to form the "useful tools that don't screw me over every time I
try to use them" fan club?  I'll chuck in a pair of vice-grips and bk as
the first nominees.

} The development speed and code quality of -rmap have also gone
} up as a consequence of moving over to bitkeeper.
} 
} Merging patches up to a new version of the kernel has gone from
} tiring (with patch and vi) to almost relaxing (with bitkeeper's
} automatic and graphical 2-way merge tools)...
} 
} This in turn has allowed me to spend my time and energy on
} improving the code, without having to fear large patches and
} the maintenance those require.

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Andrew Morton]

Cort Dougan wrote:
> 
> We're here to discuss kernel development, right?  Not debate software
> ideologies.

Not entirely, no.  This discussion is touching on the reasons for
people (ie: manpower) being here.  Also on toolchain suitability
and release practices, etc.  Also upon how bk and non-bk developers
interwork.  That's not a bad thing.

> I move the PPC tree over to BitKeeper and it was worthwhile.  I made
> rsync updates and plain old 'diff' patches against Linus' tree available
> nightly.  It was easy and very quick to do that, I had it running for
> nearly 2 years very well.  In fact, you can still grab the patches from
> ftp://ftp.kernel.org/pub/linux/kernel/people/cort/.  What is your problem with BK
> apart from the license religion?  Linus has made it clear he'll provide
> patches in the same old style.  I don't see what you think you lose here.
> The gain for people who ship him patches is well worth it.  Before I handed
> the PPC tree over to Paul I would have killed to get Linus to use BK so
> shipping him patches would be easier for everyone involved.  If I were
> still a maintainer my response would be a lot less mild to those people
> that fight against BK on something so intangible as "feelings" about the
> license.  I put in a lot of hours shipping patches that were for nothing,
> BK is helping avoid that for the current crew.

Oh I'm sure bitkeeper is excellent.

When you use the term "license religion", you are in fact saying "If
someone has philosophical objections then those people are irrational
zealots and their objections and philosophical beliefs are baseless".
That's not very respectful...

> Seriously, what is your problem with BK?  What do you feel that you lose?

I've said about, uh, three times now that I'm not losing anything.

Problem?  Well partly I just can't be assed to use the thing because
I'm comfortable with my own scripts and all revision control systems
just get in your face and suck.  But also because I'm here to improve
the body of public software, and at the end of the day, any support
which I put into bitkeeper won't help there.  (using == supporting).


So.  Summary: keep the prepatches rolling.  And lighten up on the
perjoratives - they are unbecoming.

-

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Cort Dougan]

Be respectful on l-k?  I wouldn't dare to step outside of the norm :)
No, I'm not respectful of software ideology because it takes valuable time
that we can spend arguing about meaningless and off-topic technical
subjects instead.

} When you use the term "license religion", you are in fact saying "If
} someone has philosophical objections then those people are irrational
} zealots and their objections and philosophical beliefs are baseless".
} That's not very respectful...

Then you have no problem, right?  You'll still be able to use your
patches and others will be able to use BK.  Your compaint seems to be about
what others choose to use when working on the kernel.  Some ideology is
well placed when discussing matters of the kernel but what tools people use
to work on it is going way too far.

} Problem?  Well partly I just can't be assed to use the thing because
} I'm comfortable with my own scripts and all revision control systems
} just get in your face and suck.  But also because I'm here to improve
} the body of public software, and at the end of the day, any support
} which I put into bitkeeper won't help there.  (using == supporting).

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Rik van Riel]

On Thu, 7 Mar 2002, Andrew Morton wrote:

> Problem?  Well partly I just can't be assed to use the thing because
> I'm comfortable with my own scripts and all revision control systems
> just get in your face and suck.

That's what I thought too, but bitkeeper has convinced
me to get over that prejudice ;)

> But also because I'm here to improve the body of public software,
> and at the end of the day, any support which I put into bitkeeper
> won't help there.  (using == supporting).

That's a tradeoff everybody has to make for himself.
Personally the time bitkeeper saves me helps improving
Linux a lot, so using bitkeeper does help increase my
contribution to the body of public software.

Of course, this is everybody's personal choice and
you're just as right (or wrong) as I am ;)

regards,

Rik
-- 
<insert bitkeeper endorsement here>

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Jeff Garzik]

Andrew Morton wrote:
> I've said about, uh, three times now that I'm not losing anything.
> 
> Problem?  Well partly I just can't be assed to use the thing because
> I'm comfortable with my own scripts and all revision control systems
> just get in your face and suck.  But also because I'm here to improve
> the body of public software, and at the end of the day, any support
> which I put into bitkeeper won't help there.  (using == supporting).

FWIW, I've "gotten" your problem with BitKeeper for a while now...

..And I'm glad you're speaking out and holding the torch here.  We need
dissenters to keep us BK users honest :)

[i.e. the same reason that, while I might not agree with RMS, I think
the Linux community and free software in general need him to be around. 
We need activists willing to hold the hard line.]

-- 
Jeff Garzik      | Usenet Rule #2 (John Gilmore): "The Net interprets
Building 1024    | censorship as damage and routes around it."
MandrakeSoft     |

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Florian Weimer]

Cort Dougan <cort@fsmlabs.com> writes:

> We're here to discuss kernel development, right?  Not debate software
> ideologies.

It's sometimes hard to separate the two.

Look at the digital rights management code for kernel modules.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Florian Weimer]

Troy Benjegerdes <hozer@drgw.net> writes:

> I'd really like everyone that's bitching about BK to shut the hell up and
> go work on some scripts to allow a maintainer to easily manage a
> BK<->$OTHER_SCM gateway.

How do you know that BitMover isn't trying to patent aspects of
BitKeeper which prevents you from writing such gateways?

They're already aiming at a patent for some of there merging
algorithms, IIRC.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Linus Torvalds]

In article <20020306221305.GA370@elf.ucw.cz>,
Pavel Machek  <pavel@ucw.cz> wrote:
>
>So you basically give bk for free because it is good for you. What if
>it will stop being good for you ten years from now?

Guys, calm down.

A few points:

 - I certainly don't require BK use of anybody.  It makes my life
   simpler with some people (mainly the ones that tend to be maintainers
   of subsystems and send me lots of patches), but there are many
   developers who do NOT use BK, and it doesn't slow them down at all. 

   For example, see the FS patches from Al Viro: the only thing that BK
   has resulted in as far as Al is concerned is that the changelogs are
   a lot better and include his email comments. 

   And I also export my tree as regular patches, the way I always have
   (well, the actual format changed subtly, but that's purely syntactic)

 - If Larry turns to the dark side (or, as some would say, the "even
   darker side" ;) we're _still_ ok. The data isn't going anywhere, he
   can't close that down. We'd just have to export it into a new format.

   If worst comes to worst, and nobody has fixed CVS/subversion/whatever
   by then, I can even just go back to how I used to work. Nothing lost.

 - If people in the open-source SCM community wake up and notice that
   the current open-source SCM systems aren't cutting it, that's _good_. 
   But it's absolutely NOT an excuse to use them today.  Sorry.  I use
   CVS at work, and I could never use it for Linux.  I took a look at
   subversion, and it doesn't even come close to what I wanted. 

   And I personally refuse to use inferior tools because of ideology. In
   fact, I will go as far as saying that making excuses for bad tools
   due to ideology is _stupid_, and people who do that think with their
   gonads, not their brains. 

In short: nobody requires BK of anybody else.  A lot of people really
like using it, though, and it does make some things easier.  Some people
aren't convinced - David Miller is trying it out, and I haven't heard
all happy sounds from him about it. Others have taken to BK like fish to
water, and you'll pry it out of their dead cold hands.

The most productive thing people could do might be to just do a BK->CVS
gateway, if you really feel like it.  Or just go on and ignore the fact
that some people are using BK - you don't actually have to ever even
know. 

		Linus

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Larry McVoy]

> The most productive thing people could do might be to just do a BK->CVS
> gateway, if you really feel like it.  Or just go on and ignore the fact
> that some people are using BK - you don't actually have to ever even
> know. 

We've thought of making a readonly CVS pserver interface to BK which would
at least make it easy to get the source in some form that the GPL folks
like.  Somebody else should be able to do that with a perl script.  You
could attempt a read/write interface as well, that's a lot harder, the
impedance mismatch between BK and CVS becomes much more apparent in
the read/write case.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[george anzinger]

Linus Torvalds wrote:
> 
> In article <20020306221305.GA370@elf.ucw.cz>,
> Pavel Machek  <pavel@ucw.cz> wrote:
> >
> >So you basically give bk for free because it is good for you. What if
> >it will stop being good for you ten years from now?
> 
> Guys, calm down.
> 
> A few points:
> 
>  - I certainly don't require BK use of anybody.  It makes my life
>    simpler with some people (mainly the ones that tend to be maintainers
>    of subsystems and send me lots of patches), but there are many
>    developers who do NOT use BK, and it doesn't slow them down at all.
> 
>    For example, see the FS patches from Al Viro: the only thing that BK
>    has resulted in as far as Al is concerned is that the changelogs are
>    a lot better and include his email comments.
> 
>    And I also export my tree as regular patches, the way I always have
>    (well, the actual format changed subtly, but that's purely syntactic)
> 
>  - If Larry turns to the dark side (or, as some would say, the "even
>    darker side" ;) we're _still_ ok. The data isn't going anywhere, he
>    can't close that down. We'd just have to export it into a new format.
> 
>    If worst comes to worst, and nobody has fixed CVS/subversion/whatever
>    by then, I can even just go back to how I used to work. Nothing lost.
> 
>  - If people in the open-source SCM community wake up and notice that
>    the current open-source SCM systems aren't cutting it, that's _good_.
>    But it's absolutely NOT an excuse to use them today.  Sorry.  I use
>    CVS at work, and I could never use it for Linux.  I took a look at
>    subversion, and it doesn't even come close to what I wanted.
> 
>    And I personally refuse to use inferior tools because of ideology. In
>    fact, I will go as far as saying that making excuses for bad tools
>    due to ideology is _stupid_, and people who do that think with their
>    gonads, not their brains.

Does this mean you will admit kgdb into the tree?  

(Sorry, I couldn't help myself :-)

-g

> 
> In short: nobody requires BK of anybody else.  A lot of people really
> like using it, though, and it does make some things easier.  Some people
> aren't convinced - David Miller is trying it out, and I haven't heard
> all happy sounds from him about it. Others have taken to BK like fish to
> water, and you'll pry it out of their dead cold hands.
> 
> The most productive thing people could do might be to just do a BK->CVS
> gateway, if you really feel like it.  Or just go on and ignore the fact
> that some people are using BK - you don't actually have to ever even
> know.
> 
>                 Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George           george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Jeff V. Merkey]

All hail the non-profit nazis from Ohio State.  It's none of your 
f_cking business what we use to develop software.  I use a hardware
American Arium logic analyzer and a proprietary Linux kernel 
debugger.  Should people be boycotted when they use hardware 
analyzers to debug hardware and software with Linux.  

It's pretty clear that the alumni of Ohio State University have the
finest sinsemilla weed around, and have been smoking it.  I guess
you guys will decide who we get to sleep with next, marry, and 
which type of cereal we get to eat. 

The motto behind open source was "freedom of choice".  So much for
progress.  Let's bring back slavery while we are at at.  I'll move 
back to the Indian reservation in New Mexico where I grew up since 
freedom is going away.

How about sending me some of the killer weed you guys have been smoking.
You can pass the crack pipe around while you're at it.

:-)

Jeff


On Tue, Mar 05, 2002 at 04:52:34PM -0500, The Open Source Club at The Ohio State University wrote:
> Petition Against Official Endorsement of BitKeeper by Linux Maintainers
> 
> We, the undersigned members and officers of the Open Source Club at
> the Ohio State University, are unhappy with the advocacy of the
> proprietary[1] BitKeeper software for use in maintaining the Linux
> kernel.  The Linux kernel is an important symbol of Open Source and
> Free Software for many people, and a project in which many thousands
> have participated in active development.  It is fine if some kernel
> developers choose to use BitKeeper on their own machines, but
> officially endorsing proprietary software as the means of working on
> the kernel is a large step backwards for Linux, and for the Open
> Source and Free Software communities.
> 
> If the core Linux maintainers begin to advocate using BitKeeper, then
> there will be strong pressure on these peripheral developers to use
> BitKeeper too, since it would likely be easier than browsing the
> web-exported changelogs or fetching the latest diff from kernel.org.
> 
> Using a closed-source, proprietary source control system for the
> kernel is even worse than using other forms of proprietary software
> such as source code analysis systems, because the revision control
> metadata (version numbers, branches, changelog comments, etc.), would
> be stored in a format defined by the proprietary software.  This
> metadata is really a part of Linux, because people will want to use it
> when talking about the kernel.  Those who can't[2] or don't want to
> use BitKeeper are left out in the cold.  One of the most important
> parts of Open Source and Free Software is that we, the community, are
> in control.  But by using and advocating BitKeeper, we would lose part
> of that control.
> 
> In summary, please do not advocate BitKeeper for use by the general
> community.  The Linux development process seems to have worked up till
> now, and we can wait a little longer until Arch[3] or Subversion[4]
> are completed.  Moreover, full-featured, completely functional free 
> versioning sytems are currently available, such as PRCS[5] and CVS[6].
> We respect the kernel maintainer's freedom to use proprietary software 
> for their own purposes.  And we ask the kernel maintainers to respect 
> the community's freedom from entrapment by proprietary software.
> 
> -- The Open Source Club at The Ohio State University
> Signed by:
> Michael Benedict <zosima@zosima.org>
> Colin Walters <walters@debian.org>
> Matt Curtin <cmcurtin@interhack.net>
> Martin Jansche <jansche@ling.ohio-state.edu>
> Balbir Thomas <thomas.1037@osu.edu>
> Nicholas Hurley <hurley@cis.ohio-state.edu>
> Ryan McCormack <mccormac@cis.ohio-state.edu>
> Shaun Rowland <rowland@cis.ohio-state.edu>
> 
> [1] http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html
> [2] Perhaps they aren't connected to the internet regularly enough,
>     for instance.
> [3] http://www.regexps.com/#arch
> [4] http://subversion.tigris.org
> [5] http://prcs.sourceforge.net
> [6] http://www.cvshome.org
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Kilobug]

Jeff V. Merkey wrote:
> All hail the non-profit nazis from Ohio State.

Congratulations ! You've won

+-----------------+
|       One       |
|      Godwin     |
|       Point     |
+-----------------+

You can cut it with an axe and add it to your collection.

http://www.faqs.org/faqs/usenet/legends/godwin/

-- 
** Gael Le Mignot "Kilobug", Ing3 EPITA - http://kilobug.free.fr **
Home Mail   : kilobug@freesurf.fr          Work Mail : le-mig_g@epita.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

"Software is like sex it's better when it's free.", Linus Torvalds

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Stephen Samuel]

I think you missed the point of the petition.  They're not asking
people to stop using bitkeeper. They're asking that it not be
advocated as an OFFICIAL kernel development/maintenance process.

As you said.. What you do in the privacy of your own home/office
is your business. On the other hand, what you advocate that the
Open Source community do in theirs is the business of the whole
community.


Jeff V. Merkey wrote:
 > On Tue, Mar 05, 2002 at 04:52:34PM -0500, The Open Source Club at The Ohio State University wrote:
 >
 >>have participated in active development.  It is fine if some kernel
 >>developers choose to use BitKeeper on their own machines, but
 >>officially endorsing proprietary software as the means of working on
 >>the kernel is a large step backwards for Linux, and for the Open
 >>Source and Free Software communities.

> All hail the non-profit nazis from Ohio State.  It's none of your 
> f_cking business what we use to develop software.  I use a hardware

Yep.  and they acknowledged that at the start of their petition

> American Arium logic analyzer and a proprietary Linux kernel 
> debugger.  Should people be boycotted when they use hardware 
> analyzers to debug hardware and software with Linux.  
....
> How about sending me some of the killer weed you guys have been smoking.
> You can pass the crack pipe around while you're at it.

...

>>metadata is really a part of Linux, because people will want to use it
>>when talking about the kernel.  Those who can't[2] or don't want to
>>use BitKeeper are left out in the cold.  One of the most important
.....

>>We respect the kernel maintainer's freedom to use proprietary software 
>>for their own purposes.  And we ask the kernel maintainers to respect 
>>the community's freedom from entrapment by proprietary software.


-- 
Stephen Samuel +1(604)876-0426                samuel@bcgreen.com
		   http://www.bcgreen.com/~samuel/
Powerful committed communication, reaching through fear, uncertainty and
doubt to touch the jewel within each person and bring it to life.

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Stephen Samuel]

Matthew D. Pitts wrote:
> Stephen, et al...
> 
> As has already been said, if you don't want BitKeeper to be used by kernel
> developers, write something that is just as good and release it under the
> GPL... That way, we have a choice of equals, not apples and oranges...

That could be considered ONE solution -- or simply one ASPECT of
a different solution.

I'm not going to suggest that the current OS solutions are currently
better than what BitKeeper currently has to offer -- but if we always
constrained ourselves to simply using whatever's the best solution
(without any allowance for whether or not it was open source), the
GNU project would never have started, and projects like ABI word,
and K-Office would never have gotten to where they are today.

I think that the people petitioning Linus (and really, the whole
Linux Kernel community) to not hav BitKeeper be part of the
official linux kernel development architecture recognize that
the *current* version of the Open Source solutions are not
clearly superior to some of the current proprietary solutions --
but then again, that was the situation with the Linux Kernel
for many years too.

Some people worked on and put up with and cleaned up the Linux
environent in it's early days -- when it was clearly NOT as easy
to do as working on Solaris -- or, in some cases, even Window
(especially if you go back far enough). Many of these people did
that work because they believed in the PRINCIPLE of building an
Open Source/Free solution that was, ultimately, going to be
far better that what was (and was going to be) available in
the proprietary world.

Working today on almost entirely free or open source products,
I am standing on top of the blood, sweat, tears and lost data
of those pioneers.  Many of those pioneers are still working on
the linux kernel. For them the idea that, after up to a decade of
building free source solutions, they should need to buy a proprietary
solution to continue to 'be in the loop' is galling.

Some of these people have eschewed high paying jobs to be able to
continue to work on parts of Linux, so -- for them -- having to fork
out extra money for a proprietary code control solution is also
prohibitive.  (this may not be too obvious to someone who routinely
makes in the 6-digits range working for a large company)


For many of these people, the answer is 2-prong:

1 - - and as you suggested - - produce an Open Source tool that is
   better for the task than the proprietary stuff, and

2 - - in the mean time bite the bullet, continue to use the
   open source solution, and take the (hopefully short-term)
   cost that goes along with that.


besides what I mentioned above, one of the advantages of doing
number 2  is that it actually provides an ongoing incentive to
have a workable Open Source solution in place sooner, rather
than later.  Once that happens, then not only will the heart of
this dispute go away, but the open source community will be free
to develop and tweak the solution to their own needs, rather than
bowing to the economic needs and plans of a pseudo-anonymous
company.



note: this solution DOES NOT PRECLUDE YOU (or anybody else) FROM
USING BITKEEPER (or any other proprietary solution) in the privacy of
your office and/or home -- even if you want to do Linux development
with it.  It's simply about what occurs in the OFFICIAL Linux kernel
code tree, which probably has a reasonably high proportion of people
who are both politically and financially sensitive to the idea of
being almost required to use an closed source product to work on
their open source 'baby'.

-- 
Stephen Samuel +1(604)876-0426                samuel@bcgreen.com
		   http://www.bcgreen.com/~samuel/
Powerful committed communication, reaching through fear, uncertainty and
doubt to touch the jewel within each person and bring it to life.

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Alexander Viro]

On Thu, 7 Mar 2002, Stephen Samuel wrote:
 
> note: this solution DOES NOT PRECLUDE YOU (or anybody else) FROM
> USING BITKEEPER (or any other proprietary solution) in the privacy of
> your office and/or home -- even if you want to do Linux development
> with it.

Do you realize how incredibly offensive it is?  A bunch of self-appointed PR
flacks with a gall to tell people who do real work that they must conform
to party line whenever they are in public.  Thank you so much for leaving
us "the privacy of office and/or home"...   Sheesh...

-- 
Politruki wyiskalis', mat' washu...

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[yodaiken]

On Thu, Mar 07, 2002 at 05:39:21PM -0800, Stephen Samuel wrote:
> note: this solution DOES NOT PRECLUDE YOU (or anybody else) FROM
> USING BITKEEPER (or any other proprietary solution) in the privacy of
> your office and/or home -- even if you want to do Linux development
> with it.  It's simply about what occurs in the OFFICIAL Linux kernel
> code tree, which probably has a reasonably high proportion of people
> who are both politically and financially sensitive to the idea of
> being almost required to use an closed source product to work on
> their open source 'baby'.

Sometimes it gets too hard to believe.



> 
> -- 
> Stephen Samuel +1(604)876-0426                samuel@bcgreen.com
> 		   http://www.bcgreen.com/~samuel/
> Powerful committed communication, reaching through fear, uncertainty and
> doubt to touch the jewel within each person and bring it to life.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Andreas Dilger]

On Thu, Mar 07, 2002 at 05:39:21PM -0800, Stephen Samuel wrote:
> note: this solution DOES NOT PRECLUDE YOU (or anybody else) FROM
> USING BITKEEPER (or any other proprietary solution) in the privacy of
> your office and/or home -- even if you want to do Linux development
> with it.  It's simply about what occurs in the OFFICIAL Linux kernel
> code tree, which probably has a reasonably high proportion of people
> who are both politically and financially sensitive to the idea of
> being almost required to use an closed source product to work on
> their open source 'baby'.

Do you even know what you are talking about?  It is clear you don't.

1) You do NOT need to buy BK to use it on any open-source project,
   as long as you are willing to have the changelogs posted on the
   BK website.  Since most open-source projects host their entire
   CVS repository on a public website, this isn't any additional
   restriction.

2) Nobody is forcing anyone to use BK to contribute to the kernel.  The
   kernel is still available as a tarball and incremental patches.  Linus
   is still accepting patches in email just like he always did (or didn't,
   as the case may be).

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Sean Hunter]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Thu, Mar 07, 2002 at 05:39:21PM -0800, Stephen Samuel wrote:
> 
> note: this solution DOES NOT PRECLUDE YOU (or anybody else) FROM
> USING BITKEEPER (or any other proprietary solution) in the privacy of
> your office and/or home -- even if you want to do Linux development
> with it.  It's simply about what occurs in the OFFICIAL Linux kernel
> code tree, which probably has a reasonably high proportion of people
> who are both politically and financially sensitive to the idea of
> being almost required to use an closed source product to work on
> their open source 'baby'.
> 

You left off:

  We support your right to have babies, even though you can't have 
     babies, which is nobodies fault, not even Larry McVoy's.

Thanks for giving everyone your permission to use bitkeeper in the privacy of
their own home.  Its nice to know you think anyone gives a fuck about your
opinion. Now kindly sod off and stop wasting everybodies time.

Sean


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Karl]

>All hail the non-profit nazis from Ohio State.  It's none of your
>f_cking business what we use to develop software.  I use a hardware
>American Arium logic analyzer and a proprietary Linux kernel
>debugger.  Should people be boycotted when they use hardware
>analyzers to debug hardware and software with Linux.


   I don't want to speak for our friends in Ohio, but I don't think they
asked to inhibit you in any way shape or form. Their point was about
official endorsement not personal choice. I think they went as far as to
state that explicitly.

   Karl

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Jeff V. Merkey]

On Tue, Mar 05, 2002 at 09:23:16PM -0500, Karl wrote:
> >All hail the non-profit nazis from Ohio State.  It's none of your
> >f_cking business what we use to develop software.  I use a hardware
> >American Arium logic analyzer and a proprietary Linux kernel
> >debugger.  Should people be boycotted when they use hardware
> >analyzers to debug hardware and software with Linux.
> 
> 
>    I don't want to speak for our friends in Ohio, but I don't think they
> asked to inhibit you in any way shape or form. Their point was about
> official endorsement not personal choice. I think they went as far as to
> state that explicitly.
> 
>    Karl


Yeah, I saw that part Karl, but the bottom line in their position 
was to limit our choices and choose for us their oppresive views.  It's
also tortorious to post such a petition as a mean to attack a for
profit endeavor, whether the profit is kudos or consideration.  Try
pulling this on Novell or Microsoft, and watch how fast you go to court.

These people are bullies.  

:-)

Jeff

> 

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Alan Cox]

Right from the start Linus has always said he isn't going to force anyone
to use bitkeeper. End of story. If you think its free enough -  use it, if
you don't (or you just think its crap software, dont use it)

In fact if it offends you enough to start a petition take the list of
names you get at the end and between you go write a better one under a
licence you prefer between the signatures.

Aan

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Eric W. Biederman]

The Open Source Club at The Ohio State University  <opensource-admin@cis.ohio-state.edu> writes:

> Petition Against Official Endorsement of BitKeeper by Linux Maintainers

Free software is an empowering agent.  Petitions as a technique are
only a good choice when you have no power to affect things.  And even
then they only affect when you get enough signatories.

Please use the power you have and do something productive.  Everyone
has exactly as much power as Linus to move the Linux kernel forward.  Not
everyone has as much trust, or as much ability but that is something
anyone can build.

Free software is not an entitlement, nor is it a right.  And it has no
official government support so it is not likely to become an entitlement.
Instead free software is the product of people working hard to make
certain free software is available.  And the classic motto
is show me the code.  Or the Texas version show me.

Please show that there is something good that does a better.  Or use
this as a call to arms to write it.  Or perhaps find a way to pay
Larry McVoy enough so that he will open source it.

Eric

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Rik van Riel]

On Tue, 5 Mar 2002, The Open Source Club at The Ohio State University wrote:

> Petition Against Official Endorsement of BitKeeper by Linux Maintainers
>
> We, the undersigned members and officers of the Open Source Club at
> the Ohio State University, are unhappy with the advocacy of the
> proprietary[1] BitKeeper software for use in maintaining the Linux
> kernel.

Maybe I'll take you seriously after you've written something
better than bitkeeper that is free software.

Currently bitkeeper is saving kernel hackers many hours of
work and is benefitting kernel development a lot.

You won't get me to stop using a good tool that is speeding
up my development and saving me lots of frustration. OTOH,
if you have a free software alternative to bitkeeper that
comes close in functionality, I might be willing to look
into it.

Until then, the choice between a not-quite-free tool and no
useful tool at all is easy.

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

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

Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers

[Pau Aliagas]

On Wed, 6 Mar 2002, Rik van Riel wrote:

> Until then, the choice between a not-quite-free tool and no
> useful tool at all is easy.

Give arch a try. It's in www.regexps.com.
It does a pretty decent job.
If you need an rpm spec just tell me.

Pau