BK kernel workflow

BK kernel workflow

[Jeff Garzik]

Although tangential to the problem, I thought LKML and BitMover (and 
maybe Andrew or Linus as well) might be interested in a general 
description of my workflow.


For net drivers in the Linux kernel, there exists two patch queues, 
net-drivers-2.6 and netdev-2.6 (and corresponding 2.4 versions). 
net-drivers-2.6 could be described as the "upstream immediately" or "for 
Linus" queue, and netdev-2.6 could be described as the "testing" queue.

When receive a patch from some random person on the Internet, fixing a 
net driver bug in the "8139too" driver, I do

1) create "topic-specific" repo, if it doesn't already exist

Key point:  when dealing with a large number of incoming changes, like I 
do, sorting the changes locally into logically separate _sets of 
changes_ (one set per repo) has a lot of advantages, given that 
BitKeeper doesn't allow changeset "cherrypicking".

	cd /spare/repo/netdev-2.6	# not a repo, just a subdir
	bk clone -ql ../linux-2.6 8139too

2) move the email containing the patch, in my MUA, to 25_Patches mbox

3) merge the patch into the topic-specific repo, using Linus's patch 
importing tools,

	cd 8139too && dotest < /garz/nsmail/25_Patches

4) pull the topic-specific repo into "collector" repo, and merge conflicts

	cd ALL && bk pull ../8139too

5) build and test 'ALL' repo [heh... usually...]

6) push 'ALL' to external netdev-2.6 repos on gkernel.bkbits.net and 
kernel.bkbits.net

7) Andrew's workflow includes automatically pulling netdev-2.6 repo into 
his more-experimental "-mm" tree for wider review and testing.

[time passes]

8) Linus and Andrew release the latest and greatest 2.6.N stable release.

9) every day or so, I 'bk pull' a few "topic-specific" repos into a 
local clone of net-drivers-2.6, test that, and send it off to Linus/Andrew.

Key point:  thanks to the daily snapshots, my changes show up broken up 
across several daily snapshots, rather than "one big huge lump of 
changes that's been waiting to go in".

	cd /spare/repo
	bk clone -ql linux-2.6 net-drivers-2.6
	bk pull ../netdev-2.6/8139too
	bk pull ../netdev-2.6/viro-sparse-annotations
	bk pull ../netdev-2.6/janitor
	bk pull ../netdev-2.6/misc
	bk push && bk push kernel.bkbits.net:net-drivers-2.6

	# and then email Linus/Andrew the output of
	# bk-make-sum + gcapatch (see Documentation/BK-usage)

Re: BK kernel workflow

[Paolo Ciarrocchi]

On Tue, 19 Oct 2004 12:06:49 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> Although tangential to the problem, I thought LKML and BitMover (and
> maybe Andrew or Linus as well) might be interested in a general
> description of my workflow.
> 
> For net drivers in the Linux kernel, there exists two patch queues,
> net-drivers-2.6 and netdev-2.6 (and corresponding 2.4 versions).
> net-drivers-2.6 could be described as the "upstream immediately" or "for
> Linus" queue, and netdev-2.6 could be described as the "testing" queue.

So you have two bk trees, 
- patches good for mainstream
- patches good for -mm tree

It would be cool if all the maintainers could adopt your working method,
Andrew is already automatically pulling from a bunch of trees, why not
having Linusdoing the same too?

Something like:
linux-2.6.XX is released
- Linus pull from all the "patches good for mainstream" bk trees and
from the equivalent Andrew tree (that doesn't exist at the moment)
- Linus release the first -pre release
- Linus gets other patches according to the "old" method
- Linus releases the -pre/-rc

Is it just a stupid idea ?

-- 
Paolo

Re: BK kernel workflow

[Jeff Garzik]

On Tue, Oct 19, 2004 at 11:33:40PM +0200, Paolo Ciarrocchi wrote:
> On Tue, 19 Oct 2004 12:06:49 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> > Although tangential to the problem, I thought LKML and BitMover (and
> > maybe Andrew or Linus as well) might be interested in a general
> > description of my workflow.
> > 
> > For net drivers in the Linux kernel, there exists two patch queues,
> > net-drivers-2.6 and netdev-2.6 (and corresponding 2.4 versions).
> > net-drivers-2.6 could be described as the "upstream immediately" or "for
> > Linus" queue, and netdev-2.6 could be described as the "testing" queue.
> 
> So you have two bk trees, 
> - patches good for mainstream
> - patches good for -mm tree

Close:
- patches ready for mainstream
- patches eventually ready for mainstream

and changes flow "up" from netdev-2.6 to net-drivers-2.6.


> It would be cool if all the maintainers could adopt your working method,
> Andrew is already automatically pulling from a bunch of trees, why not
> having Linusdoing the same too?

That's what Linus does already, when I email him :)

But Linus is essentially "senior editor", so we don't want to automate
the system, otherwise there is no editorial control.  He is our
emporer penguin, after all.

	Jeff

Re: BK kernel workflow

[Paolo Ciarrocchi]

On Tue, 19 Oct 2004 17:38:03 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> On Tue, Oct 19, 2004 at 11:33:40PM +0200, Paolo Ciarrocchi wrote:
> > On Tue, 19 Oct 2004 12:06:49 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> > > Although tangential to the problem, I thought LKML and BitMover (and
> > > maybe Andrew or Linus as well) might be interested in a general
> > > description of my workflow.
> > >
> > > For net drivers in the Linux kernel, there exists two patch queues,
> > > net-drivers-2.6 and netdev-2.6 (and corresponding 2.4 versions).
> > > net-drivers-2.6 could be described as the "upstream immediately" or "for
> > > Linus" queue, and netdev-2.6 could be described as the "testing" queue.
> >
> > So you have two bk trees,
> > - patches good for mainstream
> > - patches good for -mm tree
> 
> Close:
> - patches ready for mainstream
> - patches eventually ready for mainstream
> 
> and changes flow "up" from netdev-2.6 to net-drivers-2.6.

Yup, I hope that almost all the patches move from "patches eventually
ready for mainstream" to "patches ready for mainstream" ;-)

> 
> > It would be cool if all the maintainers could adopt your working method,
> > Andrew is already automatically pulling from a bunch of trees, why not
> > having Linusdoing the same too?
> 
> That's what Linus does already, when I email him :)

Good ;) but AFAIK Andrew is not publishing the "patches ready for
mainstream" (bk or collection of patches) tree.


> But Linus is essentially "senior editor", so we don't want to automate
> the system, otherwise there is no editorial control.  He is our
> emporer penguin, after all.

I understand, 
I know I'm pedantic but can we all see the list of bk trees ("patches
ready for mainstream" and "patches eventually ready for mainstream")
that we'll be used by Linus ?

I'm learning a lot trying to understand the development method used by
this community,
but there are things that I don't fully understand, 
is it possible to "formalize" it (somehow) ?

Ciao and thanks!

-- 
Paolo
Personal home page: www.ciarrocchi.tk

Re: BK kernel workflow

[Linus Torvalds]

On Tue, 19 Oct 2004, Paolo Ciarrocchi wrote:
>
> I know I'm pedantic but can we all see the list of bk trees ("patches
> ready for mainstream" and "patches eventually ready for mainstream")
> that we'll be used by Linus ?

Even _I_ don't have that kind of list. 

It's on a case-by-case basis (although with certain developers, the cases 
tend to be pretty clear-cut), and it literally changes over time. Some 
people use throw-away trees that are just used for some particular set, 
and I merge them (or not), and they go away.

		Linus

Re: BK kernel workflow

[Paolo Ciarrocchi]

On Tue, 19 Oct 2004 15:11:55 -0700 (PDT), Linus Torvalds
<torvalds@osdl.org> wrote:
> 
> 
> On Tue, 19 Oct 2004, Paolo Ciarrocchi wrote:
> >
> > I know I'm pedantic but can we all see the list of bk trees ("patches
> > ready for mainstream" and "patches eventually ready for mainstream")
> > that we'll be used by Linus ?
> 
> Even _I_ don't have that kind of list.
> 
> It's on a case-by-case basis (although with certain developers, the cases
> tend to be pretty clear-cut), and it literally changes over time. Some
> people use throw-away trees that are just used for some particular set,
> and I merge them (or not), and they go away.

So ATM is not possible to "formalize" the process (and probably even
not necessary)
Thank you.

-- 
Paolo
Personal home page: www.ciarrocchi.tk

Re: BK kernel workflow

[Larry McVoy]

On Tue, Oct 19, 2004 at 03:11:55PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 19 Oct 2004, Paolo Ciarrocchi wrote:
> >
> > I know I'm pedantic but can we all see the list of bk trees ("patches
> > ready for mainstream" and "patches eventually ready for mainstream")
> > that we'll be used by Linus ?
> 
> Even _I_ don't have that kind of list. 

I don't know how you could have that sort of list.  We have some idea
of the potential size of that list and it's huge.  Based on the lease
requests back to us (BK is lease based, it connects back to us once a
month), we estimate that there well over 10,000 clones of the Linux kernel
in BK.  If even 1/10th of those are going to have a patch for Linus that's
1,000 potential patches.  Pretty hard to keep that all in your head.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Paolo Ciarrocchi]

On Sat, 23 Oct 2004 09:12:53 -0700, Larry McVoy <lm@bitmover.com> wrote:
> On Tue, Oct 19, 2004 at 03:11:55PM -0700, Linus Torvalds wrote:
> > On Tue, 19 Oct 2004, Paolo Ciarrocchi wrote:
> > > I know I'm pedantic but can we all see the list of bk trees ("patches
> > > ready for mainstream" and "patches eventually ready for mainstream")
> > > that we'll be used by Linus ?
> >
> > Even _I_ don't have that kind of list.
> 
> I don't know how you could have that sort of list.  We have some idea
> of the potential size of that list and it's huge.  Based on the lease
> requests back to us (BK is lease based, it connects back to us once a
> month), we estimate that there well over 10,000 clones of the Linux kernel
> in BK.  If even 1/10th of those are going to have a patch for Linus that's
> 1,000 potential patches.  Pretty hard to keep that all in your head.

Well, I'm not interested in having the list of all the bk trees used
during the develpoment of a release.
I was looking to the trees used by mantainers.
That number should me really different from "1,000".
Do you agree ?

CIao,
-- 
Paolo
Personal home page: www.ciarrocchi.tk
Picasa users groups: www.picasa-users.tk
join the blog group: http://groups-beta.google.com/group/blog-users

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 24, 2004 at 12:24:42PM +0200, Paolo Ciarrocchi wrote:
> On Sat, 23 Oct 2004 09:12:53 -0700, Larry McVoy <lm@bitmover.com> wrote:
> > On Tue, Oct 19, 2004 at 03:11:55PM -0700, Linus Torvalds wrote:
> > > On Tue, 19 Oct 2004, Paolo Ciarrocchi wrote:
> > > > I know I'm pedantic but can we all see the list of bk trees ("patches
> > > > ready for mainstream" and "patches eventually ready for mainstream")
> > > > that we'll be used by Linus ?
> > >
> > > Even _I_ don't have that kind of list.
> > 
> > I don't know how you could have that sort of list.  We have some idea
> > of the potential size of that list and it's huge.  Based on the lease
> > requests back to us (BK is lease based, it connects back to us once a
> > month), we estimate that there well over 10,000 clones of the Linux kernel
> > in BK.  If even 1/10th of those are going to have a patch for Linus that's
> > 1,000 potential patches.  Pretty hard to keep that all in your head.
> 
> Well, I'm not interested in having the list of all the bk trees used
> during the develpoment of a release.
> I was looking to the trees used by mantainers.

And how do you define a maintainer?  That's a moving target.  Part of the
beauty of the Linux development model is that mini forks are not only
allowed, they are encouraged.  So people can go off on their own and do
something interesting.  Who knows?  One of those people could be the next
Alan.  

> That number should me really different from "1,000".

Sure.  But even so it's a moving target and labeling a set of people as 
maintainers implies that other people aren't.  I suspect Linus isn't 
that interested in the labels, he'll take good code from anyone.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Paolo Ciarrocchi]

On Sun, 24 Oct 2004 07:44:48 -0700, Larry McVoy <lm@bitmover.com> wrote:
> On Sun, Oct 24, 2004 at 12:24:42PM +0200, Paolo Ciarrocchi wrote:
[...]
> >
> > Well, I'm not interested in having the list of all the bk trees used
> > during the develpoment of a release.
> > I was looking to the trees used by mantainers.
> 
> And how do you define a maintainer?  That's a moving target.  Part of the
> beauty of the Linux development model is that mini forks are not only
> allowed, they are encouraged.  So people can go off on their own and do
> something interesting.  Who knows?  One of those people could be the next
> Alan.

I totally agree on the "beauty of Linux development" part of your statement,
I don't 100% agree on your definition of maintainer.
There a few well defined maintainer in the community and those names
are defined and written in the kernel documentation.
So, I think that is moving target but we have a few stable and well
know references.

> > That number should me really different from "1,000".
> 
> Sure.  But even so it's a moving target and labeling a set of people as
> maintainers implies that other people aren't.  I suspect Linus isn't
> that interested in the labels, he'll take good code from anyone.

Good point, 
even though I'm almost sure that both Linus and Andrew prefer getting
patches after they are reviewed by those "maintainers".

Anyway, 
I'm not a kernel hacker at all so my comments will sound just silly to
a lot of people involved in the development but as a user I'm
sometimes "alarmed" by the lack of formality in the development
process (see the naming wars),

Maybe we cannot avoid it, maybe that's the reason because linux is
"the best free OS" but maybe we can add a few more rules/indications
to the process.

Larry,
thank you for your answer, I always appreciate having such a kind of
open discussions with people that are really involved in the
development.

Ciao,
-- 
Paolo

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 24, 2004 at 06:44:38PM +0200, Paolo Ciarrocchi wrote:
> I totally agree on the "beauty of Linux development" part of your statement,
> I don't 100% agree on your definition of maintainer.

I explicitly didn't define maintainer.  That's the beauty of Linux
development.  I've been around for more than a decade in the Linux kernel
and people come and people go.  People show up and prove themselves and
become more important because they _are_ more important.  Not because
they have the maintainer title.

Linus sets the tone on this one, he has always played it fairly harshly
in that he respects the work you did today.  What you did (or did not do)
yesterday isn't relevant.  One way to sum it up is "There is no tenure
in Linux kernel development".  You are useful as long as you are useful
and then you get pushed aside.  I don't always agree with this model,
I think it has chased away some useful people who felt like "Linus owed
them" but on the other hand it is extremely open to new useful people.

> There a few well defined maintainer in the community and those names
> are defined and written in the kernel documentation.
> So, I think that is moving target but we have a few stable and well
> know references.

Yeah but focussing on them is the wrong answer.  Who knew who Andrew
Morton was 5 years ago?  He's clearly one of the most important people
around today but tomorrow someone else may emerge.  No offense at all
intended towards Andrew, he's clearly kicking butt, I watch his trees,
the amount of work he does is astounding, if you aren't watching you
should be.  But the cool part of the process is that Andrew came out of
left field and became who he is.

I've worked at places where it was all about who you knew, that sort of
clubby old boy feeling, and new people had a very tough time breaking
into the system.  The Linus model is crushingly hard on people who
have paid their dues but have slowed down, that's the "no tenure" part,
but the good part is that you don't have to be anybody to be important.
You just need to be good.  All the rest is just talk.

> I'm not a kernel hacker at all so my comments will sound just silly to
> a lot of people involved in the development but as a user I'm
> sometimes "alarmed" by the lack of formality in the development
> process (see the naming wars),

I was interviewed by a guy at Business Week a few days ago about this
process and I tried to get the point across that there actually is
a process but it's more of a zen thing than something that managers
would like.

> Larry,
> thank you for your answer, I always appreciate having such a kind of
> open discussions with people that are really involved in the
> development.

Sadly, I'm not at all involved in the development other than as someone
who is trying to help indirectly.  BK is clearly helping, I think even
the BK license haters have finally admitted that, but I'm pretty much
out of the process.  I'm just like you, sitting on the sidelines admiring
what is going on. As Linus said in some mail to me a while back, I'm like
the guy who provides the lumber for the house raising.  No matter how much
I'd like to be a part of the house raising, I'm not, I'm just a vendor
providing some needed parts.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Matthias Urlichs]

Hi, Larry McVoy wrote:

> I was interviewed by a guy at Business Week a few days ago about this
> process and I tried to get the point across that there actually is a
> process but it's more of a zen thing than something that managers would
> like.

So, did you point him at Linus' Documentation/ManagementStyle paper?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: BK kernel workflow

[Andrea Arcangeli]

On Sun, Oct 24, 2004 at 04:32:14PM -0700, Larry McVoy wrote:
> the BK license haters have finally admitted that, [..]

dream on

Re: BK kernel workflow

[Joe Perches]

On Mon, 2004-10-25 at 13:46 +0200, Andrea Arcangeli wrote:
> On Sun, Oct 24, 2004 at 04:32:14PM -0700, Larry McVoy wrote:

More completely, Larry said:
"BK is clearly helping, I think that even"

> > the BK license haters have finally admitted that, [..]

> dream on

Andrea, I'm confused by your response.

Are you suggesting one or more of:

1. BK has improved LK workflow
2. BK has not improved LK workflow
3. BK has had no impact on LK workflow
4. you hate the license

Any of these or something else?

If your answer does not include 1, why?

I've read http://kerneltrap.org/node/view/3148

>From my view, LK workflow post patch penguin (ie: BK)
is improved simply because fewer patches seem to be lost.

I too do not use BK because of the license restrictions
on developing any other SCM systems.  I think that portion
of the license is just wrong, but BK is BitMover's product
and I believe Larry can license it as he chooses.

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 05:29:02AM -0700, Joe Perches wrote:
> 1. BK has improved LK workflow
[..]
> If your answer does not include 1, why?

as a matter of fact nobody can know how the workflow would be if _all_
kernel developers would have been able to take advantage of a
distributed revision control system in the last ~3 years. The simple
fact I try to avoid discussing this topic on public lists to avoid be
targeted as whiner as usual, doesn't mean Larry can speak for myself
saying the few people like me now changed their mind and they agrees BK
generally helps the workflow.

> From my view, LK workflow post patch penguin (ie: BK)
> is improved simply because fewer patches seem to be lost.

IMHO that's largerly thanks to Andrew, and he's not using BK but quilt
to manage -mm, and as far as I can see his merges with Linus are using
patches. Infact I'm only sending my seldom patches to Andrew.

Re: BK kernel workflow

[Linus Torvalds]

On Mon, 25 Oct 2004, Andrea Arcangeli wrote:
> 
> as a matter of fact nobody can know how the workflow would be if _all_
> kernel developers would have been able to take advantage of a
> distributed revision control system in the last ~3 years.

.. and nobody knows how the universe would look if the speed of light 
wasn't constant.

Your point is pointless. No such distributed revision control system 
exists. And without BK, the people who have worked on them wouldn't 
largely even understand what's wrong with CVS.

In fact, I find that people largely _still_ don't understand what's wrong
with CVS, and are still trying to just make another CVS thing.

So give Larry the credit he deserves, even if you dislike the license.

		Linus

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 08:14:25AM -0700, Linus Torvalds wrote:
> Your point is pointless. No such distributed revision control system 
> exists. And without BK, the people who have worked on them wouldn't 

arch exists and it's exactly as distributed as BK.

Re: BK kernel workflow

[Linus Torvalds]

On Mon, 25 Oct 2004, Andrea Arcangeli wrote:
> 
> arch exists and it's exactly as distributed as BK.

And I looked at it before starting BK. Trust me, it was nowhere _near_ 
usable, which was my point. Nothing you have described has existed for 
three years. Except for BK.

I doubt arch is there today either, but hey, if it displaces CVS, I 
certainyl won't complain. How are the gcc people doing with it?

		Linus

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 09:10:47AM -0700, Linus Torvalds wrote:
> I doubt arch is there today either, but hey, if it displaces CVS, I 
> certainyl won't complain. How are the gcc people doing with it?

gcc people are stuck with CVS AFIK. Apparently CVS is good enough for
them.

arch isn't ready for prime time with the kernel. It would be ready if we
were ok to limit it to say 5000 changesets and to obsolete the older
changesets once in a while. the backend needs a rewrite to handle that.

Thanks to various improvements we did (I only did one that allows
caching with hardlinked trees, Chris and others did more), probably arch
would be already way faster than BK in a daily checkout checkin and
cloning (nobody on the open source side can verify since we cannot use
BK, AFIK Miles tried to buy a copy of BK but Larry refused to sell it,
but I seriously doubt BK has such an advanced hardlinking cache
mechanism like arch), but the very first setup on a new machine would be
very inefficient (if compared to CVS) and the local copy of the
repository would take more space (again if compared to CVS).

The user interface isn't nice either, it'd be nicer at least to avoid
overlaps between commands.

I believe this all can be fixed, it just needs a critical mass of users
and some big initial pain.

Re: BK kernel workflow

[Jeff Garzik]

Andrea Arcangeli wrote:
> On Mon, Oct 25, 2004 at 08:14:25AM -0700, Linus Torvalds wrote:
> 
>>Your point is pointless. No such distributed revision control system 
>>exists. And without BK, the people who have worked on them wouldn't 
> 
> 
> arch exists and it's exactly as distributed as BK.


It doesn't scale or merge as well as BK though.

I've told Larry that, if both BK and <open source tool> were completely 
equal in terms of function, I'd use the open source tool.  Neither arch 
(scalability) nor subversion (scalability + stability) are there yet.

	Jeff

Re: BK kernel workflow

[Miles Bader]

Jeff Garzik <jgarzik@pobox.com> writes:
>> arch exists and it's exactly as distributed as BK.
>
> It doesn't scale or merge as well as BK though.

Examples?

Scalability I'm not sure about; BK's "you must inform BK before you
change a file" model gives it a potential for being very quick at
"tree-compare" operations -- but makes it more annoying for the user.

Merging also seems a bit hard to judge.  From what I understand of BK,
it has a much more limited merging model than arch does; to do a
reasonable comparison, you'd have to see how well arch did if you
limited yourself to that restricted model, and then give arch some more
points for not forcing you to do so.

BK no doubt wins on the rough-edges-sanded-down front though; there are
a _few_ advantages to commercial software...

-Miles
-- 
97% of everything is grunge

Re: BK kernel workflow

[Larry McVoy]

On Mon, Oct 25, 2004 at 03:39:51PM +0200, Andrea Arcangeli wrote:
> On Mon, Oct 25, 2004 at 05:29:02AM -0700, Joe Perches wrote:
> > 1. BK has improved LK workflow
> [..]
> > If your answer does not include 1, why?
> 
> as a matter of fact nobody can know how the workflow would be if _all_
> kernel developers would have been able to take advantage of a
> distributed revision control system in the last ~3 years. The simple
> fact I try to avoid discussing this topic on public lists to avoid be
> targeted as whiner as usual, doesn't mean Larry can speak for myself
> saying the few people like me now changed their mind and they agrees BK
> generally helps the workflow.

That's strange, I wonder why you think BK doesn't help.  The prevailing
wisdom is that it has helped.  It's well documented by third parties
who have nothing to do with you or me.

Is it possible that you have an axe to grind about BK and that any
positive statement about BK will be challenged by you no matter how
silly that makes you appear?

Maybe you know about some different system that would have worked better.
Perhaps you could share with the rest of us what that system is and how
it works better. 

> > From my view, LK workflow post patch penguin (ie: BK)
> > is improved simply because fewer patches seem to be lost.
> 
> IMHO that's largerly thanks to Andrew, and he's not using BK but quilt
> to manage -mm, and as far as I can see his merges with Linus are using
> patches. Infact I'm only sending my seldom patches to Andrew.

The implication that Andrew doesn't use BK is incorrect, we see him in
the logs all the time.  You're right that he uses other tools to manage
his collection of patches and we agree with his reasons for doing so.
But he also uses BK and has pointed out himself the fact that BK has
helped the kernel development effort.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 09:20:22AM -0700, Larry McVoy wrote:
> The implication that Andrew doesn't use BK is incorrect, we see him in
> the logs all the time. [..]

I assume this is great news for bitmover: one more tainted open source
developer that will not be allowed by law to ever compete with your
business, right? Anyways this is offtopic for l-k, but you can still
celebrate elsewhere.

Re: BK kernel workflow

[Larry McVoy]

On Mon, Oct 25, 2004 at 06:47:32PM +0200, Andrea Arcangeli wrote:
> On Mon, Oct 25, 2004 at 09:20:22AM -0700, Larry McVoy wrote:
> > The implication that Andrew doesn't use BK is incorrect, we see him in
> > the logs all the time. [..]
> 
> I assume this is great news for bitmover: one more tainted open source
> developer that will not be allowed by law to ever compete with your
> business, right? Anyways this is offtopic for l-k, but you can still
> celebrate elsewhere.

You have made this point hundreds of times, everyone knows your position
that we're screwing over the open source world by preventing them from
copying our work.  OK, I can see that you think that, we respectfully
disagree because we feel we have to protect our IP.  Rightly or wrongly,
we feel we did some new work that is worth protecting.

The big flaw in your position is that you are not tainted, you are a good
programmer, you claim to care deeply about this issue, so you could go
solve the problem.  Either by fixing arch or creating your own system.
You should be the poster child for why the BitKeeper license is a
flawed idea.  

We both think we care about helping the kernel.  You think that we're
screwing over a pile of people who could write a GPLed SCM system.
We think that that is not true and you yourself prove our point.  Kernel
guys like working on the kernel.  If they liked working on SCM they would
be doing that, there would be a GPLed answer that was better than BK or at
least good enough, and we wouldn't be arguing, we'd probably be friends.

So who cares more about the kernel development process?  The guy who took
crap from you and your friends for years but cared enough to keep going
because what counted were _results_, or the guy who sits around and whines
that we are polluting the well which was already dry?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 10:12:23AM -0700, Larry McVoy wrote:
> We think that that is not true and you yourself prove our point.  Kernel
> guys like working on the kernel. [..]

This is sure fine with Linus and Andrew (peraphs even with myself), but
not everybody is Andrew and Linus. The reason I don't use it myself is
to avoid tainting _other_ people that might be beginners that might one
day write their own GPL'd SCM.

Re: BK kernel workflow

[Linus Torvalds]

On Mon, 25 Oct 2004, Andrea Arcangeli wrote:
> 
> I assume this is great news for bitmover: one more tainted open source
> developer [...]

Andrea, shut up.

It's not _your_ decision to make, or your decision to complain about. It's
the developers decision. It was mine, Jeff's, David's, Andrew's... Not
yours.

It's your decision is to not use BK. Fine. But then complaining when
people decide to use the best tool available is fricking impolite. Not
just to Larry, but to the people who made the choice.

You whine about BK taking rights away, but the fact is, BK is an _option_
for people to use. _YOU_ are the one trying to limit what people are
supposed to do.

In short, BK isn't the problem. You are.

		Linus

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 10:18:27AM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 25 Oct 2004, Andrea Arcangeli wrote:
> > 
> > I assume this is great news for bitmover: one more tainted open source
> > developer [...]
> 
> Andrea, shut up.
> 
> It's not _your_ decision to make, or your decision to complain about. It's
> the developers decision. It was mine, Jeff's, David's, Andrew's... Not
> yours.
> 
> It's your decision is to not use BK. Fine. But then complaining when
> people decide to use the best tool available is fricking impolite. Not
> just to Larry, but to the people who made the choice.
> 
> You whine about BK taking rights away, but the fact is, BK is an _option_
> for people to use. _YOU_ are the one trying to limit what people are
> supposed to do.
> 
> In short, BK isn't the problem. You are.

you know, I cannot care less if I'm the problem. And I won't shut up.

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Mon, 25 Oct 2004, Linus Torvalds wrote:

> In short, BK isn't the problem. You are.

I think you're making it yourself way too easy.

There is a certain ego problem, that makes a more rational discussion 
about the real influence of bk rather difficult. bk makes it in first 
place easier to apply and merge a lot of patches, but patches still have 
to be written, reviewed and maintained. The ability to handle big amounts
of patches includes also the possibility to merge a lot of crap. What 
keeps up the general quality? It would be a lot easier to give Larry some 
credit here, if he hadn't already taken it all.

There is a certain license problem, which very effectly keeps out a lot of 
those people, who might have other ideas for managing the kernel sources 
and improving the development process. The "protecting IP" talk is 
complete bullshit, one doesn't need direct access to figure out how it 
works. There are a few free SCM systems out there, that use very similiar 
mechanism, they of course still need to work out the details, but it's no 
magic and just takes times. Being able to import the kernel repository 
into them would be a great way to test them, but unfortunately all the 
free testing is reserved for bk, as usual the winner takes it all and the 
losers eat the dust, isn't that how open source works...?

Blaming Andrea for this mess is of course easy, but it doesn't solve 
anything and misses the point, the only thing Andrea is to blame for is 
that he is not very diplomatic, but that's unfortunately a trait seldom 
found under hackers. Ignoring the problems and silencing the critics 
doesn't solve anything and I would be more concerned if nobody would 
object anymore, when Larry is on one of his ego trips.

bye, Roman

Re: BK kernel workflow

[Linus Torvalds]

On Tue, 26 Oct 2004, Roman Zippel wrote:
> 
> On Mon, 25 Oct 2004, Linus Torvalds wrote:
> 
> > In short, BK isn't the problem. You are.
> 
> I think you're making it yourself way too easy.
>
> Blaming Andrea for this mess is of course easy, but it doesn't solve 
> anything and misses the point

[ Answering these in a different order ]

The only thing I blame Andrea for is _whining_. Don't get me wrong, I 
don't blame him for the bad state of CVS or anything like that.

The fact is, Andrea doesn't actually do anything constructive when it 
comes to SCM. He just complains every time somebody says something 
positive about a product that (a) he didn't do anything for and (b) nobody 
forces him to use, and (c) there are no real alternatives for today (much 
less the three years ago he was whining about).

> The ability to handle big amounts of patches includes also the
> possibility to merge a lot of crap. What keeps up the general quality?

No SCM is _ever_ going to be a quality manager.

And I also claim that people who think that "processes" are quality 
management (see iso9000, or Dilbert) are seriously mistaken too.

The thing that keeps up the general quality is _people_. Good people, who 
take pride in the quality. They end up being maintainers, not because they 
chose the job, but because people ended up chosing them, for better of for 
worse.

And the way to help those people is to make the day-to-day job easy, so
that they can spend as much time as possible on the thing that matters:  
upholding good taste (and in the process keeping quality up). And that's
where an SCM comes in - not as a primary source of quality, but as a way
to keep track of the details, so that people can concentrate on what is
important.

And the SCM doesn't have to be anything really fancy. It can be a few 
scripts to keep track of patches (that tends to grow and become slightly 
more sophisticated over time). I'm not saying that BK is "it". There's a 
number of BK users there, but clearly there are other ways to maintain 
patches too - and people use them.

But complaining when a maintainer uses a tool that suits him is _stupid_. 
It's arrogant to think that you can tell me how to do my work, but it's 
really stupid when you can't give any reasonable alternatives that would 
help me do it as efficiently.

And that's what Andrea is doing. Sure, BK is commercial, but dammit, so is
that 2GHz dual-G5 too and that Shuttle box in my corner. They happen to be
the tools I use for what I do. If Andrea told me that I should use a
slower machine because that's what most people use, I'd consider him a
total idiot. Similarly, when he complains that people use software tools
that clearly _do_ make them more productive, I consider his complaint
stupid.

There are other tools I use to make myself more productive. Many of them
are open source. Some I wrote myself. But I still use "uemacs" and "pine"  
as part of my tool-chest, for example - and last I saw, they weren't open
source either (but I hear that the uemacs author stopped caring, so that
one might have been re-licensed).

Should I (or anybody else) ask Andrea's permission before we start using 
non-opensource tools? No.  If Andrea were complaining about my "pine" 
usage, he'd be laughed off the planet. It may be ass-backwards and old and 
text-only, but the fact is, it's really none of his damn business, even 
though he can see the effects in every email I write in the headers.

Similarly, Andrea can see some of the effects of me using BK when he looks
at the tar-balls and patches - syntactic markers that show that they have
been generated by a person who uses BK. It's really _no_ different from
the fact that I use pine to communicate. And no, neither BK nor pine are
under an open source license.  Deal with it.

Can Andrea point me to open-source tools and ask me politely whether I've 
considered them as alternatives? Hell yes. I encourage him to do so when 
something appears.

		Linus

Re: BK kernel workflow

[Miles Bader]

Linus Torvalds <torvalds@osdl.org> writes:
> The fact is, Andrea doesn't actually do anything constructive when it 
> comes to SCM.

This is not true.

Andrea has given some very useful input on the gnu-arch mailing list.
He's definitely doing more than just complaining about BK.

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Mon, 25 Oct 2004, Linus Torvalds wrote:

> The only thing I blame Andrea for is _whining_. Don't get me wrong, I 
> don't blame him for the bad state of CVS or anything like that.

You must be seeing something I don't. Andrea was objecting to how Larry 
was practically declaring defeat for the "bk haters", how you're defining 
this as whining I don't know.

> The fact is, Andrea doesn't actually do anything constructive when it 
> comes to SCM. He just complains every time somebody says something 
> positive about a product that (a) he didn't do anything for and (b) nobody 
> forces him to use, and (c) there are no real alternatives for today (much 
> less the three years ago he was whining about).

Miles already mentioned that you're wrong here and I don't really know 
what you expect here from him.

> > The ability to handle big amounts of patches includes also the
> > possibility to merge a lot of crap. What keeps up the general quality?
> 
> No SCM is _ever_ going to be a quality manager.

No disagreement here, but that wasn't really point I was trying to make.

> And that's what Andrea is doing. Sure, BK is commercial, but dammit, so is
> that 2GHz dual-G5 too and that Shuttle box in my corner. They happen to be
> the tools I use for what I do. If Andrea told me that I should use a
> slower machine because that's what most people use, I'd consider him a
> total idiot. Similarly, when he complains that people use software tools
> that clearly _do_ make them more productive, I consider his complaint
> stupid.

Your analogy is flawed, nobody cares what you are using privately, but 
your decisions as kernel maintainer have an effect on other people, may 
this be the patches you include in the next release or the tools you 
distribute them with.
In the end it's your decision what tools you use, if you think the 
advantages outweigh the license which goes contrary to the open 
devolopment process, that's fine, but so have other people the right to 
disagree with that decision. Maybe you could make some suggestion on how 
to articulate this more politically correct?
Linus, what disturbs me here is that I don't see that you don't even try 
to acknowledge that the bk license might be part of problem, you don't 
mention the bk license with a single word. Nobody hates bk, that's a myth 
I'd expect from Larry but not from you. bk is a rather innocent and 
certainly useful tool, the annoying part are the business practices of its 
owner, who tries to push a licence into an environment, where it has to 
provoke rejection.

bye, Roman

Re: BK kernel workflow

[Linus Torvalds]

On Wed, 27 Oct 2004, Roman Zippel wrote:
>
> Linus, what disturbs me here is that I don't see that you don't even try 
> to acknowledge that the bk license might be part of problem

Why?

What's the problem? You don't like it, you don't use it. It's literally 
that simple.

This is the same thing as with the GPL. I absolutely _detest_ people who 
whine about the GPL - and there are more GPL haters out there than BK 
haters. It's _their_ problem. 

EXACT SAME THING. Nobody has the right to whine about another persons
choice of license. You have a choice: use it or don't. Complaining about
the license to the author isn't part of it.

Larry can tell you that we've discussed the BK license in private, and he
definitely knows that I'd really like for it to be an open source license.  
But I also suspect that Larry will tell you that I haven't been whining
about it - I've been trying to come up with ways it could work out for
him, considering that he's got employees to take care of, and I haven't
been able to come up with anything that would convince him. Fair enough.

Because it really is his choice.  Not mine.  Not yours. Not Andrea's.

And dammit, that choice is as close to "sacred" as anything can get in
software development as far as I'm concerned. 

To paraphrase Voltaire - "I may disagree with your choice of license, but
I shall defend to the death your right to choose it". That goes for Larry,
and for the BSD people and for all the people who write software for a
living using some really nasty licenses.

And the same thing goes for users. Anybody who tells me I can't use a
program because it's not open source, go suck on rms. I'm not interested. 
99% of that I run tends to be open source, but that's _my_ choice, dammit.

		Linus

Re: BK kernel workflow

[Larry McVoy]

On Tue, Oct 26, 2004 at 08:00:18PM -0700, Linus Torvalds wrote:
> Larry can tell you that we've discussed the BK license in private, and he
> definitely knows that I'd really like for it to be an open source license.  
> But I also suspect that Larry will tell you that I haven't been whining
> about it - I've been trying to come up with ways it could work out for
> him, considering that he's got employees to take care of, and I haven't
> been able to come up with anything that would convince him. Fair enough.

We (BitMover) wrestle with this all the time, or at least I do.  I think
that the set of people on this list have no idea how painful it has
been for me to do what we have done.  I started out as one of you and
liked it that way.  I saw a problem, Linus needed a tool, and I saw a
solution, I could give him that tool.  So far, so good.  But the effort
required to produce that tool cost a lot of money.  So I had to start
a company, get some help, get other people involved.  This is a way 
bigger problem than I can solve, and as I'm fond of saying, most of 
the people at BitMover are dramatically smarter than I am and that's
what it takes.

I went to lunch one day and just for fun, err, morbid fascination,
I started counting up what I had put into BK and I stopped counting
at $600K.  At the time, it represented 1/3 of the money I had made in
my life.  1/3.  Any of you jerkoffs whining about our license given up
1/3 of what you have made to date to help Linux?  I didn't think so.
And just for the record, no, I haven't made that back yet from BK, not
even close, I'm at least still $550K in the hole.  I'm not complaining,
I'm just pointing out that the whiners are whining but they aren't
coughing up any money or any effort, they are just whining.  Disgusting,
isn't it?  It is to me.

The reason Linus hasn't come up with an answer for how we could open
source BK is that you guys think this is easy.  It's one thing to
take a widely perceived as difficult problem and come up with an open
source solution and charge for it.  It's quite another thing to take
a widely perceived as easy but in reality difficult problem and charge
for an open source solution.  Just ask the SVN guys.  That's not an open
source project, it's funded by HP and other big companies.  The second
that funding dries up are you going to go work on SVN?  How much code
have you contributed to SVN?  Or Arch?  Or whatever?  What?  Nothing?
But you still have the balls to think this is all easy.  OK, that's fine,
and that's why Linus isn't getting anywhere with me.

I'm very less than thrilled with being crapped on for helping out in the
best way could.  It's especially annoying when people do it who have no
idea what it took to help out the way we did.  I've long since gotten
over any thought of being accepted by this community as part of them,
that's just dead.  But if you think I'll sit by while jerkoffs like
Andrea and Roman piss all over us for helping, think again.  As far as
I'm concerned they can kiss my ass.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Matthias Urlichs]

Hi, Larry McVoy wrote:

> As far as I'm concerned [ flame deleted ]

Um, Larry, didn't you say some time ago that you'd stop doing that?

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: BK kernel workflow

[Buddy Lucas]

On Tue, 26 Oct 2004 21:18:14 -0700, Larry McVoy <lm@bitmover.com> wrote:
> On Tue, Oct 26, 2004 at 08:00:18PM -0700, Linus Torvalds wrote:
> > Larry can tell you that we've discussed the BK license in private, and he
> > definitely knows that I'd really like for it to be an open source license.
> > But I also suspect that Larry will tell you that I haven't been whining
> > about it - I've been trying to come up with ways it could work out for
> > him, considering that he's got employees to take care of, and I haven't
> > been able to come up with anything that would convince him. Fair enough.
> 
> We (BitMover) wrestle with this all the time, or at least I do.  I think
> that the set of people on this list have no idea how painful it has
> been for me to do what we have done.  I started out as one of you and
> liked it that way.  I saw a problem, Linus needed a tool, and I saw a
> solution, I could give him that tool.  So far, so good.  But the effort
> required to produce that tool cost a lot of money.  So I had to start

Open Source projects produce excellent tools too. But I'll take your
word for it that there was no other way. The thing is, and I'm afraid
that many among your criticasters do not get this -- even with Linus
saying it over and over again: trying to refrain people from using the
software they want to use has nothing to do with freedom.

BK's license, the language used to write it, Larry's face, or all of
the above, are absolutely *no* justification for the way some of you
come down on Larry.  If you think the BK license interferes in a bad
way with Linux development and you can back it up with solid reasoning
or facts, you might have a point and you should speak up (or start
coding)-- probably using another soapbox, by the way. And drop the
attitude.

Otherwise, what tools other people use is no business of yours. If
that thought bothers you, rethink whether you are really part of a
community that cares deeply about freedom.

Larry, thanks for what's obviously a great piece of software.


Cheers,
Buddy

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Tue, 26 Oct 2004, Linus Torvalds wrote:

> > Linus, what disturbs me here is that I don't see that you don't even try 
> > to acknowledge that the bk license might be part of problem
> 
> Why?

To answer that you should have quoted a bit more: "the annoying part are 
the business practices of its owner".

> What's the problem? You don't like it, you don't use it. It's literally 
> that simple.

Unfortunately it's not that easy, because you're still missing the point.
I don't care what software you use, I don't care what license Larry uses 
for its products. I absolutely don't care.
The problem is that you support a license which limits everyones ability 
on how to access the kernel source and gives Larry full control over it. 
Give me a good reason, why he can deny me that rather simple request to 
get some data out of the repository. On the one hand you blame Andrea for 
not developing an alternative, on the other hand we don't have access to 
the data to actually help other projects. The kernel source is the data 
that we care most about, why can Larry limit the ways we can make use of 
it?
Linus, what happened to the early promises, that the data wouldn't be 
locked into bk? Is the massively reduced data set in the cvs repository 
really all we ever get out of it again?

bye, Roman

Re: BK kernel workflow

[Linus Torvalds]

On Wed, 27 Oct 2004, Roman Zippel wrote:
>
> The problem is that you support a license which limits everyones ability 
> on how to access the kernel source and gives Larry full control over it. 

Ok, Roman, you're on some pretty strong medication.

I'm behind three layers of firewalls (don't ask), and Larry definitely 
doesn't have full control over anything.

Did you think "kernel.bkbits.net" is my source tree? Dream on. My personal
source tree is on my own machine, nobody touches it but me. That's how I
have _always_ worked. The public ones are just random other repositories, 
they get pushed to by me and nobody else.

And I mean that "nobody else". If somebody else tried to push something
else than what is in my tree into them, I'd notice, because of how BK
works. My pushes just wouldn't _work_.

And you get a lot more data out of the kernel repostitory than you got
_before_ I was using BK, in a much more timely manner - even if you're not 
a BK user. You get tar-balls and patches every night, something that just 
wouldn't happen without a SCM that I liked.

> Give me a good reason, why he can deny me that rather simple request to 
> get some data out of the repository.

Give me _one_ good reason you think you have the right to anything more?

The alternative to me using BitKeeper would be patches and tar-balls. 
Which you already have. So why are you complaining? BK isn't taking 
anything away from you.. 

Since you seem to be blind to the problem, let's try it one more time. 

The BK license is _exactly_ the same issue as with the GPL. In the GPL, 
the rule is "tit for tat" - you get to play with the sources, but in 
exchange you have to give out your modifications. Some people complain 
about that, and I call them worthless whiners.

In the BK license, it's "tit for tat". You get to use Larry's program, in 
exchange for not competing with him. Some people complain about that, and 
I call them worthless whiners.

See the pattern? In both cases, the answer is: if you don't like it, don't 
use it. And in both cases, if you don't use it, you are no worse off than 
if it didn't exists, so it's not like the existence of GPL'd programs or 
BK is making your life any worse.

Sure, your life could be better if you accepted the rules. But that's the 
whole POINT of the rules. That's why the GPL works - people accept the 
fact that they have to make modifications available, because they think 
that it's worth it for them. Same is true of the BK users - they accept 
the license because they think it's worth it for them.

Or they don't. Their (your) choice. Don't whine to me or to Larry. It's
_your_ problem, and it is for _you_ to solve. Not me.

		Linus

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Wed, 27 Oct 2004, Linus Torvalds wrote:

> The alternative to me using BitKeeper would be patches and tar-balls. 
> Which you already have. So why are you complaining? BK isn't taking 
> anything away from you.. 

Linus, what happened to the early promises, that the data wouldn't be 
locked into bk? Is the massively reduced data set in the cvs repository 
really all we ever get out of it again?

> Since you seem to be blind to the problem, let's try it one more time. 
> 
> The BK license is _exactly_ the same issue as with the GPL. In the GPL, 
> the rule is "tit for tat" - you get to play with the sources, but in 
> exchange you have to give out your modifications. Some people complain 
> about that, and I call them worthless whiners.
> 
> In the BK license, it's "tit for tat". You get to use Larry's program, in 
> exchange for not competing with him. Some people complain about that, and 
> I call them worthless whiners.
> 
> See the pattern? In both cases, the answer is: if you don't like it, don't 
> use it. And in both cases, if you don't use it, you are no worse off than 
> if it didn't exists, so it's not like the existence of GPL'd programs or 
> BK is making your life any worse.

You can play this game with every license, if a licence had no conditions 
it wouldn't be a license anymore. If you want to get anywhere with this, 
why don't you look at the purpose of the license?
The only purpose of the bk license is to protect the business case of its 
owner with all its consequences, which you are trying very hard to avoid 
to discuss.
One of these consequences is that you cannot convert that repository on 
your harddisk into a different format, no matter behind how many firewalls 
you hide it. This makes your question for alternatives rather pointless, 
you couldn't use them anyway, even if they existed, unless you want to 
throw away the current history.
Why are you avoiding to discuss these consequences? Your actions as kernel 
maintainer don't happen in isolation, they have an effect on other people, 
positive as negative. Concentrating only on the positive and doing 
personal attacks can't hide the reality forever. Call me whatever you 
want if it makes you feel better, but I'll continue to look on both sides 
of the story.

I make a last attempt to make this more clear. I don't care what tools you 
use, I don't care if I can't use them, but why is it acceptable for you to 
cut off _any_ possibility for me to archive the same result in some other 
way? I don't want to drink away your beer and I don't want to control what 
you watch on your TV. We are talking about the kernel repository here, 
which is a shared resource a lot of people helped to create, but why is it
acceptable for you, that some of them can't benefit from it like the rest.
Linus, this is not some random project, this is a public project with 
higher moral standards, why is acceptable to have different moral 
standards during its development? A goal of Linux is it to preserve the 
freedom of its users, making them independent of a single vendor, why is 
it acceptable to make it a condition that developers have to commit 
themselves to a single vendor in order to get full access to the kernel 
repository?

bye, Roman

Re: BK kernel workflow

[Linus Torvalds]

On Thu, 28 Oct 2004, Roman Zippel wrote:
> 
> Linus, what happened to the early promises, that the data wouldn't be 
> locked into bk? Is the massively reduced data set in the cvs repository 
> really all we ever get out of it again?

Roman, I'm not going to bother fighing your idiotic issues any more.

The data is all there, and has been there since day one. That's what the 
patches are, that's what the tar-balls I do are, and that's what the 
snapshots that others do are.

All there. Since day one.

Go away now. 

> You can play this game with every license

Absolutely. And I do.

What's so hard to understand with the single sentence:

	"Don't complain about other peoples licenses."

And no, it has _nothing_ to do with the GPL vs BK. It's a general truism.  
The fact is, developers can choose whatever license they want for their
own code. And users can choose whatever program they want, as long as they
follow that license. And it's _their_ decisions.

> I don't care what tools you use, I don't care if I can't use them, but
> why is it acceptable for you to cut off _any_ possibility for me to
> archive the same result in some other way?

But I don't. If you don't like BK, use the tar-balls. It's exactly the 
same source tree.

And no, if you don't use BK, you can't use the BK tree. Well DUH! 

And if you want to go write your own SCM, and use your own SCM for doing 
your own Linux development, be my guest. But stop whining about choices 
that OTHER people made, and that you don't have anything to do with.

As it is, you're nothing but an uninvited religious nut at my door, trying
to convince me on your nut-case religion. Sorry, I'm not buing it. *BLAM*
</sound of door closing in your face />

		Linus

Re: BK kernel workflow

[Alan Cox]

On Mer, 2004-10-27 at 21:56, Roman Zippel wrote:
> Linus, what happened to the early promises, that the data wouldn't be 
> locked into bk? Is the massively reduced data set in the cvs repository 
> really all we ever get out of it again?

The daily CVS snapshots seem to solve most of that. Yes BK's licensing
model isn't free software friendly, yes its a PITA. With the CVS
snapshots nobody is forcing your hand, its not encrypted and locked away
behind a DRM system.

Alan

Re: BK kernel workflow

[Pavel Machek]

Hi!

> > Linus, what happened to the early promises, that the data wouldn't be 
> > locked into bk? Is the massively reduced data set in the cvs repository 
> > really all we ever get out of it again?
> 
> The daily CVS snapshots seem to solve most of that. Yes BK's licensing
> model isn't free software friendly, yes its a PITA. With the CVS
> snapshots nobody is forcing your hand, its not encrypted and locked away
> behind a DRM system.

IIRC Larry announced that if we start looking into the data he *will*
encrypt it and try to lock it away...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: BK kernel workflow

[James Bruce]

Linus Torvalds wrote:

>On Wed, 27 Oct 2004, Roman Zippel wrote:
>  
>
>>Linus, what disturbs me here is that I don't see that you don't even try 
>>to acknowledge that the bk license might be part of problem
>>    
>>
>
>Why?
>
>What's the problem? You don't like it, you don't use it. It's literally 
>that simple.
>
>This is the same thing as with the GPL. I absolutely _detest_ people who 
>whine about the GPL - and there are more GPL haters out there than BK 
>haters. It's _their_ problem. 
>
>EXACT SAME THING. Nobody has the right to whine about another persons
>choice of license. You have a choice: use it or don't. Complaining about
>the license to the author isn't part of it.
>  
>

Actually it's not that simple.  With the free BK license it's not _your_ 
choice that affects validity; It's the choice of any person at your 
company deciding for everyone else.  So if one OSDL employee uses the 
free BK licence, *nobody else* at OSDL can work on an SCM, even at home 
in their spare time.  Technically, if any one of the other 10,000 people 
at my university work on an SCM, I can't use it either since they pay 
me.  I try to bury my head in the sand and think that they aren't.  In 
reality however, I can't vouch for what the other 9,999 people are 
doing.  Here's the relevant sentence in the license:

3(d) Notwithstanding  any  other  terms  in  this  License, this License 
is not available to You if You and/or your employer develop,  produce, 
sell, and/or resell a product which contains substantially similar 
capabilities of  the  BitKeeper Software, or, in the reasonable opinion 
of BitMover, competes with the BitKeeper Software.

IOW: "Not available to You if your employer develops anything 
substantially similar."

At least 90% of the whining/hate comes from this single clause in the 
license.  We know from the past that Larry won't budge on it, and that 
is of course his right.  However it is not true to say that this is like 
the GPL, or any MSFT license even.  None of them go that far in 
regulating what *other* people can do, especially what they can do at 
home, away from work.  My uni just opened a branch campus in Qatar;  If 
a student earns $10 to add some feature to SVN, it affects whether I can 
use BK for free at home on an open source project.  The alternative is 
paying a $2,600 per year seat license.

Imagine if in 1991, DOS/Windows cost $2,600 a year, unless you promised 
that neither you nor your employer would work on an operating system.  
That would cause a lot of argument, with pragmatic people trying to use 
the system for ordinary development of non-OSes, and others screaming 
about the "corrupt principles" and pushing alternatives, even if they 
suck in a features comparison.  Why is anyone surprised that this is 
happening now with BK?

BK is by far the best SCM I have ever used, and the only one that 
supports distributed development both sanely and robustly.  But frankly, 
it has a clause in its license that will generate arguments without end, 
ones which will *not* go away with time.

Larry, if anything is wrong in my analysis of the meaning of clause 3c, 
I would love to stand corrected.  Preferably that would take the form of 
an updated license.  I believe the analysis to be consistent with the 
wording of the clause; Several of my colleagues also analyzed the 
license and came to the exact same conclusions.

Jim Bruce
(Sorry for being OT.  Having said my only point on this topic, which 
I've held since the BK thing began, I will return to only reading these 
threads, after this one.  I welcome off-list discussions and/or flames too.)

Re: BK kernel workflow

[Geert Uytterhoeven]

On Thu, 28 Oct 2004, James Bruce wrote:
> 3(d) Notwithstanding  any  other  terms  in  this  License, this License is
> not available to You if You and/or your employer develop,  produce, sell,
> and/or resell a product which contains substantially similar capabilities of
> the  BitKeeper Software, or, in the reasonable opinion of BitMover, competes
> with the BitKeeper Software.

Hence all the Linux people at IBM pay for a BK license, since IBM does
ClearCase these days...

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: BK kernel workflow

[Larry McVoy]

> Actually it's not that simple.  With the free BK license it's not _your_ 
> choice that affects validity; It's the choice of any person at your 
> company deciding for everyone else.  So if one OSDL employee uses the 
> free BK licence, *nobody else* at OSDL can work on an SCM, even at home 
> in their spare time.  Technically, if any one of the other 10,000 people 
> at my university work on an SCM, I can't use it either since they pay 
> me.  I try to bury my head in the sand and think that they aren't.  In 
> reality however, I can't vouch for what the other 9,999 people are 
> doing.  

The reason it is worded that way is so that we avoid the situation where
one guy is doing the work on $SCM and the other guy is sitting there 
running BK commands in order to reverse engineer BK.

We aren't going to come make a fuss if you are using BK and some other
guy is tinkering with CVS, we're not unreasonable people.  On the other
hand, that doesn't give you carte blanche, if your officemate or friend
is working on a BK replacement and you are helping him, yes, we will 
likely make a fuss.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Xavier Bestel]

Le jeu 28/10/2004 à 15:53, Larry McVoy a écrit :

> The reason it is worded that way is so that we avoid the situation where
> one guy is doing the work on $SCM and the other guy is sitting there 
> running BK commands in order to reverse engineer BK.

I don't think you can stop that from happening, legally.

IANAL,
	Xav

Re: BK kernel workflow

[Larry McVoy]

On Thu, Oct 28, 2004 at 04:06:20PM +0200, Xavier Bestel wrote:
> Le jeu 28/10/2004 ?? 15:53, Larry McVoy a ??crit :
> 
> > The reason it is worded that way is so that we avoid the situation where
> > one guy is doing the work on $SCM and the other guy is sitting there 
> > running BK commands in order to reverse engineer BK.
> 
> I don't think you can stop that from happening, legally.

Since you haven't paid for the product, copyright law applies and
that's quite different than contract law.  You get a certain set
of rights, which vary worldwide, when you buy something.  Copyright
is far more restrictive.

"Fair use" != "reverse engineering" in any venue so far as I know.

As always, IANAL, so contact yours for clarification.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Alan Cox]

On Iau, 2004-10-28 at 16:10, Larry McVoy wrote:
> "Fair use" != "reverse engineering" in any venue so far as I know.

Reverse engineering is enshrined in EU law as a right (although this
started due to abuse by car companies not for computing). While people
jump up and down and point to that its not always clear you can do so
for the purposes of cloning rather than interoperability.

Ie its one thing to reverse engineer BK to make a BK->Subversion tool
but quite another to reverse engineer it to reimplement BK

(leaving aside that all the patch files are publically grabbable and
every patch Linus sends goes out to a mailing list so it would be a
rather hard work way of doing it)

I don't use BK. It's not causing problems for me.

Alan

RE: BK kernel workflow

[David Schwartz]

> Since you haven't paid for the product, copyright law applies and
> that's quite different than contract law.  You get a certain set
> of rights, which vary worldwide, when you buy something.  Copyright
> is far more restrictive.
>
> "Fair use" != "reverse engineering" in any venue so far as I know.
>
> As always, IANAL, so contact yours for clarification.

	As I understand the law, at least in the United States, you have the exact
same rights whether you buy the product or get it for free, so long as you
acquire it legally. This includes the right to use the product as it is
normally used. Otherwise, I could write a poem, put it up on billboards, and
then try to sue everyone whose eyes passed over it. This is legally
enshrined in the doctrine of "first sale", which despite its name applies to
any legal acquisition.

	It's not clear whether shrink wrap or other licenses can reduce this basic
right to use that which one lawfully acquires. Some have pointed to various
cases (such as ProCD v. Zeidenberg), but all the cases I have seen have
differed from the shrinkwrap/copyright issue in at least one key respect.

	DS

Re: BK kernel workflow

[Kevin P. Fleming]

David Schwartz wrote:

> 	As I understand the law, at least in the United States, you have the exact
> same rights whether you buy the product or get it for free, so long as you
> acquire it legally.

But there's the rub: acquiring it legally (for free) requires acceptance 
of the license terms. If you do not accept the terms, or accept them but 
later take actions which violate the terms you accepted, you can no 
longer say that you "acquired it legally". You have violated the terms 
of the agreement between the two parties, and the party that owns the 
copyright to the product in question has every right to take action 
against you, if warranted.

You are correct in saying that the mere act of money changing hands does 
_not_ give you any rights that you wouldn't have gotten for free, 
presuming that the license being offered in both cases gives you the 
same rights. In the case of BitKeeper, it does not. The free and for-pay 
licenses give the licensee different rights.

Re: BK kernel workflow

[Alan Cox]

On Iau, 2004-10-28 at 20:38, Kevin P. Fleming wrote:
> But there's the rub: acquiring it legally (for free) requires acceptance 
> of the license terms. If you do not accept the terms, or accept them but 
> later take actions which violate the terms you accepted, you can no 
> longer say that you "acquired it legally". You have violated the terms

Thats not actually the case. The law in countries writes in additional
implicit clauses you cannot avoid and also forbids clauses. Those
clauses vary by country but you'd find in most of the world that a
clause like

3.	Not to be used by Women except for payment of a $500 additional 	tech
support fee

would not be enforcable

RE: BK kernel workflow

[David Schwartz]

> David Schwartz wrote:

> > As I understand the law, at least in the United States, you
> > have the exact
> > same rights whether you buy the product or get it for free, so
> > long as you
> > acquire it legally.

> But there's the rub: acquiring it legally (for free) requires acceptance
> of the license terms.

	I just downloaded bitkeeper, and I didn't have to consent to any license.
So you can legally acquire BitKeeper without accepting the license terms. So
this whole argument is irrelevent

	DS

Re: BK kernel workflow

[David S. Miller]

On Thu, 28 Oct 2004 16:22:25 -0700
"David Schwartz" <davids@webmaster.com> wrote:

> 	I just downloaded bitkeeper, and I didn't have to consent to any license.
> So you can legally acquire BitKeeper without accepting the license terms. So
> this whole argument is irrelevent

You can acquire it, but the first time you ever try to use
it you will be asked to page through the text of the license
and agree to it.

RE: BK kernel workflow

[David Schwartz]

> On Thu, 28 Oct 2004 16:22:25 -0700
> "David Schwartz" <davids@webmaster.com> wrote:

> > 	I just downloaded bitkeeper, and I didn't have to consent
> > to any license.
> > So you can legally acquire BitKeeper without accepting the
> > license terms. So
> > this whole argument is irrelevent

> You can acquire it, but the first time you ever try to use
> it you will be asked to page through the text of the license
> and agree to it.

	That does not matter. Once you lawfully acquire it, you automatically have
the (transferrable!) right to use it. Really. Otherwise, as I said, I could
put my copyrighted poem up on billboards (along with a license if you want)
and then sue everyone who read it.

	In the United States, the license, to be valid, must be a condition of
obtaining lawful possession of the copyrighted work. If you disagree, please
feel free to cite cases where this argument was raised and rejected.

	DS

RE: BK kernel workflow

[Scott Lockwood]

US Courts have recently ruled that EULA's are legal. So when you buy a
copy of MS Office at the store, the EULA it contains is still binding. I
work at the law firm that represents the MPAA and the RIAA - I can find
out the exact ruling if you wish.

BK's EULA is similarly enforceable.

The horse is dead - you can stop beating it now.

>
>> On Thu, 28 Oct 2004 16:22:25 -0700
>> "David Schwartz" <davids@webmaster.com> wrote:
>
>> > 	I just downloaded bitkeeper, and I didn't have to consent
>> > to any license.
>> > So you can legally acquire BitKeeper without accepting the
>> > license terms. So
>> > this whole argument is irrelevent
>
>> You can acquire it, but the first time you ever try to use
>> it you will be asked to page through the text of the license
>> and agree to it.
>
> 	That does not matter. Once you lawfully acquire it, you automatically
> have
> the (transferrable!) right to use it. Really. Otherwise, as I said, I
> could
> put my copyrighted poem up on billboards (along with a license if you
> want)
> and then sue everyone who read it.
>
> 	In the United States, the license, to be valid, must be a condition of
> obtaining lawful possession of the copyrighted work. If you disagree,
> please
> feel free to cite cases where this argument was raised and rejected.
>
> 	DS
>
>
>
> -
> 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: BK kernel workflow

[Xavier Bestel]

Le ven 29/10/2004 à 16:31, Scott Lockwood a écrit :
> US Courts have recently ruled that EULA's are legal. So when you buy a
> copy of MS Office at the store, the EULA it contains is still binding. I
> work at the law firm that represents the MPAA and the RIAA - I can find
> out the exact ruling if you wish.
> 
> BK's EULA is similarly enforceable.

Come and enforce that in the EU.

> The horse is dead - you can stop beating it now.

It's still moving, I saw it !

	Xav

The requested ruling (Was: BK kernel workflow)

[Scott Lockwood]

Ha! I found it faster on Slashdot than from our Librarian. Please note
that I am not a lawyer (I'm the IS guy/server monkey), but am in arms
reach of one at just about all times. I can ask someone to read this, and
see if they agree with the below:

Here's a link to the ruling in question. To quote Slashdot on it, "Some
highlights from the ruling are: A clickthrough EULA isn't unconscionable
(and thus enforceable); Fair Use rights can be waived in a EULA; First
Sale rights (!) can be waived in a EULA; The DMCA's interoperability
provisions are not a defense."

http://www.freedom-to-tinker.com/doc/2004/bnetd_30sep.pdf

BK's EULA is similarly enforceable.

The horse is dead - you can stop beating it now.

> US Courts have recently ruled that EULA's are legal. So when you buy a
> copy of MS Office at the store, the EULA it contains is still binding. I
> work at the law firm that represents the MPAA and the RIAA - I can find
> out the exact ruling if you wish.

RE: The requested ruling (Was: BK kernel workflow)

[David Schwartz]

> Ha! I found it faster on Slashdot than from our Librarian. Please note
> that I am not a lawyer (I'm the IS guy/server monkey), but am in arms
> reach of one at just about all times. I can ask someone to read this, and
> see if they agree with the below:
>
> Here's a link to the ruling in question. To quote Slashdot on it, "Some
> highlights from the ruling are: A clickthrough EULA isn't unconscionable
> (and thus enforceable); Fair Use rights can be waived in a EULA; First
> Sale rights (!) can be waived in a EULA; The DMCA's interoperability
> provisions are not a defense."
>
> http://www.freedom-to-tinker.com/doc/2004/bnetd_30sep.pdf
>
> BK's EULA is similarly enforceable.
>
> The horse is dead - you can stop beating it now.

	Yes, this case does seem to be dead on point. Amazing, at least in the
Eastern District of Missouri, sellers of copyrighted works can require you
to waive all of your fair use and first sale rights as a condition of the
sale. (I'm exaggerating very slightly, because some issues specific to
computer software were involved. But it's hard to imagine it would make much
difference.)

	This case involved a 'clik to install' agreement that required you to waive
your rights to reverse engineer, among other things. The court was not
impressed with DMCA interoperability defenses either, on grounds that I
can't comprehend.

	The really weird thing, IMO, is how the courts were willing to join state
contract law with Federal copyright law in very strange ways. For example,
copyright law allows you to reverse engineer, and DMCA enforces copyright,
so how can you have a DMCA case against reverse engineering because you gave
up your reverse engineering rights by contract? There exists no copyright
protection against reverse engineering.

	I make my living selling software, I should rejoice. Yay.

	DS

Re: BK kernel workflow

[Adrian Bunk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Oct 28, 2004 at 08:10:04AM -0700, Larry McVoy wrote:
> On Thu, Oct 28, 2004 at 04:06:20PM +0200, Xavier Bestel wrote:
> > Le jeu 28/10/2004 ?? 15:53, Larry McVoy a ??crit :
> > 
> > > The reason it is worded that way is so that we avoid the situation where
> > > one guy is doing the work on $SCM and the other guy is sitting there 
> > > running BK commands in order to reverse engineer BK.
> > 
> > I don't think you can stop that from happening, legally.
> 
> Since you haven't paid for the product, copyright law applies and
> that's quite different than contract law.  You get a certain set
> of rights, which vary worldwide, when you buy something.  Copyright
> is far more restrictive.

US copyright law isn't the only one in the world...

> "Fair use" != "reverse engineering" in any venue so far as I know.

German copyright law explicitely allows every person allowed to use a 
program to observe and test this program for getting the ideas behind 
the program as long as you can do this through normal usage of the 
program.

If you aren't building a similar program but require disassembling for 
interoperability, this is explicitely allowded.

According to German copyright law, any licence clauses that violate 
these rules are void [1].

Note that German copyright lay doesn't differentiate whether you paid 
or not - it only requires that you allowed to use the program.

> As always, IANAL, so contact yours for clarification.

These are paragraphs 69d(3), 69e and 69g(2) of German copyright law - 
IANAL, but the text of the law is pretty unambiguous.

cu
Adrian

[1] the clauses are void, not the licence itself

- -- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBgU+zmfzqmE8StAARAv9PAJ9klSxSbl8zi9kKv2MI96oq0r0pggCdHTDv
tMik8nm1bVB5seygLyQfmgc=
=kTsy
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Larry McVoy]

> Note that German copyright lay doesn't differentiate whether you paid 
> or not - it only requires that you allowed to use the program.

Sure, but you aren't allowed to use it if you are going to do this.
That's pretty unambiguous as well and we think we can make it stick,
or at least that's what the lawyers have told me.

It's most unfortunate that people take the position "hey, I can rip off
your stuff, here's the law that says so" when it is something we gave 
them to use for free.  All that means is that we stopped improving the
free version and put all the effort into the commercial version because
we just can't afford the risk exposure.

All of the "we can do whatever we want" statements may well be true, I
don't really know and don't really care.  But the fact that people take
the attitude that it's OK to bite the hand that feeds you is doing nothing
but shooting yourself in the foot.  What are we supposed to do in the face
of "I can rip you off, here's the law"?  Give you more stuff to copy?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Adrian Bunk]

On Thu, Oct 28, 2004 at 02:35:34PM -0700, Larry McVoy wrote:
> > Note that German copyright lay doesn't differentiate whether you paid 
> > or not - it only requires that you allowed to use the program.
> 
> Sure, but you aren't allowed to use it if you are going to do this.
> That's pretty unambiguous as well and we think we can make it stick,
> or at least that's what the lawyers have told me.
>...

The German copyright law says the licence clauses are invalid - not the 
licence itself.

I'm not sure how a lawyer would circumvent the law...

> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: BK kernel workflow

[Larry McVoy]

On Sat, Oct 30, 2004 at 08:51:11AM +0200, Adrian Bunk wrote:
> On Thu, Oct 28, 2004 at 02:35:34PM -0700, Larry McVoy wrote:
> > > Note that German copyright lay doesn't differentiate whether you paid 
> > > or not - it only requires that you allowed to use the program.
> > 
> > Sure, but you aren't allowed to use it if you are going to do this.
> > That's pretty unambiguous as well and we think we can make it stick,
> > or at least that's what the lawyers have told me.
> >...
> 
> The German copyright law says the licence clauses are invalid - not the 
> licence itself.
> 
> I'm not sure how a lawyer would circumvent the law...

The flaw here is that you are presuming you have a legal right to use BK
in the first place.  You don't, you only get that right if we grant it
to you and if you can't agree with the terms you don't get BK.  It's 
pretty simple and the terms are pretty reasonable.

As someone pointed out to me in private mail, it is the nature of any
engineer to try and find a way to do something they are told can't be
done.

Further more, he told me that he thought a lot of this discussin is 
because people feel like the power of the Linux kernel was shifting
from Linus to me because of BK.  Is that true?  Do you guys really 
think that any of this crud gives me control over Linux?  Because
that's certainly not my goal, the whole point was to make sure that
Linus stayed in charge as long as he wanted.

If there are reasonable people out there who feel this way then let's
figure out some sort of public contract or something that makes it clear
that we have no designs on the Linux kernel.  That's just wacko but if
a lot of people think that then lets fix that.  By the way, with all
due respect, Andrea & Roman are not "reasonable" people in this context.
Let's find some reasonable people who are not BK users and make sure they
are comfortable with what is going on.  Alan Cox, Al Viro, who else?
I don't really care if it is non-BK users, BK users, or a combination,
I just care that there is some sanity in the discussion.

Is there any need for this or is this a non-issue?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Alan Cox]

On Sul, 2004-10-31 at 00:46, Larry McVoy wrote:
> a lot of people think that then lets fix that.  By the way, with all
> due respect, Andrea & Roman are not "reasonable" people in this context.
> Let's find some reasonable people who are not BK users and make sure they
> are comfortable with what is going on.  Alan Cox, Al Viro, who else?
> I don't really care if it is non-BK users, BK users, or a combination,
> I just care that there is some sanity in the discussion.
> 
> Is there any need for this or is this a non-issue?

Seems a total non issue to me. If you did utterly evil things then your
statements archived in email so far would be more than sufficient.

Alan

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 31, 2004 at 12:05:53AM +0100, Alan Cox wrote:
> On Sul, 2004-10-31 at 00:46, Larry McVoy wrote:
> > a lot of people think that then lets fix that.  By the way, with all
> > due respect, Andrea & Roman are not "reasonable" people in this context.
> > Let's find some reasonable people who are not BK users and make sure they
> > are comfortable with what is going on.  Alan Cox, Al Viro, who else?
> > I don't really care if it is non-BK users, BK users, or a combination,
> > I just care that there is some sanity in the discussion.
> > 
> > Is there any need for this or is this a non-issue?
> 
> Seems a total non issue to me. If you did utterly evil things then your
> statements archived in email so far would be more than sufficient.

Cool.  But I'd like to clarify something someone else said, for the record.

> > I think you could make a compelling argument that the linux
> > kernel history
> > metadata is *not* covered under the GPL, and hence can be
> > restricted by licensing.

> That's an interesting argument. I think you could argue that a BK
> repository is an aggregation of metadata and the kernel source, and
> therefore only the kernel source needs to be distributed. IANAL, this
> question has now gotten into territory in which I don't feel comfortable
> offering an opinion.

There are really three distinct chunks of information in BK:
    - the source code under management
    - the metadata created by users, i.e., checkin comments.  We also
      consider user names, dates, and timestamps to be created by users
      even though BK itself does that for you.
    - the metadata created by BK 

The license and ownership of kernel source code managed by BK has nothing
to do with BK nor the BK license.

There is a question as to whether the metadata created by the users
is GPLed.  It's not because it falls under the separate works part
of the GPL.  If that metadata were GPLed then your user name in an
inode is GPLed if you were putting a GPLed file into a filesystem.
That's a boundary you aren't going to be able to cross no matter how
hard you try (note: you can start arguing about this and I'll ignore 
you, we've been over this).

Just to make our position clear, consider this a formal declaration that
we make no claims of ownership of user created metadata, as defined above,
and impose no restrictions on its use.  I suspect that this declaration
isn't needed, you ought to have rights to your own name and checkin
comments, but let's make sure that there is no confusion about that.

There is the question of metadata created by BK.  That's also not GPLed
for the same reasons.  This metadata is more like the block pointers in
a file system.  While you may use BK, if you have a license, to dig out
your data and the user created metadata, you aren't entitled to expose the
internal BK metadata.  That falls under the reverse engineering clause,
non-compete clause, etc.  I realize you don't like this if you are trying
to create a competing product but that's the way things are.

Please respect that just as we are respecting your rights to your data.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Robert Love]

On Sat, 2004-10-30 at 16:46 -0700, Larry McVoy wrote:

> If there are reasonable people out there who feel this way then let's
> figure out some sort of public contract or something that makes it clear
> that we have no designs on the Linux kernel.  That's just wacko but if
> a lot of people think that then lets fix that.  By the way, with all
> due respect, Andrea & Roman are not "reasonable" people in this context.
> Let's find some reasonable people who are not BK users and make sure they
> are comfortable with what is going on.  Alan Cox, Al Viro, who else?
> I don't really care if it is non-BK users, BK users, or a combination,
> I just care that there is some sanity in the discussion.

I am a non-BK user[1].  And I see this as a total non-issue.

	Robert Love

[1] While I am no fan of the license, the real reason I don't use BK is
because I don't think it currently makes sense for developers who are
not also maintainers.  BK really shines when you have people above
(Linus, Andrew) and below (other developers) you.  E.g., it makes sense
for Greg K-H.  Not so much for me or, say, Ingo.  It is the push-pull
relationship where BK shines.  Your comment that you were looking at
improving workloads like Andrew's interests me.

Re: BK kernel workflow

[Adrian Bunk]

On Sat, Oct 30, 2004 at 04:46:19PM -0700, Larry McVoy wrote:
> On Sat, Oct 30, 2004 at 08:51:11AM +0200, Adrian Bunk wrote:
> > On Thu, Oct 28, 2004 at 02:35:34PM -0700, Larry McVoy wrote:
> > > > Note that German copyright lay doesn't differentiate whether you paid 
> > > > or not - it only requires that you allowed to use the program.
> > > 
> > > Sure, but you aren't allowed to use it if you are going to do this.
> > > That's pretty unambiguous as well and we think we can make it stick,
> > > or at least that's what the lawyers have told me.
> > >...
> > 
> > The German copyright law says the licence clauses are invalid - not the 
> > licence itself.
> > 
> > I'm not sure how a lawyer would circumvent the law...
> 
> The flaw here is that you are presuming you have a legal right to use BK
> in the first place.  You don't, you only get that right if we grant it
> to you and if you can't agree with the terms you don't get BK.  It's 
> pretty simple and the terms are pretty reasonable.

As already said:

At least according to German law, the licence is still valid if some of 
the licence clauses are void because they violate the law.

If I know that a clause in a treaty is void according to the law, I can 
sign the treaty knowing that the clause is void but the treaty is still 
valid. The reason behind this is that a company shouldn't have any 
advantages from clauses that aren't allowed according to the law.


> As someone pointed out to me in private mail, it is the nature of any
> engineer to try and find a way to do something they are told can't be
> done.
> 
> Further more, he told me that he thought a lot of this discussin is 
> because people feel like the power of the Linux kernel was shifting
> from Linus to me because of BK.  Is that true?  Do you guys really 
> think that any of this crud gives me control over Linux?  Because
> that's certainly not my goal, the whole point was to make sure that
> Linus stayed in charge as long as he wanted.
>...

To clarify things:
- I do not use BK and I do not plan to use it
- I do currently not plan any significant contribution to any
  SCM tool
- although I'd be more happy if Linus would use an open source SCM tool,
  I can live with the current status quo


It has nothing to do with the question whether I like or dislike BK and 
it's licencing - I simply completely dislike it if someone from the USA 
thinks laws everywhere in the world are similar to US law. It's more 
than a year ago that I first told you that there's no case law in 
continental Europe, and to be honest, I'm quite pissed off by your 
attitude of still asking for case law in e.g. Germany.

Please, do me a favor and inform yourself about the differences. [1]

cu
Adrian



[1] e.g the Wikipedia article "Civil law (legal system)" gives an
    overview over the differences of the different law systems [2]
[2] it was interesting, I didn't know before that different from the
    other 49 US states, Louisiana has a civil law system

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: BK kernel workflow

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry McVoy wrote:

| Since you haven't paid for the product, copyright law applies and
| that's quite different than contract law.  You get a certain set
| of rights, which vary worldwide, when you buy something.  Copyright
| is far more restrictive.
|
| "Fair use" != "reverse engineering" in any venue so far as I know.

In Spain, reverse engineering is allowed for interoperability.
- --
Ramón Rey Vicente <ramon.rey en hispalinux.es>
JID rreylinux@jabber.org - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgnuJw4Wp058o43cRAkGoAJ4rmFCXzNNklsC+ITWYn5GxFyTdgACgiPzH
eDRazB4r4gTrkcjWR3YwaIg=
=dCLQ
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Larry McVoy]

On Fri, Oct 29, 2004 at 07:19:05PM +0200, Ram?n Rey Vicente wrote:
> In Spain, reverse engineering is allowed for interoperability.

And in lots of other places.  Which has been mentioned in this and other
instances of this discussion for the last 5 years.  And the response is
that BK already gives you documented ways to interoperate, extensively
documented, in fact.  You can get data and/or metadata into and out of
BK from the command line.  You could create your own network protocol,
client, and server using the documented interfaces that BK has.  You
could create your own CVS2BK tool, your own BK2CVS tool, etc., all
using documented interfaces.

The point of the interoperability hole is for commercial products
which try and lock up your data.  We don't do that, in fact, we are
*dramatically* more open about getting data in and out, with all
the metadata, than any other commercial product.  Go try and get the
same information from Perforce, Clearcase, or even CVS or Subversion.
Good luck.

Given that BK isn't hiding anything, the "reverse engineering for
interoperability" does not apply.  Hello?  Anyone listening?  Didn't
think so.  Sigh.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Stephen Frost]

* Larry McVoy (lm@bitmover.com) wrote:
> On Fri, Oct 29, 2004 at 07:19:05PM +0200, Ram?n Rey Vicente wrote:
> > In Spain, reverse engineering is allowed for interoperability.
[...]
> Given that BK isn't hiding anything, the "reverse engineering for
> interoperability" does not apply.  Hello?  Anyone listening?  Didn't
> think so.  Sigh.

(Not actually following the conversation, but this caught my eye)

If I had a license to run BK and was using it and later that license was
revoked such that I could no longer run BK, is there sufficient
documentation provided that I could write code to read my
data/metadata/etc off of the disk w/o using BK?

	Stephen

Re: BK kernel workflow

[Larry McVoy]

On Fri, Oct 29, 2004 at 02:06:25PM -0400, Stephen Frost wrote:
> * Larry McVoy (lm@bitmover.com) wrote:
> > On Fri, Oct 29, 2004 at 07:19:05PM +0200, Ram?n Rey Vicente wrote:
> > > In Spain, reverse engineering is allowed for interoperability.
> [...]
> > Given that BK isn't hiding anything, the "reverse engineering for
> > interoperability" does not apply.  Hello?  Anyone listening?  Didn't
> > think so.  Sigh.
> 
> (Not actually following the conversation, but this caught my eye)
> 
> If I had a license to run BK and was using it and later that license was
> revoked such that I could no longer run BK, is there sufficient
> documentation provided that I could write code to read my
> data/metadata/etc off of the disk w/o using BK?

We can't reach out and revoke your license arbitrarily.  Even if we put
into the license that we could do that, it's not enforceable.  That's more
or less blackmail "gimme all your money or I'll revoke your license".

While the BK haters love to spread FUD about us having that ability
that's just nonsense, it would never stand up in any court.

So it's a moot point.  We aren't going to revoke your license, you get
to revoke your license by violating the terms.

As for the on disk format, sure, you can dig it out.  It's loosely
derived from the SCCS format, we used to be compatible with SCCS but we
dropped that because it was too restrictive.  But you could go get CSSC
and tweak it enough to get your data out.

If you are worried about this, the easiest way to make sure that you are
safe is park a clone of your tree on bkbits.net.  There is no license
required to get at the data over the web and all the data and metadata
is right there.  If you are worried that we'd drop bkbits.net you could
hire a neutral third party, get them to run their own BK server, park
your data there, and you have the same thing.

We don't do lockins.  Period.  You can get out of BK if that's what you
want to do.  This is a good time to note that we have a >99% renewal 
rate w/ our commercial customers.  But the ones that wanted to get
out, I think there have been 2 or 3, got all their data out and all 
their history out.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry McVoy wrote:

| Given that BK isn't hiding anything, the "reverse engineering for
| interoperability" does not apply.  Hello?  Anyone listening?  Didn't
| think so.  Sigh.

Ok, you are right.

Other issue in my country laws is: "in a contract, improper clauses have
no validity at all". In other words, you cannot forbid me contributing
to other SCM.
- --
Ramón Rey Vicente <ramon.rey en hispalinux.es>
JID rreylinux@jabber.org - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgocGw4Wp058o43cRAlSTAKCjAuUlbE7kACmMgKP1vAZvMRxlhQCfXC1B
UASb6oajbHgb+mKdSuQi1OE=
=Z6Ey
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Larry McVoy]

On Fri, Oct 29, 2004 at 08:08:07PM +0200, Ram?n Rey Vicente wrote:
> Other issue in my country laws is: "in a contract, improper clauses have
> no validity at all". In other words, you cannot forbid me contributing
> to other SCM.

And the legal case law which shows that is?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Scott Lockwood]

In what way is that improper? Just because you think so, or do you have
something you can cite in the spanish legal system that forbids this sort
of exchange of rights for a licsense?

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Larry McVoy wrote:
>
> | Given that BK isn't hiding anything, the "reverse engineering for
> | interoperability" does not apply.  Hello?  Anyone listening?  Didn't
> | think so.  Sigh.
>
> Ok, you are right.
>
> Other issue in my country laws is: "in a contract, improper clauses have
> no validity at all". In other words, you cannot forbid me contributing
> to other SCM.
> - --
> Ramón Rey Vicente <ramon.rey en hispalinux.es>
> JID rreylinux@jabber.org - GPG public key id 0x9F28E377
> GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBgocGw4Wp058o43cRAlSTAKCjAuUlbE7kACmMgKP1vAZvMRxlhQCfXC1B
> UASb6oajbHgb+mKdSuQi1OE=
> =Z6Ey
> -----END PGP SIGNATURE-----
> -
> 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: BK kernel workflow

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Lockwood wrote:

| In what way is that improper? Just because you think so, or do you have
| something you can cite in the spanish legal system that forbids this sort
| of exchange of rights for a licsense?

Improper in the way of misusing the legal system.  For example, many of
the clauses of the EULA of Microsoft products are not legal following
the civil laws

«art 1256
La validez y el cumplimiento de los contratos no pueden dejarse al
arbitrio de uno de los contratantes.»

The validity and the fulfillment of contracts cannot be left to the will
of one of the contractors

«Art. 1275
Los contratos sin causa, o con causa ilícita, no producen efecto alguno.
Es ilícita la causa cuando se opone a las leyes o a la moral. »

The contracts without cause, or with illicit cause, do not produce
effect some.The cause is illicit when it is against to the laws or the moral
- --
Ramón Rey Vicente <ramon.rey en hispalinux.es>
JID rreylinux@jabber.org - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgpI8w4Wp058o43cRAhtRAJ9E88cxLUnOul/5WT9k5qWPJ1d7AwCgk4rP
PQfdsdnSouUZ6nISeS0IZWc=
=OeZx
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Scott Lockwood]

None of which contradicts "exchange of rights for a licsense" at all. The
agreement is not one sided - if you don't agree to the restrictions, you
have no liscense to use the software, period. Imposition of new terms that
one party did not agree to AFTER a contract was executed is what that law
is likely directed at - and that's the same just about anywhere in the
world.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Scott Lockwood wrote:
>
> | In what way is that improper? Just because you think so, or do you have
> | something you can cite in the spanish legal system that forbids this
> sort
> | of exchange of rights for a licsense?
>
> Improper in the way of misusing the legal system.  For example, many of
> the clauses of the EULA of Microsoft products are not legal following
> the civil laws
>
> «art 1256
> La validez y el cumplimiento de los contratos no pueden dejarse al
> arbitrio de uno de los contratantes.»
>
> The validity and the fulfillment of contracts cannot be left to the will
> of one of the contractors
>
> «Art. 1275
> Los contratos sin causa, o con causa ilícita, no producen efecto alguno.
> Es ilícita la causa cuando se opone a las leyes o a la moral. »
>
> The contracts without cause, or with illicit cause, do not produce
> effect some.The cause is illicit when it is against to the laws or the
> moral
> - --
> Ramón Rey Vicente <ramon.rey en hispalinux.es>
> JID rreylinux@jabber.org - GPG public key id 0x9F28E377
> GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBgpI8w4Wp058o43cRAhtRAJ9E88cxLUnOul/5WT9k5qWPJ1d7AwCgk4rP
> PQfdsdnSouUZ6nISeS0IZWc=
> =OeZx
> -----END PGP SIGNATURE-----
>

Re: BK kernel workflow

[Kyle Moffett]

AFAIK, much of this has been rather confused talk about the status of 
"IP"
(Intellectual Property) in the US. I'm only familiar with US laws, so 
I'll
only talk to them, but this may apply for other countries too. IANAL, 
only
an informed student.  The only part of this discussion that I care about
is the "no contribute" clause in the BK license, that states that one 
may
not work on other SCM systems given certain relationships to BK users.

To start with, I'm going to ignore the DMCA for now, because it 
conflicts
hundreds of pages of preexisting laws and court cases, and is currently
hotly contended all over the place.

In the US there are three laws that protect the rights of authors of 
"stuff".
There is Trademark Law, which restricts usage of a brand name or image,
Patent Law, which restricts usage of a method or procedure, and
Copyright Law, which restricts distribution.  Trademark and Patent Law
do not apply to the license, because no-one here is attempting to 
deprive
Larry of his brand name(s) and he has (to my knowledge) filed no patent
on his BitKeeper algorithms.

Therefore the only remaining protection which he may enjoy is Copyright
protection, which restricts copying of some "product" without a license
from the author (Larry).  Copyright Law states that no-one may make and
distribute copies of BitKeeper without a license from Larry.  There may 
be
contractual obligations or monetary payment required to _obtain_ a copy
of said works, but once one has gotten said copy, they _own_ that copy.
They may *NOT* reproduce and/or distribute it without a license, but 
that
copy is theirs to do whatever they want with (Following any contract
agreed to _before_ obtaining the "product").

If someone else in the company I work for obtains BK, or if the company
itself obtains and uses BK, I am _not_ bound by their decisions, because
I am a separate entity, and I did not agree to said terms (Assuming that
this does not conflict with an employment contract).  Therefore you 
can't
assume association through business.

If I download the software and store it on my HDD, I _never_ have to
agree to the license before I download it, therefore I am under no 
license
concerning its use because any license is post-purchase, and therefore
not binding.

To my knowledge, there has not been a single significant instance of
a EULA made _after_ the point-of-sale being found binding by a court
of law.  There _have_ been many cases where Copyright law forbids
some action of a user also forbidden in an EULA, but in no other case
have they been upheld.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: BK kernel workflow

[Scott Lockwood]

You wrote:

To my knowledge, there has not been a single significant instance of
a EULA made _after_ the point-of-sale being found binding by a court
of law.  There _have_ been many cases where Copyright law forbids
some action of a user also forbidden in an EULA, but in no other case
have they been upheld.

Now read:

http://www.freedom-to-tinker.com/doc/2004/bnetd_30sep.pdf

Re: BK kernel workflow

[Larry McVoy]

Indeed.  Kyle's comments were clearly without basis in fact.  Saying
that you aren't bound by the terms of the license because you didn't
download the code, your co-worker did, is no different than saying "hey,
look at this!  A copy of the Linux kernel!  Now how did that get here?
Well, I didn't put it here so I think I'll ignore the terms of the GPL."
Best of luck on that logic.

> > To my knowledge, there has not been a single significant instance of
> > a EULA made _after_ the point-of-sale being found binding by a court
> > of law.  There _have_ been many cases where Copyright law forbids
> > some action of a user also forbidden in an EULA, but in no other case
> > have they been upheld.
> 
> Now read:
> 
> http://www.freedom-to-tinker.com/doc/2004/bnetd_30sep.pdf

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

RE: BK kernel workflow

[David Schwartz]

> Indeed.  Kyle's comments were clearly without basis in fact.  Saying
> that you aren't bound by the terms of the license because you didn't
> download the code, your co-worker did, is no different than saying "hey,
> look at this!  A copy of the Linux kernel!  Now how did that get here?
> Well, I didn't put it here so I think I'll ignore the terms of the GPL."
> Best of luck on that logic.

	No, these are in no way comparable. The big difference between copyright
and contract is that I don't have to agree to give you copyright rights.
Your analogy blurs this *major* distinction. The problem with having a
co-worker agree to the license is it's not clear how you would get the right
(under copyright) to use the software.

	The big questions, IMO, are:

	1) Will courts really uphold click-wrap agreements in contradiction to
first sale, and

	2) Will courts really uphold the DMCA in defense of rights obtained by
contract, not copyright.

	My opinion is this:

	Yes on the first question. They will. Largely because they 'first sale'
only seems to apply when you own something, and if software is leased or
licensed to you, you don't own anything. I think this is a bad
interpretation of copyright law, but I think courts will run with this. This
effectively guts all rights to fair use or first sale for at least computer
software. If someone can say "you must yield your fair use rights to obtain
any right to use this software", then there effectively is no right to fair
use at all. (One wonders if you can do the same thing with books and CDs.)

	No on the second question. The current case that suggests this is, I hope,
an aberration. The DMCA is a very powerful right that should be subject to
the same restrictions other Federal copyright rights are subject to. It
should not be expanded to defend rights obtained by contract and not
recognized under contract law.

	I want to take one minute to thank Larry for the efforts he has put forward
to help the Linux kernel project and, specifically, for the effort has has
put to make Linus' life easier and more productive. We all benefit from
this. Yes, Larry benefits too, but many kernel developers also benefit from
the work they do. It would be a strange twist if we expected people to work
on GPL'd projects to their personal detriment.

	DS

Re: BK kernel workflow

[Kyle Moffett]

On Oct 30, 2004, at 19:35, Larry McVoy wrote:
> Indeed.  Kyle's comments were clearly without basis in fact.  Saying
> that you aren't bound by the terms of the license because you didn't
> download the code, your co-worker did, is no different than saying 
> "hey,
> look at this!  A copy of the Linux kernel!  Now how did that get here?
> Well, I didn't put it here so I think I'll ignore the terms of the 
> GPL."

The critical difference with the GPL is that it doesn't _add_ 
restrictions.
Without the GPL you may use the code however you want as long as
you don't distribute.  With the GPL, you may use the code however you
want internally, and you can distribute provided you follow some rules.
The GPL is your only license to distribute at all, so if you want to do 
so
you must follow its _distribution_ restrictions.

Besides, I never said anything about one user taking a copy another
user downloaded.  Here is what I said:

> If someone else in the company I work for obtains BK, or if the company
> itself obtains and uses BK, I am _not_ bound by their decisions, 
> because
> I am a separate entity, and I did not agree to said terms (Assuming 
> that
> this does not conflict with an employment contract).  Therefore you 
> can't
> assume association through business.

This means that if my coworker downloads and uses the software I am in
no way bound by _his_ agreeing to the license.  If I illegally obtain a
copy from him (IE: stealing from his HDD) then that's another issue.  
But
he can agree to _no_ license that limits my individual rights (Unless I
signed some draconian employment contract that lets my boss do that).

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: BK kernel workflow

[Larry McVoy]

On Sat, Oct 30, 2004 at 10:37:23PM -0400, Kyle Moffett wrote:
> On Oct 30, 2004, at 19:35, Larry McVoy wrote:
> >Indeed.  Kyle's comments were clearly without basis in fact.  Saying
> >that you aren't bound by the terms of the license because you didn't
> >download the code, your co-worker did, is no different than saying 
> >"hey,
> >look at this!  A copy of the Linux kernel!  Now how did that get here?
> >Well, I didn't put it here so I think I'll ignore the terms of the 
> >GPL."
> 
> The critical difference with the GPL is that it doesn't _add_
> restrictions.  Without the GPL you may use the code however you want
> as long as you don't distribute.  

Even that's not true.  You have to accept the terms of the GPL to get
the code in the first place.  It's not "no rules as long as you don't
distribute", it's the "the GPL rules" or you don't get the code in the
first place.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Kyle Moffett]

On Oct 30, 2004, at 23:34, Larry McVoy wrote:
> Even that's not true.  You have to accept the terms of the GPL to get
> the code in the first place.  It's not "no rules as long as you don't
> distribute", it's the "the GPL rules" or you don't get the code in the
> first place.

This statement is *completely* incorrect.  If I want to download GPL
software I can do so _without_ agreeing to the GPL.  I can download
it, burn a hundred private copies onto CD and smash them all with
a hammer without agreeing to the GPL(1).  However, whoever gives
me the copy _must_ agree to the GPL, or they can't give copies out
to others.  The only time I must agree to the GPL is if I want to take
one of the hundred CDs that I'm going to smash and give it to
somebody else (AKA distribution).

I can do the same thing with Starcraft.  I can burn myself a bunch of
copies and put them in a box on my desk to look at because they're
pretty, or I can smash them all to pieces to relieve anger, or I can
make a mobile out of the duplicate CDs, as long as I don't give a
_single_ copy to anybody else.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 31, 2004 at 12:01:56AM -0400, Kyle Moffett wrote:
> On Oct 30, 2004, at 23:34, Larry McVoy wrote:
> >Even that's not true.  You have to accept the terms of the GPL to get
> >the code in the first place.  It's not "no rules as long as you don't
> >distribute", it's the "the GPL rules" or you don't get the code in the
> >first place.
> 
> This statement is *completely* incorrect.  If I want to download GPL
> software I can do so _without_ agreeing to the GPL.  

You're right but you are splitting hairs.  So what?  Why is this point
at all interesting?  Just to win the argument about this point?  OK,
you win.  Feel better?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Kyle Moffett]

On Oct 30, 2004, at 16:42, Scott Lockwood wrote:
> Now read:
>
> http://www.freedom-to-tinker.com/doc/2004/bnetd_30sep.pdf

I stand corrected.  I am familiar with the bnetd case but I was not
aware that it had been decided.  However, I _do_ have a copy of
bnetd on my HDD that I do not distribute.  I use it to host a server
for my LAN parties on the basis that I can do whatever I want
(excepting distribution) with the stuff that I own (IE: the bits on the
CD.  If Vivendi feels like suing me because I have a copy of stuff
they never had copyright on in the first place which I may or may
not be using, then they can go ahead and call my lawyer.  The
bnetd staff may have been distributing stuff they aren't allowed
to due to license infringement, but I have a right to circumvent
my _own_ damn computer in any way I please.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: BK kernel workflow

[Larry McVoy]

On Fri, Oct 29, 2004 at 08:55:57PM +0200, Ram?n Rey Vicente wrote:
> Scott Lockwood wrote:
> | In what way is that improper? Just because you think so, or do you have
> | something you can cite in the spanish legal system that forbids this sort
> | of exchange of rights for a licsense?
> 
> Improper in the way of misusing the legal system.  

This is not getting us anywhere.  You're not citing case law, you're
citing vague statements that don't apply here.  And even if they do
apply, the law is a moving target, new case law changes the rules all
the time.  Who's to say that we don't have a lawsuit in Spain and 
and get new case law put in place that says you don't have such and
such a right unless you pay for the product?  Who's to say someone 
else doesn't do that?  It's a moving target.  

It's worth thinking this through a little.  One view of law is that
it is the process of writing down what society thinks is reasonable.

A good example is the interoperability thing, lots of places have said
"if you lock up my data then I have the right to dig it out regardless of
your license" or words to that effect.  That's reasonable.  

On the other hand, if you have a program that does not lock up the data,
does not impede your ability to get your work done, is it reasonable for
you to go digging around in that product for the purposes of creating
a clone?  Maybe, if the license doesn't prohibit that.  Is it reasonable
for a license to prohibit that?  I think so and so does BitMover's
legal counsel and so does outside counsel who are experts in contract
and copyright law.  Are we right?  Dunno.  Maybe we go to court and
find out.  Maybe we go to court and make new case law.

The bottom line is that we are trying to be reasonable, we are trying
to provide a service and protect our investment at the same time, and
we are secure in the knowledge that we could make a very strong case
that we are good guys, doing a good thing for you, and we're reasonable.
What that means is that if it comes down to a legal battle, even a legal
battle where the current law comes down on your side, we may create new
case law which says "well, yeah, but you didn't pay for it and when we
talked about all that stuff you referenced we really meant in the context
of a paid for product".  It's a matter of how things are interpreted
and things get reinterpreted all the time in situations such as this.

The side that will win will be the side which is both reasonable and
has enough money to present that case.  We think that's us.

How reasonable are you going to look when the only reason you have
for doing what you are doing is to steal our technology?  Remember,
you are doing this to a program that was given to you for free under
the agreement that you would not do this.  Whether the law currently
distinguishes between paying or free, do you really think you can go
before a jury and win a case where you are violating the terms of a
license for a product for which you paid nothing and for the sole purpose
of creating a competing product?  If you do, go for it.  All I can say
is I wouldn't do that if I were you.  It doesn't look reasonable to me
and I'll bet you long odds that it won't look reasonable to a jury.

I'm quite willing to go to court and test this out, by the way, we've
set aside money for legal fees in case we need to do this.  It would be
nice to have some case law which clarified this one way or the other.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Stephen Frost]

* Larry McVoy (lm@bitmover.com) wrote:
> This is not getting us anywhere.  You're not citing case law, you're
> citing vague statements that don't apply here.  And even if they do
> apply, the law is a moving target, new case law changes the rules all
> the time.  Who's to say that we don't have a lawsuit in Spain and 
> and get new case law put in place that says you don't have such and
> such a right unless you pay for the product?  Who's to say someone 
> else doesn't do that?  It's a moving target.  

Just to put it out there- there are places in the world where the legal
system isn't based on case law.  Don't know if Spain is that way or not.

> On the other hand, if you have a program that does not lock up the data,
> does not impede your ability to get your work done, is it reasonable for
> you to go digging around in that product for the purposes of creating
> a clone?  Maybe, if the license doesn't prohibit that.  Is it reasonable
> for a license to prohibit that?  I think so and so does BitMover's
> legal counsel and so does outside counsel who are experts in contract
> and copyright law.  Are we right?  Dunno.  Maybe we go to court and
> find out.  Maybe we go to court and make new case law.

An interesting parallel are 'no-compete' clauses which employers use to
try and keep employees from being able to move from one company to a
competeing one.  These clauses are actually not enforcable in some
jurisdictions because the lawmakers there felt it was unreasonable.
This, really, is the light under which I'd think the BK license would be
seen.  Of course, IANAL, nor do I actually use (or have ever used) BK 
anyway.

> The side that will win will be the side which is both reasonable and
> has enough money to present that case.  We think that's us.

That's an unfortunate reality (the money bit).

[...]
> is I wouldn't do that if I were you.  It doesn't look reasonable to me
> and I'll bet you long odds that it won't look reasonable to a jury.

It's unlikely that a jury would be involved in such a case since it's
unlikely the facts themselves would be in dispute.

	Stephen

Re: BK kernel workflow

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Frost wrote:
| * Larry McVoy (lm@bitmover.com) wrote:
|
|>This is not getting us anywhere.  You're not citing case law, you're
|>citing vague statements that don't apply here.  And even if they do
|>apply, the law is a moving target, new case law changes the rules all
|>the time.  Who's to say that we don't have a lawsuit in Spain and
|>and get new case law put in place that says you don't have such and
|>such a right unless you pay for the product?  Who's to say someone
|>else doesn't do that?  It's a moving target.
|
|
| Just to put it out there- there are places in the world where the legal
| system isn't based on case law.  Don't know if Spain is that way or not.

Is not case law based. And the jury is only used in some kind of crimes.
- --
Ramón Rey Vicente <ramon.rey en hispalinux.es>
JID rreylinux@jabber.org - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgtSSw4Wp058o43cRApcBAJ9QPuB0ImazZvYY4QvwsmDpRPCBBACgzClN
jJK6csMdRyPoJqpSKoo4Knc=
=X2LP
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Adrian Bunk]

On Fri, Oct 29, 2004 at 12:39:24PM -0700, Larry McVoy wrote:
> On Fri, Oct 29, 2004 at 08:55:57PM +0200, Ram?n Rey Vicente wrote:
> > Scott Lockwood wrote:
> > | In what way is that improper? Just because you think so, or do you have
> > | something you can cite in the spanish legal system that forbids this sort
> > | of exchange of rights for a licsense?
> > 
> > Improper in the way of misusing the legal system.  
> 
> This is not getting us anywhere.  You're not citing case law, you're
> citing vague statements that don't apply here.  And even if they do
> apply, the law is a moving target, new case law changes the rules all
> the time.  Who's to say that we don't have a lawsuit in Spain and 
> and get new case law put in place that says you don't have such and
> such a right unless you pay for the product?  Who's to say someone 
> else doesn't do that?  It's a moving target.  
>...


Case law as you know it is not present in continental Europe, it's only 
present in some countries overseas.

In continental Europe, we have laws that cover every detail [1].
Therefore, in continental Europe, we don't cite some court cases ruled 
two centuries ago - we cite the paragraphs of the corresponding laws.

If the copyright law (like the German copyright law) says something, the 
only way to change it is a change of the law [2].


Larry, if you don't believe me, please ask any lawyer who roughly knows 
both your and our law systems about this.


> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

cu
Adrian

[1] e.g. in Germany our "Buergerliches Gesetzbuch" (our main book of 
    civil law) contains four paragraphs covering swarms of bees - what 
    happens if two swarms of different owners unite, you are allowed to 
    enter foreign estates to capture your swarm of bees etc. - it's all 
    explicitely covered by the law
[2] the exception is that our highest court may say a law or a
    paragraph of a law is void because it violates our constitution

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: BK kernel workflow

[Larry McVoy]

From: Roman Zippel (zippel@linux-m68k.org)
> What someone does in the privacy of his home is outside the scope of the 
> GPL, this means the kernel repository is the private toy of Linus and he 
> leaves the decision who may play with him to Larry.

Anyone who thinks this is incorrect.  Yes, I have a lot of influence
on the license under which BK is shipped, I own more than 50% of the
stock in BitMover.  On the other hand, I have a board of directors, we
call board meetings for any serious decision and I have never overridden
the board.  Not once.  And it is extremely unlikely that I ever will, the
whole point of the board (at least in our company) is to have a sounding
board where we make sure we aren't doing something stupid.  There are
calmer heads than mine prevailing and there isn't any way that Roman &
Co are going to piss me off enough that we will do something stupid.
There is zero chance of that.  We've set up process to make sure that
doesn't happen.

> This is also means that Linux history recorded in bk is not part of the 
> public record. 

It is indeed part of the public record, Linus has it and so do about 
10,000 other people.  Let's look at that, shall we?  Suppose I lost 
what little mind I have left and said, against the advice our board,
I'm sick of whiners like Roman, let's shut them down and revoke the 
BK license.  Never mind the fact that I can't do that, any court in
the world would spank us hard for trying to do it, let's just suppose.

So there you are with a pile of bits on disk.  Are you really suggesting,
Roman, that the collective intelligence of the free software world
is so pathetic that they can't extract the information they want from
those bits?  Remember, you already have the nightly BK2CVS snapshots
on master.kernel.org and we can't retract those even if we tried.
You have that and the bits on disk and your brain.  And you can't get
what you want?  How lame is that?  Are you really saying, in public,
that you can't handle that?  I know you are smarter than that, I've
read your code.

> This is an unfortunate fact and not a complaint BTW, but 
> Larry has not much use for facts anyway, when I try to summarize the facts 
> around the publicly available information as best as I can, Larry doesn't 
> even try to prove me wrong and instead continues to attack me personally. 
> I don't really care about the latter, but that he gets the support to do 
> so is the personally very disappointing part. :-(

Roman, I'm not attacking you.  I think your view on things leaves
something to be desired but I think that if BK wasn't in the picture
we would agree on 90% of the problems we faced together.  If you think
I'm attacking you then you are not listening.  I've been trying to tell
you that we are trying to help and you keep not listening.  Whatever.
But suggesting that I'm attacking you is just nonsense.  I don't care
about you enough to bother attacking you, that's one thing, and I
abhor the concept of attacking a person regardless of their beliefs,
that's the other thing.  If someone attacked you, Roman, as a person,
I'd defend you.  That's an awful thing to do and it is unacceptable.

On the other hand, I am attacking your position on this one issue.
I think you don't understand how hard it has been to build the technology
to help you and I think you have no idea what it takes to create a
business model which supports that effort.  That's an attack, I admit
it, on your thoughts on this issue.  I respect you as a person and as
a contributor to the Linux kernel but I do not agree with your views on
this one issue.  Anyone who has been to graduate school or has learned
this lesson elsewhere knows the difference between an attack on what
you said and an attack on you as a person.  There's a big difference.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Al Viro]

On Fri, Oct 29, 2004 at 08:55:57PM +0200, Ramón Rey Vicente wrote:
> The contracts without cause, or with illicit cause, do not produce
> effect some.The cause is illicit when it is against to the laws or the moral

And moral is defined by...?

Re: BK kernel workflow

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Lockwood wrote:

| In what way is that improper? Just because you think so, or do you have
| something you can cite in the spanish legal system that forbids this sort
| of exchange of rights for a licsense?

I forget this. In my country at least, you cannot make a contract
against the rights of people. The rights are not exchangable. I'm free,
and I cannot exchange "some piece" of my freedom in a contract.
- --
Ramón Rey Vicente <ramon.rey en hispalinux.es>
JID rreylinux@jabber.org - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgpZdw4Wp058o43cRAkdYAJ43cTLqZDuUQ6XOOrFBusBh2k4mPgCghoZR
9jl9x4RNdkn8NCx2/vrAq0k=
=EJW+
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Ramón Rey Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Lockwood wrote:

|>I forget this. In my country at least, you cannot make a contract
|>against the rights of people. The rights are not exchangable. I'm free,
|>and I cannot exchange "some piece" of my freedom in a contract.
|
|
| Use of commercial software is not a right. It's a privilage granted by a
| liscense. You do not have a 'right' to Windows, or Linux, or $foo.

Of course, but you have the right of freedom, and the freedom of
contributing to other SCM...

The license of BK is like MacDonalds made me sign a contract forbiding
me to eat the Burger King chips.
- --
Ramón Rey Vicente <ramon.rey en hispalinux.es>
JID rreylinux@jabber.org - GPG public key id 0x9F28E377
GPG Fingerprint 0BC2 8014 2445 51E8 DE87  C888 C385 A9D3 9F28 E377
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgplzw4Wp058o43cRAhRiAKCrg8WF6nWsF/V2B04ISCo8cDOuZwCgn8qZ
Lc4iYzOdru0zaNjFhzn6U+4=
=pzf7
-----END PGP SIGNATURE-----

Re: BK kernel workflow

[Tim Hockin]

On Fri, Oct 29, 2004 at 09:26:44PM +0200, Ramón Rey Vicente wrote:
> | Use of commercial software is not a right. It's a privilage granted by a
> | liscense. You do not have a 'right' to Windows, or Linux, or $foo.
> 
> Of course, but you have the right of freedom, and the freedom of
> contributing to other SCM...
> 
> The license of BK is like MacDonalds made me sign a contract forbiding
> me to eat the Burger King chips.

GOOD LORD you people a re fsking annoying.  You make these outrageous
claims that are based in nothing but your own deluded self-righteous
brain's skewed reality.

If you want a hamburger analogy, you're WAY off base.  The license of BK
is like McDonalds saying you can have all the free hamburgers you want,
but you can NOT have them if you are trying to recreate the secret sauce
recipe.

And again - IF YOU DON'T LIKE THE LICENSE, DON'T USE THE SOFTWARE.

And please, for the sake of GOD shut up.

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Fri, 29 Oct 2004, Larry McVoy wrote:

> And in lots of other places.  Which has been mentioned in this and other
> instances of this discussion for the last 5 years.  And the response is
> that BK already gives you documented ways to interoperate, extensively
> documented, in fact.  You can get data and/or metadata into and out of
> BK from the command line.  You could create your own network protocol,
> client, and server using the documented interfaces that BK has.  You
> could create your own CVS2BK tool, your own BK2CVS tool, etc., all
> using documented interfaces.

Wow, now I'm really interested, how this fits together with this mail: 
http://marc.theaimsgroup.com/?l=linux-kernel&m=109884946914484

What I'm asking for there is the _minimum_ amount of information to do 
exactly the above. Is there somewhere a provision like "unless you give 
this data to evil bk haters"?

To make this easier to understand for everyone, here is a simple example: 
a very simple network protocol would be to extend the current commit mails 
with the identifiers one can already find in bkcvs, so they can be put 
into the correct order.

The million Euro question is now: How can he decline me this information 
on the one hand (note: I didn't ask that he gives me this himself) and on 
the other hand how will he prevent me from getting to this information, if 
someone does exactly the above?
For the answer to this question stay tuned and don't switch the channel...

bye, Roman

Re: BK kernel workflow

[Larry McVoy]

On Fri, Oct 29, 2004 at 10:32:13PM +0200, Roman Zippel wrote:
> What I'm asking for there is the _minimum_ amount of information to do 
> exactly the above. Is there somewhere a provision like "unless you give 
> this data to evil bk haters"?

Roman, you can have any of your data that you want, including the metadata
such as dates, times, user names, etc.  Nobody is hiding that from you,
it's all there, you don't need a license to get it, go to bkbits.net and
get it.  If someone has a tree that you want to get it from you can ask
them to put a copy on bkbits and away you go.

> To make this easier to understand for everyone, here is a simple example: 
> a very simple network protocol would be to extend the current commit mails 
> with the identifiers one can already find in bkcvs, so they can be put 
> into the correct order.

That's not a network protocol, just change the bloody commit trigger.
I don't care if you get that information, if you want it, have at it.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Fri, 29 Oct 2004, Larry McVoy wrote:

> Roman, you can have any of your data that you want, including the metadata
> such as dates, times, user names, etc.  Nobody is hiding that from you,
> it's all there, you don't need a license to get it, go to bkbits.net and
> get it.

I had another closer look and it seems there are good chances to 
reconstruct the data in useable way (especially the rather recently 
added gnupatch and constant link should help). It's not my favourite 
solution, since it has to be pieced together from more parts than really 
necessary, but as proof of concept it should be interesting. So far I 
stayed away from this, because of the traffic this will cause and your 
previous disapproval of causing such traffic, but I can assure you I do my 
best to keep it to a minimum.

> > To make this easier to understand for everyone, here is a simple example: 
> > a very simple network protocol would be to extend the current commit mails 
> > with the identifiers one can already find in bkcvs, so they can be put 
> > into the correct order.
> 
> That's not a network protocol, just change the bloody commit trigger.
> I don't care if you get that information, if you want it, have at it.

I'm still a little confused how this matches your earlier statement, if 
you had said this earlier, we could have cut the whole thing short and I 
could have avoided getting roasted by Linus.
Anyway, I don't really care and thanks for the offer, I certainly will 
come back to it (although not immediately).

bye, Roman

Re: BK kernel workflow

[Pavel Machek]

Hi!

> > In Spain, reverse engineering is allowed for interoperability.
> 
> And in lots of other places.  Which has been mentioned in this and other
> instances of this discussion for the last 5 years.  And the response is
> that BK already gives you documented ways to interoperate, extensively
> documented, in fact.  You can get data and/or metadata into and out of
> BK from the command line.  You could create your own network protocol,
> client, and server using the documented interfaces that BK has.  You
> could create your own CVS2BK tool, your own BK2CVS tool, etc., all
> using documented interfaces.

Actually, I probably could not, due to legal reasons. Or do you tell
me that it is okay for people to develop BK2ARCH importer tool, using
documented interfaces, with free version of bitkeeper?
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 31, 2004 at 10:03:23PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > In Spain, reverse engineering is allowed for interoperability.
> > 
> > And in lots of other places.  Which has been mentioned in this and other
> > instances of this discussion for the last 5 years.  And the response is
> > that BK already gives you documented ways to interoperate, extensively
> > documented, in fact.  You can get data and/or metadata into and out of
> > BK from the command line.  You could create your own network protocol,
> > client, and server using the documented interfaces that BK has.  You
> > could create your own CVS2BK tool, your own BK2CVS tool, etc., all
> > using documented interfaces.
> 
> Actually, I probably could not, due to legal reasons. Or do you tell
> me that it is okay for people to develop BK2ARCH importer tool, using
> documented interfaces, with free version of bitkeeper?

Pavel, you've burned up any goodwill you may have once had.
You getting an exception to the BK license is about as likely as 
you getting a date with Halle Berry.  If that happens, swing by 
to introduce me and I'll be happy to reconsider.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Pavel Machek]

Hi!

> > > > In Spain, reverse engineering is allowed for interoperability.
> > > 
> > > And in lots of other places.  Which has been mentioned in this and other
> > > instances of this discussion for the last 5 years.  And the response is
> > > that BK already gives you documented ways to interoperate, extensively
> > > documented, in fact.  You can get data and/or metadata into and out of
> > > BK from the command line.  You could create your own network protocol,
> > > client, and server using the documented interfaces that BK has.  You
> > > could create your own CVS2BK tool, your own BK2CVS tool, etc., all
> > > using documented interfaces.
> > 
> > Actually, I probably could not, due to legal reasons. Or do you tell
> > me that it is okay for people to develop BK2ARCH importer tool, using
> > documented interfaces, with free version of bitkeeper?
> 
> Pavel, you've burned up any goodwill you may have once had.
> You getting an exception to the BK license is about as likely as 
> you getting a date with Halle Berry.  If that happens, swing by 
> to introduce me and I'll be happy to reconsider.

:-)

Okay, once more, same question. Mail above says that "You
> > > could create your own CVS2BK tool, your own BK2CVS tool,
etc.". Probably not me. But lets say Halle Berry. Is she allowed to
create CVS2ARCH tool?

The mail above seems to suggest she is... Is my impression right? "Is
Halle Berry allowed to write CVS2ARCH tool, using documented
interfaces, with free version of bitkeeper?"
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: BK kernel workflow

[Larry McVoy]

> "Is
> Halle Berry allowed to write CVS2ARCH tool, using documented
> interfaces, with free version of bitkeeper?"

Hey, if Halle Berry wants to use BK for just about anything, she is welcome
to do it, with my blessing.  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Pavel Machek]

Hi!

> > "Is
> > Halle Berry allowed to write CVS2ARCH tool, using documented
> > interfaces, with free version of bitkeeper?"
> 
> Hey, if Halle Berry wants to use BK for just about anything, she is welcome
> to do it, with my blessing.  

Okay. I take that to mean that it is okay to write CVS2<something>
conversion tool, using documented interface, and still use free
version of bitkeeper. (Provided that one is not forbidden from using
it for other reasons).

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 31, 2004 at 10:46:17PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > "Is
> > > Halle Berry allowed to write CVS2ARCH tool, using documented
> > > interfaces, with free version of bitkeeper?"
> > 
> > Hey, if Halle Berry wants to use BK for just about anything, she is welcome
> > to do it, with my blessing.  
> 
> Okay. I take that to mean that it is okay to write CVS2<something>
> conversion tool, using documented interface, and still use free
> version of bitkeeper. (Provided that one is not forbidden from using
> it for other reasons).

As soon as you are Halle Berry, that's true.  Until then, that's not true.

Come on Pavel, you think I'm stupid enough to tell you that you can touch
BK?  No, I'm not.  No, you can't.  Under any circumstances.  You've long
since lost that priviledge and you aren't getting it back.

You've got the BK2CVS tree, I suggest you use it.  That's all you get and
no amount of dancing around with my words will change that.

Are we clear on all this?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Kyle Moffett]

On Oct 31, 2004, at 18:44, Larry McVoy wrote:
> Come on Pavel, you think I'm stupid enough to tell you that you can 
> touch
> BK?  No, I'm not.  No, you can't.  Under any circumstances.  You've 
> long
> since lost that priviledge and you aren't getting it back.

So you are saying that at one point (X days ago) he could have written 
his
own BK2CVS tool without an issue?

I do not know for certain, but I will guess that Pavel has not done 
anything
blatantly illegal or violated the BK license in any way you can prove.  
I am
also guessing that he has not signed any additional contracts or EULAs
with you.

You also appear to be stating in this email that he may _not_ now write
his own BK2CVS tool.

What changed? (Aside from derogatory opinionated remarks in a public
forum which, AFAIK, are not significant in any court of law)

> You've got the BK2CVS tree, I suggest you use it.  That's all you get 
> and
> no amount of dancing around with my words will change that.

You were stating earlier that you are not trying to trap people into 
BK, but
these statements appear to be much to the contrary of that position.

One could theorize that the "preferred form" for the kernel is a tar.gz 
or
tar.bz2 file of the sources, and since you distribute through BK _all_
versions of the kernel, you must also provide a way to get the 
"preferred
form" for any particular version.  I realize that this is somewhat 
difficult,
but if you are going to use contractual crap to restrict Pavel's rights 
to
get at his BK data, then you probably ought to offer to send anybody
a tar.gz or tar.bz2 of any version of the sources at any particular 
time.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 31, 2004 at 10:16:44PM -0500, Kyle Moffett wrote:
> I do not know for certain, but I will guess that Pavel has not done
> anything blatantly illegal or violated the BK license in any way you
> can prove.  I am also guessing that he has not signed any additional
> contracts or EULAs with you.

You guess a lot.  You guess wrong.  A simple google groups search on 
Pavel's name and BitKeeper will give you more than enough data to see
why Pavel has given up any right to use BK.

> You were stating earlier that you are not trying to trap people into BK,
> but these statements appear to be much to the contrary of that position.

Look, Kyle, I've never heard from you before this thread.  However,
I've been around the Linux kernel, helping in various ways, for
more than a decade.  Yes, a lot of people question the BK license,
but my participation here predates that by at least 6 or 7 years.
I'd suggest you do a little research before you start making comments
about my motives.  If I were some sleazy marketing guy showing up out
of nowhere, much as you have shown up, and the first thing I was doing
was more or less "give me all your money", you might have a point.
But that's not the case.  Yes, lots of people beat me up about the BK
license and they may have a point, it's not in the open source spirit,
I get it.  But that doesn't give you the right to start jumping in.
At least not the right to have me take that at face value.

I guess what I'm saying is that I'll take crap from Andrea and Pavel
and Roman because they've been around for a while and while I don't
agree with them on the BK issue I respect their work and their position.
I'm not about to take crap from you, however, until you have contributed
as much here as they have.  No offense, I'm not trying to play old boy
games, I'm just saying that you need to get a little more background
before you spout off.  If I were coming over to the Mac world or the
Windows world and yelling I'd expect exactly the same sort of pushback.
I'll admit that I haven't been reading the list that much lately so
maybe you rock the Linux world and I just don't know about it, in 
which case I apologize, point me at the body of work and I'll start
reading.

> One could theorize that the "preferred form" for the kernel is a tar.gz
> or tar.bz2 file of the sources, and since you distribute through BK
> _all_ versions of the kernel, you must also provide a way to get the
> "preferred form" for any particular version.  I realize that this is
> somewhat difficult, but if you are going to use contractual crap to
> restrict Pavel's rights to get at his BK data, then you probably ought to
> offer to send anybody a tar.gz or tar.bz2 of any version of the sources
> at any particular time.

This would be another example of you not having done your homework.  You
can get that from bkbits.net today, albeit rate limited so the non-BK users
don't screw up the BK users.  
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Pavel Machek]

Hi!

> > > In Spain, reverse engineering is allowed for interoperability.
> > 
> > And in lots of other places.  Which has been mentioned in this and other
> > instances of this discussion for the last 5 years.  And the response is
> > that BK already gives you documented ways to interoperate, extensively
> > documented, in fact.  You can get data and/or metadata into and out of
> > BK from the command line.  You could create your own network protocol,
> > client, and server using the documented interfaces that BK has.  You
> > could create your own CVS2BK tool, your own BK2CVS tool, etc., all
> > using documented interfaces.

Okay, statement here seems to be "it is technically possible to write
BK2something using documented interfaces", problem is just that nobody
but Halle Berry is allowed to do the work. So Larry claims that he's
not doing lock-in because you can export that data. Only catch is that
you are not legally permitted to do that with free version, and Larry
is not going to sell commercial version to you if you do something
like this. So we have unique lockin at legal level, instead of
technical one.

If I misunderstood this, Larry please clarify.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: BK kernel workflow

[Larry McVoy]

On Tue, Oct 26, 2004 at 02:06:54AM +0200, Roman Zippel wrote:
> bk makes it in first 
> place easier to apply and merge a lot of patches, but patches still have 
> to be written, reviewed and maintained. The ability to handle big amounts
> of patches includes also the possibility to merge a lot of crap. What 
> keeps up the general quality? 

http://www.bitkeeper.com/press/newsforgearticle.html - see part 2, the
long answer on development models.  It goes into detail about how it 
can work.

> There is a certain license problem, which very effectly keeps out a lot of 
> those people, who might have other ideas for managing the kernel sources 
> and improving the development process. 

Well, you don't use BK and Andrea doesn't use BK and the arch developers
don't use BK and you have all had at least 3 years to do something better.

> The "protecting IP" talk is 
> complete bullshit, one doesn't need direct access to figure out how it 
> works. There are a few free SCM systems out there, that use very similiar 
> mechanism, they of course still need to work out the details, but it's no 
> magic and just takes times. 

There is a lot more magic in there than you believe and the fact that 
nobody has replicated BK in the last 5 years gives us some reason to
believe that the license is actually working.  

While there is some fairly profound stuff buried inside of BK, it's the
nasty little corner cases which are the hard work.  If I had to divide
up the work I think that the corner cases are more than 80% of the work.
You are mistakenly assuming that the way BK stores the data, or does
merges, or synchronizes is what we think is worth protecting, and you
are pretty much wrong.  Yes, that stuff is interesting to an engineer
because it is something you can describe, it's like math.  But the math
is easy compared to the polishing.

The hard part is all the knowledge about all the little things which go
wrong and how to fix them.  It's relatively easy to make a system which
looks like BK, there are several out there.  They all fall over as soon
as you try and stress them in any way.  The fact that BK doesn't is what
is hard and yes, it *is* worth protecting, we worked very hard to make
BK work for you and we think it is perfectly reasonable that you either
agree to not rip us off or you don't get to use BK.

Our license is not one iota less reasonable than the GPL.  What about all
those people who want to use your work and not give back?  How about that
guy who wants a BSD licensed Linux, for the obvious reasons?  You were all
outraged that that guy would want to rip off your work, why is it so darned
hard for you to see that we are equally outraged when you want to use our
work for free and rip it off?  If you really were about just helping the
world it wouldn't bother you in the slightest to offer up a BSD licensed
Linux kernel.  Admit it, you want to keep on playing in your playground.
That's fine, we want the same thing.  We are both using licensing to 
accomplish our goals.

> Being able to import the kernel repository 
> into them would be a great way to test them, but unfortunately all the 
> free testing is reserved for bk, as usual the winner takes it all and the 
> losers eat the dust, isn't that how open source works...?

Huh?  We make the CVS exported tree available nightly and have been doing
so for more than a year and in spite of all the dire predictions that it 
wouldn't last it's still there.

There are 23,000 commits in the BK2CVS 2.5/2.6 tree.  All on kernel.org
for your importing pleasure complete with all the checkin comments and
other history.

You can import to your hearts content and people have, only to find that
their system falls over dead when they do.  

> Blaming Andrea for this mess is of course easy, but it doesn't solve 
> anything and misses the point, the only thing Andrea is to blame for is 
> that he is not very diplomatic, but that's unfortunately a trait seldom 
> found under hackers. Ignoring the problems and silencing the critics 
> doesn't solve anything and I would be more concerned if nobody would 
> object anymore, when Larry is on one of his ego trips.

Nobody is "blaming Andrea for this mess", all that was being asked was
that he treat other people how he would like to be treated.  What Andrea
and you are doing is similar to that guy asking for a BSD licensed Linux
kernel and continuing to do so at every opportunity.  Wouldn't that get 
a bit old?

As for my ego, my friend, don't flatter yourself that I would come to
this forum to inflate my ego in the unlikely event I felt it needed a
tuneup.  You'd have to be insane to think that hanging out here and
getting crapped on for 5 years is an ego inflating process.  Sheesh.
Who are you kidding?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Mon, 25 Oct 2004, Larry McVoy wrote:

> You are mistakenly assuming that the way BK stores the data, or does
> merges, or synchronizes is what we think is worth protecting, and you
> are pretty much wrong.

Does that mean you don't mind if someones export the changeset information 
in an useful way? All I need is pretty much the information that already 
comes via the commit list (actually in the format used until May, where 
it still contained information about renames) plus some useful identifiers 
to identify the predecessors of a changeset.

bye, Roman

Re: BK kernel workflow

[Larry McVoy]

Roman, 

While I respect your position that anything not GPL is evil, without
agreeing with it, that does not in any way extend to anything which
violates our license.

If there is some information that you need as a kernel developer which
BK is hiding from you of course we would provide that information.
To the best of my knowledge there is absolutely nothing that we are
hiding from you in that context.  If there is, let us know.  Our belief
is at least in part based on the lack of queries from anyone else.

On the other hand, if there is information that is not interesting to
a kernel developer but is interesting to someone trying to rip off our
software, no, we must respectfully decline to offer that.

Thanks,

--lm

On Wed, Oct 27, 2004 at 04:30:37AM +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 25 Oct 2004, Larry McVoy wrote:
> 
> > You are mistakenly assuming that the way BK stores the data, or does
> > merges, or synchronizes is what we think is worth protecting, and you
> > are pretty much wrong.
> 
> Does that mean you don't mind if someones export the changeset information 
> in an useful way? All I need is pretty much the information that already 
> comes via the commit list (actually in the format used until May, where 
> it still contained information about renames) plus some useful identifiers 
> to identify the predecessors of a changeset.
> 
> bye, Roman

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

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Tue, 26 Oct 2004, Larry McVoy wrote:

> On the other hand, if there is information that is not interesting to
> a kernel developer but is interesting to someone trying to rip off our
> software, no, we must respectfully decline to offer that.

Allow me to translate that what this means, so everyone clearly knows 
what's going on here:
The complete development history of the Linux kernel is now effectly 
locked into the bk format, you can get a summary of it, but that's it.
The data everyone put into a bk repository is now owned by BM and only if 
you abide to the rules set by BM, do you have the permission to extract 
some of the data again. You can completely forget the idea to one day 
import "your" data into a different SCM system.

bye, Roman

Re: BK kernel workflow

[Joe Perches]

On Wed, 2004-10-27 at 22:58 +0200, Roman Zippel wrote:
> The complete development history of the Linux kernel is now effectly 
> locked into the bk format, you can get a summary of it, but that's it.
> The data everyone put into a bk repository is now owned by BM and only if 
> you abide to the rules set by BM, do you have the permission to extract 
> some of the data again. You can completely forget the idea to one day 
> import "your" data into a different SCM system.

Nonsense.

I believe these statements to be wrong.
I believe you might even know these statements are wrong.

It's sad really.

Subscribe to BK-KERNEL-COMMITS if you want to see every change
ever made and track them.  Use the web tools, use the CVS.

Perhaps now you'll say something like because BK doesn't provide
a cross-reference tool for every email to LK that proposes some patch
that BK is stopping you from importing "your" data.

Write your own import tools.

Stop whining.  Go write your own SCM.
BitBucket anyone?  Lots of activity on SF.

Re: BK kernel workflow

[Larry McVoy]

On Wed, Oct 27, 2004 at 10:58:03PM +0200, Roman Zippel wrote:
> Allow me to translate that what this means, so everyone clearly knows 
> what's going on here:
> The complete development history of the Linux kernel is now effectly 
> locked into the bk format, you can get a summary of it, but that's it.

That's not even close to being the case.

100% of the information is available on bkbits.net, diffs, comments, 
everything, all of which you can get at with a wget in a form that
is perfect for import into another system.

100% of the data, diffs, comments, everything, is available in a BK2CVS
exported CVS tree.  The comparison of the metadata is as follows:

    System          File deltas		Commits
    BK              203,999		53,274        (1)
    CVS             195,689		23,429        (2)

In other words, the files which contain the data have 96% of the same
information as the BK files, at the same boundaries, the same patches can
be generated, etc.  In 4% of the cases you are looking at a patch which
was two commits in BK but one commit in CVS.  In 4% of the cases only.
96% of the time you'd get the same patch from each system.

Every commit in CVS matches up to a commit in BK, so every commit in CVS
represents a point in the BK history where you get identical output from
BK and CVS.

That's pretty darned good IMO.  You could pick up with those CVS files
and move forward and you've lost no data, no history, and only a tiny
amount of patch boundary history.

What you have lost is some metadata which doesn't translate into CVS and
doesn't translate into Arch, so that's pointless.  And as Andrea said,
Arch can't handle more than 5,000 changesets, and the history exported
is almost 5 times that.

Maybe you weren't aware that that is the situation so you were complaining
about something that wasn't true.  Now that you are aware that you are
getting all of the data, all of the comments, in a form which is 96%
of the way to being identical to BK you will no longer have a complaint.

Regardless of what you believe, Roman, I think that anyone can see that
the statement that the development history of Linux kernel is locked 
into the BK format is not true.  I can't believe anyone could look at 
the data and come to your conclusion.

--lm

(1) To reproduce these numbers, get a BK 2.5 tree and do this:

	CSETS=`bk prs -hnd:I: ChangeSet | wc -l`
	BOTH=`bk -r prs -hnd:I: | wc -l`
	DELTAS=`expr $BOTH - $CSETS`

(2) To reproduce these numbers, get a BK2CVS 2.5 tree and do this:

	DELTAS=`find . -name '*,v' | grep -v ChangeSet,v | xargs egrep '^head[[:space:]]+1\.[0-9]+;|^next[[:space:]]+1\.[0-9]+;' | wc -l`

	Similarly for the ChangeSet,v file to get csets.

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Wed, 27 Oct 2004, Larry McVoy wrote:

> 100% of the data, diffs, comments, everything, is available in a BK2CVS
> exported CVS tree.  The comparison of the metadata is as follows:
> 
>     System          File deltas		Commits
>     BK              203,999		53,274        (1)
>     CVS             195,689		23,429        (2)
> 
> In other words, the files which contain the data have 96% of the same
> information as the BK files, at the same boundaries, the same patches can
> be generated, etc.  In 4% of the cases you are looking at a patch which
> was two commits in BK but one commit in CVS.  In 4% of the cases only.
> 96% of the time you'd get the same patch from each system.

Actually the Commit numbers are far more interesting and here you have 
difference of 56% you haven't explained.
A large number of CVS commits are really also single BK commits (let's say 
30%, I have to leave the verification to you, but I don't think I'm that 
far of), that would leave 70% of BK commits merged into 32% of CVS 
commits. These 70% can't be extracted anymore as a single logical change 
from CVS.
The only reason this number isn't worse is that the kernel development is 
still quite serial, e.g. most of the patches sent by Andrew show up as a 
single commit, but the more people use bk the worse these numbers get.

> That's pretty darned good IMO.

I can play with numbers too...

> Maybe you weren't aware that that is the situation so you were complaining
> about something that wasn't true.  Now that you are aware that you are
> getting all of the data, all of the comments, in a form which is 96%
> of the way to being identical to BK you will no longer have a complaint.

You're only telling half of the story and I'm afraid you'll get away with 
it, because most people don't really know the topic that well and I can't 
blame them.

bye, Roman

Re: BK kernel workflow

[Linus Torvalds]

On Thu, 28 Oct 2004, Roman Zippel wrote:
> 
> Actually the Commit numbers are far more interesting and here you have 
> difference of 56% you haven't explained.

It's because CVS cannot handle what BK does. So when you do a BK merge, 
there's no way in hell that will be a CVS merge, and instead it ends up 
being one big commit of the branch.

Merges happen pretty often, so these "big commits" aren't _that_ big
(certainly nowhere near as big as a CVS banch merge tends to be - if only
simply because nobody uses CVS for "small branches", the pain isn't worth
it). 

Face it. BK is just better than CVS. It's not a 1:1 mapping.

		Linus

Re: BK kernel workflow

[Larry McVoy]

Warning: long message.  Reason you should read it: because I show you
how you can independently verify, without a BK license, that Roman is
spreading FUD.  So read this, check it out, you'll see that this is
all Roman's nonsense.  If you already believe that, you can skip this
but there is a lot of useful BK2CVS data in this message.  

If any of you doubt our good faith this is the message for you to read,
you can see for yourself.  It would be nice if one of you went off and did
what I suggest and reported back the results.  Who knows, maybe there's
a bug.  If you find that to be the case, we'll fix it and re-export the
whole tree to match what it is I'm saying below but I doubt (famous last
words) that you'll find a bug.  If you do, let me know.

> You're only telling half of the story and I'm afraid you'll get away with 
> it, because most people don't really know the topic that well and I can't 
> blame them.

Any of the BK users can go verify my numbers, I even included the commands
I used to generate those numbers.

It's all well and good to say I'm only telling half of the story but
that's not supported by the data.  You have a perfectly legitimate point
if the BK users were getting a lot more information than you are, i.e.,
if you were stuck on tarball/patches and everyone else had BK.  But that's
not the case, you have 96% as much information as any BK user has.  In 
a form which most BK users wish they had, it's more compact, higher
signal to noise.

As for the comment that people don't know the topic that well, you are
exactly right.  One thing that we gave you in the BK2CVS exporter is
changesets.  We didn't have to do that, in fact, in order to do that we
change things very slightly in the RCS history we output.  We arranged
the date/timestamps so that each delta in each file in the same changeset
has the same time and we arranged so that the date in the ChangeSet file
we export matches those.

That was so it would be trivial for people like you to import the data
into an alternative system which has real changesets and preserve the
changeset boundaries.

We had to DO EXTRA WORK to make that happen.  If we had exported the
data exactly as it appears in BK you couldn't recreate the changeset
boundaries.  You could guess but sometimes you'd guess wrong.  We removed
the guesswork.

To most people this is just noise, they don't understand, but what
they should take away from this is that while you are accusing of us of
making it hard for you, we actually made it easy for you.  Anyone can
go verify this, here is how.  In the BK2CVS tree we created a file
called ChangeSet, it has all the changeset comments you see in BK with
bk changes.  Plus one extra datum which looks like this:

BKrev: 417edb4fCTYTu66uKlGNZJVk9pbDDg

That string corresponds to a changeset rev in bk, if you get a bk tree
and do

	bk changes -vr417edb4fCTYTu66uKlGNZJVk9pbDDg

you will see the changeset comments and the file checkin comments for
that changeset.  You will also see the timestamps, which may vary from
file to file.

In the BK2CVS tree, if you were to do an rlog with the exact date string
associated with that rev over all the files, you'll get the same set of
files as you see in that BK changeset, but all the files will have an
identical date.

It's an invariant in the BK2CVS tree that dates are monotonically
increasing, each changeset has a different date, and each file
participating in the changeset has the same date as the changeset.
None of that is necessarily true in the BK tree.  That's something we
did to make it absolutely TRIVIAL to import this history properly into
some other SCM system like arch or whatever.

I want to underscore that.  We gave you the bk exported tree but we
modified it to make it easier for you to recreate a more exact copy of
what is in BK.  We didn't have to do that, it was extra work, noone could
have faulted us for doing a perfectly exact export, but we tweaked it to
make it easy for you.  I can easily believe that this is the first time
that you realized this.  Whatever, it's true, anyone can go verify it.
It demonstrates a tremendous goodfaith effort on our part to make sure
that you could track a BK tree accurately.

If we were trying to screw you over, as you take every opportunity to
suggest we are, then how do you explain this extra effort we went to?
You yourself can verify this, you don't need a BK license, those strings
work in bkweb.  You go to

http://linux.bkbits.net:8080/linux-2.5/gnupatch@417edb4fCTYTu66uKlGNZJVk9pbDDg

i.e.,

http://linux.bkbits.net:8080/linux-2.5/gnupatch@$BKREV

for any value of Bkrev in the BK2CVS export tree, you'll see the list of
files, you'll see the dates.  Now go look at the same list of files in the
BK2CVS tree and you'll notice that the dates are just slightly different,
usually by a few seconds, but regardless of the amount they are different,
they are always the same value in all files in the same changeset.

Just so you, my loyal enemy, can have an easier time to import this data
correctly into your favorite competing system.

Go verify that, see that I'm telling the truth, see that the BK data is
slightly less consistent, and explain to me what possible reason we could
have had for doing that other than to help you.  Then explain to me how
you can claim that we're trying to screw you somehow in that history.

I know _you_ won't, you are prejudiced against us so anything which might
show us in a positive light isn't something you will do.  But any other
reader of this thread can do it, some will do it, and I hope they report
back here that things are exactly as I say they are and that the only
conclusion anyone can draw is that you are fanatical guy who doesn't
want realize or admit we actually tried to help you in good faith.
I don't really care if you ever realize that but I'd like it if other
people went off and checked and figured out "hey, those BitMover guys
may have a wacky license but they really are trying to help, they even
try and help the non-BK users".  That would be nice.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Wed, 27 Oct 2004, Larry McVoy wrote:

> Warning: long message.  Reason you should read it: because I show you
> how you can independently verify, without a BK license, that Roman is
> spreading FUD.  So read this, check it out, you'll see that this is
> all Roman's nonsense.  If you already believe that, you can skip this
> but there is a lot of useful BK2CVS data in this message.  

I have to apologize, there is a little more data in cvs repository, but it 
doesn't change in any way what I was trying to tell Linus.
It seems I made another mistake, I have to apologize for. I didn't realize 
that the kernel repository is a private party and you are the bully at the 
door. Well, it seems I'm not cool enough and I deeply apologize for 
bothering you guys.

All I have left to say is that, what I said before is everything but 
nonsense and I invite everyone to verify what I say and whether Larry 
really tells the complete story.
So for example the 56% number is very real:

$ rlog ChangeSet,v | grep BKrev: | wc -l
23461

The number of the changesets in the bk repository is around 53000, this is 
the difference I talked about and it's real. What does this mean? The bk 
repository contains around 53000 snaphots of kernel development history, 
44% of these snapshots can be restored via bkcvs. So where is the rest?

bk preserves the history nonlinearly, e.g. something like this:

	t1 -> t2 -> t3 -> t4 -> t5
	 +--->  t1.1 -> t1.2 ---^

This means someone cloned the repo at t1 and committed some changes at 
t1.1 and t1.2, in the meantime the changes t2, t3, t4 were applied to the 
parent repo and at t5 the changes from the cloned repo were merged.

CVS by itself can't of course represent this history, so it only contains 
the changes from t1, t2, t3, t4, t5, the snapshots t1.1, t1.2 cannot be 
restored anymore reliably from bkcvs, one can only get the merged 
changeset t5. As it's rather likely that every commit changes different 
files, one can actually get 100% of the file changes, but you still have 
in this case only 71% percent of the commits. Why would anyone be 
interested in the remaining 29%? Only with the complete information one go 
back to any previous snapshot, so if e.g. something went wrong during the 
merge in t5, it's quite easy to tell that it still worked at t4 and t1.2. 
Without the extra information one only knows that it went wrong after t4. 
Applied to bkcvs this means a problem can be located with a precision of 
44% and this number is still quite high as I mentioned in the last mail. 
The more bk users the less this number becomes. Let's say 5 people set up 
a repo with 20 changes each to let Linus pull from them, instead of 
sending them to Andrew, so they can end up as just 24 commits in bkcvs. 
The little grepping I did on ChangeSet,v seems to backup my theory (if 
someone knows how to get real numbers, I'd love to hear them), I looked at 
pulls from the net, scsi and Greg's repo and most of them are indeed 
merged into a single bkcvs commit.

On the other hand Larry's 96% number sounds impressive, but it's the less 
interesting one, if some of the commit information is missing, it's 
nontrival to put the file changes in the correct context. In the example 
above this means the individual file patches of t1.1 and t1.2 have to be 
matched to the corresponding splitted changelog of t5, it's anything but 
trivial, if it's possible at all and it doesn't provide the information 
that t1.1 has to be applied on top of t1. This means that it's often 
possible to extract a changeset manually, but doing it automatically is 
rather impractical and not worth the trouble.

Now it's theoretically possible to extract data via bkweb, but I (and I 
hope not only me) still remember what happened last time Andrea tried 
that, so I haven't actually looked into it too deeply. It certainly is
possible to extract all commits, the problem starts with putting them into 
a context. The repository information in bkweb is a bit filtered (e.g. 
empty merges), which are of only little interest to the human viewer, but 
that makes it interesting to reliably tell where a branch starts and end. 
Without further research I can only guess, whether that information is 
deducible or has to be extrapolated.

Finally the commit mails have really only informational value, as they 
lack any usable context.

Well, that's about it about the usefulness of the public available 
information. So if anyone could tell me, what exactly is FUD about this, 
I certainly would love to know it.

So why do I actually care about this data? For one I have that weird idea 
that the goals of a free software project should be reflected in its 
development process, that I actually get insulted for this is a truly 
strange experience.
I would really like to have access to this data, it's data I contributed 
to, it's data I care about and which I'm working on a lot of time anyway, 
but unfortunately full access to this data is restricted to a private 
club. Consequently this means that there will never be a gateway to easily 
exchange data, if synchronization is limited to bkcvs, this will cause 
unnecessary conflicts. If the information has to go via 
scm->patch->bk->bkcvs->scm, some information obviously get lost and the 
scm can only guess whether the information has been merged or not. IOW an 
alternative scm will always be in a disadvantage...

Anyway, I will now go away and play with the other uncool kids.

bye, Roman

Re: BK kernel workflow

[Eric Mudama]

On Thu, 28 Oct 2004 23:03:42 +0200 (CEST), Roman Zippel
<zippel@linux-m68k.org> wrote:
    [munch]
> CVS by itself can't of course represent this history
    [munch]


At least you understand the problem, whether you realize it or not.

However, Larry's job isn't to make CVS better.  Why is this still
being argued? (oh yea, everyone is tired of arguing politics in the US
at least...)

--eric

Re: BK kernel workflow

[Larry McVoy]

On Thu, Oct 28, 2004 at 11:03:42PM +0200, Roman Zippel wrote:
> [complaints about the awful horrible evil BK2CVS tool]

You guys work in patches all the time.  Complaining about this loss
information is like whining at Andrew because he removes some patches
from the -mm tree.  There is no record of all the combinations of the
-mm tree and you aren't whining at Andrew?  Why not?

There is no record of all sorts of patch combinations out there and you
aren't complaining about it.  Why not?

I can tell you why not.  Because the combination and recombination of
those patches doesn't give you any insight into how BK works.

If you don't like the situation, you are welcome to go create a better 
system.  You do not get to use BK to do so, those are our rules.  You
do not get to use BK metadata to do so either, those are also our rules.

Believe it or not, I understand your frustration and can understand
how pissed off this makes you.  It's pretty frustrating on all sides.
But it's not unreasonable.  It is a reasonable thing to protect our
work, just as it is reasonable for you to protect your work against
GPL violators.

We're being reasonable, you are just frustrated that it's reasonable for
us to protect what we built and what we own.

I understand your position, you want the kernel to be a showcase for
how well free software works.  It should be developed, managed, enhanced
with 100% free software, at least in your mind.  A fine goal, and one
you could realize.  

However, one of my claims over the years is that a lot of free software
is a reimplementation of some closed software.  I've also claimed that it
is much easier to do that if you have access to the closed software, the
closed software becomes a very good specification of what should be done.
When I've claimed this lots of you get pissed off and say it's not true,
free software innovates, etc.  Sure it does, but my statement stands.
The fact that you are working so hard to get your fingers on things that
we figured out is an excellent example of the point.  If it were easy
for you to create a BK clone you would have done so already and thumbed
your nose at me.

Every time you come back and complain that you aren't getting enough 
information from us you are making my case.  Free software, at least
some of it, is no more than a copy.

It's my claim that I value free software even *more* than you do.  Why?
Because I keep trying to draw attention to this problem, the problem
of how do we pay for the development truly innovative free software.
You are hurting the cause of free software by making a public spectacle
of yourself by asking over and over again for help from a commercial
company to copy that commercial companies' software.

If you truly believed in the cause you would go off and try and build
a real BK replacement using free software tools, using only freely
available knowledge, and using funding generated from free software.
That would be the best way to prove to the world that I'm just wrong.
I would welcome that.  I'd come work with you if you figured out how
to do that.  If you think I enjoy arguing with the people I'm trying 
to help you're mistaken.  This is no more fun for me than it is for you.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Thu, 28 Oct 2004, Larry McVoy wrote:

> I understand your position,

No, you don't and as I doubt you'll ever get it, I'll better leave at 
that.

bye, Roman

Re: BK kernel workflow

[Manu Abraham]

On Fri October 29 2004 2:45 am, Larry McVoy wrote:
> On Thu, Oct 28, 2004 at 11:03:42PM +0200, Roman Zippel wrote:
> > [complaints about the awful horrible evil BK2CVS tool]
>
>  You
> do not get to use BK metadata to do so either, those are also our rules.
>

The contents of the BK, ie the metadata is Free software, licensed under the 
GPL. Therefore i don't understand .. Isn't this then a violation of the GPL ?

Isn't this something like M$ stating that you are the property of M$ because 
you are using one of their systems. Worser still ? Do you mean to say M$ owns 
all *.doc, *.xls  files etc as an example... If so, then that is really 
bad ..

> Free software, at least
> some of it, is no more than a copy.
>

sarcasm ? Even the linux kernel is free software ..
Isn't this is just like M$ marketing talk ?

> It's my claim that I value free software even *more* than you do.  Why?

It's a contradiction, considering the earlier two statements.

I agree to the fact that BK has made Kernel development faster, which has 
therefore helped.

I'm not a BK user. I download the tarballs, but the statements by Mr. Larry 
has shaken me a bit. 

As per the statements by Mr. Larry, what i understood is that the BK metadata 
belongs to Mr. Larry legally as per the US rules and regulations.


Manu
> 

Re: BK kernel workflow

[Scott Lockwood]

Microsoft does own certains things in their business that people put their
data thru. That doesn't mean MS owns your word document. It means they own
parts of their technology that allow you to create that word document.

Why is this so hard for (some of) you people to understand?

The horse is dead - you can stop beating it now.

> On Fri October 29 2004 2:45 am, Larry McVoy wrote:
>> On Thu, Oct 28, 2004 at 11:03:42PM +0200, Roman Zippel wrote:
>> > [complaints about the awful horrible evil BK2CVS tool]
>>
>>  You
>> do not get to use BK metadata to do so either, those are also our rules.
>>
>
> The contents of the BK, ie the metadata is Free software, licensed under
> the
> GPL. Therefore i don't understand .. Isn't this then a violation of the
> GPL ?
>
> Isn't this something like M$ stating that you are the property of M$
> because
> you are using one of their systems. Worser still ? Do you mean to say M$
> owns
> all *.doc, *.xls  files etc as an example... If so, then that is really
> bad ..
>
>> Free software, at least
>> some of it, is no more than a copy.
>>
>
> sarcasm ? Even the linux kernel is free software ..
> Isn't this is just like M$ marketing talk ?
>
>> It's my claim that I value free software even *more* than you do.  Why?
>
> It's a contradiction, considering the earlier two statements.
>
> I agree to the fact that BK has made Kernel development faster, which has
> therefore helped.
>
> I'm not a BK user. I download the tarballs, but the statements by Mr.
> Larry
> has shaken me a bit.
>
> As per the statements by Mr. Larry, what i understood is that the BK
> metadata
> belongs to Mr. Larry legally as per the US rules and regulations.
>
>
> Manu
>>
> -
> 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: BK kernel workflow

[Roman Zippel]

Hi,

On Fri, 29 Oct 2004, Manu Abraham wrote:

> On Fri October 29 2004 2:45 am, Larry McVoy wrote:
> > On Thu, Oct 28, 2004 at 11:03:42PM +0200, Roman Zippel wrote:
> > > [complaints about the awful horrible evil BK2CVS tool]
> >
> >  You
> > do not get to use BK metadata to do so either, those are also our rules.
> >
> 
> The contents of the BK, ie the metadata is Free software, licensed under the 
> GPL. Therefore i don't understand .. Isn't this then a violation of the GPL ?

What someone does in the privacy of his home is outside the scope of the 
GPL, this means the kernel repository is the private toy of Linus and he 
leaves the decision who may play with him to Larry.
This is also means that Linux history recorded in bk is not part of the 
public record. This is an unfortunate fact and not a complaint BTW, but 
Larry has not much use for facts anyway, when I try to summarize the facts 
around the publicly available information as best as I can, Larry doesn't 
even try to prove me wrong and instead continues to attack me personally. 
I don't really care about the latter, but that he gets the support to do 
so is the personally very disappointing part. :-(

bye, Roman

RE: BK kernel workflow

[David Schwartz]

> What someone does in the privacy of his home is outside the scope of the
> GPL, this means the kernel repository is the private toy of Linus and he
> leaves the decision who may play with him to Larry.

	This position is conditioned on two facts, either:

	1) Linus does not distribute his BK tree, or

	2) Linus' BK tree is not a derivative work of the Linux kernel

	If both of these are false, then the tree must be covered by the GPL. I
think 2 is clearly false.

	DS

Re: BK kernel workflow

[Valdis.Kletnieks]

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

On Fri, 29 Oct 2004 09:41:42 PDT, David Schwartz said:

> 	This position is conditioned on two facts, either:
> 
> 	1) Linus does not distribute his BK tree, or
> 
> 	2) Linus' BK tree is not a derivative work of the Linux kernel
> 
> 	If both of these are false, then the tree must be covered by the GPL. I
> think 2 is clearly false.

The *contents of the source of the tree itself* are indeed GPL, and I doubt that
anybody argues otherwise.  The actual method(s) used to *STORE* said contents
are *NOT* GPL - if you argue that the fact of storing the source in a BK tree
renders the BK itself GPL, then we should stroll over to Redmond with a laptop
that has a copy of the source untarred into an NTFS filesystem, and demand that
they cough up the source for NTFS.

Is anybody arguing that doing that would GPL NTFS? If no, then it doesn't GPL
any of the BK bits either.

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

RE: BK kernel workflow

[David Schwartz]

> The *contents of the source of the tree itself* are indeed GPL,
> and I doubt that
> anybody argues otherwise.

	Good, I'm glad we agree on that.

> The actual method(s) used to *STORE*
> said contents
> are *NOT* GPL

	Of course not.

> - if you argue that the fact of storing the source
> in a BK tree
> renders the BK itself GPL, then we should stroll over to Redmond
> with a laptop
> that has a copy of the source untarred into an NTFS filesystem,
> and demand that
> they cough up the source for NTFS.

	No, I'm not arguing that.

> Is anybody arguing that doing that would GPL NTFS? If no, then it
> doesn't GPL
> any of the BK bits either.

	Since nobody made that argument, I'm puzzled why you feel the need to
refute it.

	Here is the argument I was replying to:

>> What someone does in the privacy of his home is outside the scope of the
>> GPL, this means the kernel repository is the private toy of Linus and he
>> leaves the decision who may play with him to Larry.

	DS

Re: BK kernel workflow

[Chris Friesen]

David Schwartz wrote:

> 	This position is conditioned on two facts, either:
> 
> 	1) Linus does not distribute his BK tree, or
> 
> 	2) Linus' BK tree is not a derivative work of the Linux kernel
> 
> 	If both of these are false, then the tree must be covered by the GPL. I
> think 2 is clearly false.

The linux tree is certainly a derivative work of itself.  The more important 
(and much more difficult) question is whether the metadata about the tree is a 
derivative work under the rules of the GPL, or whether it is mere aggregation.

I think you could make a compelling argument that the linux kernel history 
metadata is *not* covered under the GPL, and hence can be restricted by licensing.

Chris

Re: BK kernel workflow

[Ryan Anderson]

On Fri, Oct 29, 2004 at 01:03:15PM -0600, Chris Friesen wrote:
> David Schwartz wrote:
> 
> >	This position is conditioned on two facts, either:
> >
> >	1) Linus does not distribute his BK tree, or
> >
> >	2) Linus' BK tree is not a derivative work of the Linux kernel
> >
> >	If both of these are false, then the tree must be covered by the 
> >	GPL. I
> >think 2 is clearly false.
> 
> The linux tree is certainly a derivative work of itself.  The more 
> important (and much more difficult) question is whether the metadata about 
> the tree is a derivative work under the rules of the GPL, or whether it is 
> mere aggregation.
> 
> I think you could make a compelling argument that the linux kernel history 
> metadata is *not* covered under the GPL, and hence can be restricted by 
> licensing.

On the other hand, there is that whole "preferred form" part of the GPL
that could seriously muddy this issue.

-- 

Ryan Anderson
  sometimes Pug Majere

RE: BK kernel workflow

[David Schwartz]

> I think you could make a compelling argument that the linux
> kernel history
> metadata is *not* covered under the GPL, and hence can be
> restricted by licensing.

	That's an interesting argument. I think you could argue that a BK
repository is an aggregation of metadata and the kernel source, and
therefore only the kernel source needs to be distributed. IANAL, this
question has now gotten into territory in which I don't feel comfortable
offering an opinion.

	As for the 'preferred form' argument, I think an argument can be made that
the source itself is the preferred form of the work for the purpose of
making modifications to it. One uses the BK repository to *get* the
preferred form. Again, though, one could argue the other side of this --
that it's preferred to have the metadata to make the modifications.

	DS

Re: BK kernel workflow

[Pavel Machek]

Hi!

> > Allow me to translate that what this means, so everyone clearly knows 
> > what's going on here:
> > The complete development history of the Linux kernel is now effectly 
> > locked into the bk format, you can get a summary of it, but that's it.
> 
> That's not even close to being the case.
> 
> 100% of the information is available on bkbits.net, diffs, comments, 
> everything, all of which you can get at with a wget in a form that
> is perfect for import into another system.

...but, if someone actually *tries* to import it into another system,
your bandwidth bill will be so huge that you'll stop bkbits.net, no?
How many terabytes would need to be transfered in order to do complete
import of linux-kernel into another system?
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: BK kernel workflow

[Larry McVoy]

On Sun, Oct 31, 2004 at 09:47:17PM +0100, Pavel Machek wrote:
> How many terabytes would need to be transfered in order to do complete
> import of linux-kernel into another system?
> 								Pavel

Not as much as it would take to do the same thing from a remote CVS server.
CVS is dramatically worse than diff and patch.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Sam Ravnborg]

On Sun, Oct 31, 2004 at 09:47:17PM +0100, Pavel Machek wrote:
 
> ...but, if someone actually *tries* to import it into another system,
> your bandwidth bill will be so huge that you'll stop bkbits.net, no?
> How many terabytes would need to be transfered in order to do complete
> import of linux-kernel into another system?

Anyone that is allowed to use bitkeeper can do this.
Transfer data to another SCM is not illegal according
to the bk license.

	Sam (one of many happy bk users)

Re: BK kernel workflow

[Theodore Ts'o]

On Wed, Oct 27, 2004 at 10:58:03PM +0200, Roman Zippel wrote:
> 
> Allow me to translate that what this means, so everyone clearly knows 
> what's going on here:
> The complete development history of the Linux kernel is now effectly 
> locked into the bk format, you can get a summary of it, but that's it.
> The data everyone put into a bk repository is now owned by BM and only if 
> you abide to the rules set by BM, do you have the permission to extract 
> some of the data again. You can completely forget the idea to one day 
> import "your" data into a different SCM system.

As compared to *before* we started using BK, when we kept no
development history whatsovever?  You think that's any better?

The summary of the information is pretty much everything that you
could get out of any other revision control system, so what's your
beef?

						- Ted

Re: BK kernel workflow

[Pete Zaitcev]

On Tue, 26 Oct 2004 02:06:54 +0200 (CEST), Roman Zippel <zippel@linux-m68k.org> wrote:

> There is a certain license problem, which very effectly keeps out a lot of 
> those people, who might have other ideas for managing the kernel sources 
> and improving the development process. [...]

Roman, I don't think this is valid. I don't use BK, and my patches still
get in somehow. Neither Greg Kroah or DaveM ever made any issue of it.

If people have ideas, they ought to participate as is, then present
ideas based on their experience. I don't think that BK prevents "a lot
of those people" from working on kernel and presenting ideas.

-- Pete

Re: BK kernel workflow

[Matthias Urlichs]

Hi, Andrea Arcangeli wrote:

> one more tainted open source
> developer that will not be allowed by law to ever compete with your
> business, right?

Wrong. Since when does usage constitute "tainted" knowledge?
You get tainted knowledge by looking at source code, not by usage.

By the same token, users of MS Office, which is even more restrictively
licensed than BK (no free use whatsoever, remember?), couldn't work on
OpenOffice.org.


The license says that, if you work on a competing system, you cannot use
BK. It cannot prevent somebody who has used BK sometime in the past, from
writing an SCM sometime in the future, since the license governs only your
use of BK, but not whatever else you're doing. It's a license for
BitKeeper and not for anybody's brain, after all.

<parrot whom="Linus">Andrea, shut up.</parrot>

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: BK kernel workflow

[Andrea Arcangeli]

On Mon, Oct 25, 2004 at 09:51:31PM +0200, Matthias Urlichs wrote:
> Wrong. Since when does usage constitute "tainted" knowledge?
> You get tainted knowledge by looking at source code, not by usage.

come on, as someone stated in other thread the licence doesn't even
appear legal in europe, so what do you expect?

> By the same token, users of MS Office, which is even more restrictively
> licensed than BK (no free use whatsoever, remember?), couldn't work on
> OpenOffice.org.

Note that if I would be buying a BK non-free licence the "restrictions"
would go away AFIK. However Miles (on the arch list) tries to buy one
(exactly so he could test BK) and he failed to get one.

"no free use" may be less restrictive than the "free licence". You pay
to get more freedom, which sounds fair.

> The license says that, if you work on a competing system, you cannot use
> BK. It cannot prevent somebody who has used BK sometime in the past, from
> writing an SCM sometime in the future, since the license governs only your
> use of BK, but not whatever else you're doing. It's a license for
> BitKeeper and not for anybody's brain, after all.

either you're completely wrong or Larry did not protect any IP.

Larry said in an earlier email today: "we have to protect our IP.
Rightly or wrongly, we feel we did some new work that is worth
protecting.".

don't get me wrong, I've nothing against protecting IP, but my point is
how can he protect IP if I can use BK, learn all the features, then the
next day I stop using them and contribute to another SCM after the
knowledge learned? I mean, there must be a delay between the two events
otherwise what a protection is that. I can use BK the next second I stop
using BK and I make a patch to arch, the next second I use BK again.

I would be *very* happy if you were right in the way you interpret the
licence, if Larry could confirm you didn't misread the licence, I could
sure use bitkeeper too (at least to try it once, you know I may be
curious about testing bk speed after all these talks).

But I'm not attempting that unless Larry confirms I can learn using bk
and immediatly after I can contribute to arch or some other SCM to
possibly implement overlapping features (and so far I clearly understood
this was not possible, and this is also why it didn't look legal in
europe but IANAL).

Re: BK kernel workflow

[Miles Bader]

Andrea Arcangeli <andrea@novell.com> writes:
> Note that if I would be buying a BK non-free licence the "restrictions"
> would go away AFIK. However Miles (on the arch list) tries to buy one
> (exactly so he could test BK) and he failed to get one.

Nope, that wasn't me; I don't have any money... :-(

-Miles
-- 
97% of everything is grunge

Re: BK kernel workflow

[Jon Smirl]

On Mon, 25 Oct 2004 09:20:22 -0700, Larry McVoy <lm@bitmover.com> wrote:
> That's strange, I wonder why you think BK doesn't help.  The prevailing
> wisdom is that it has helped.  It's well documented by third parties
> who have nothing to do with you or me.

>From what I see BitKeeper has definitely helped the kernel development
processes. On the other hand BitKeeper has been stable for the last
couple of years. Are we going to see any large changes in BK any time
soon? For example BK could be extended to handle the workflow AndrewM
does. Another extension would be for moving signed patches through the
system to help avoid another SCO problem. Any hints on where the
future is going? Can BK be extended to further automate the kernel
development workflow?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: BK kernel workflow

[Larry McVoy]

On Mon, Oct 25, 2004 at 02:18:43PM -0400, Jon Smirl wrote:
> On Mon, 25 Oct 2004 09:20:22 -0700, Larry McVoy <lm@bitmover.com> wrote:
> > That's strange, I wonder why you think BK doesn't help.  The prevailing
> > wisdom is that it has helped.  It's well documented by third parties
> > who have nothing to do with you or me.
> 
> >From what I see BitKeeper has definitely helped the kernel development
> processes. On the other hand BitKeeper has been stable for the last
> couple of years. Are we going to see any large changes in BK any time
> soon? For example BK could be extended to handle the workflow AndrewM
> does. Another extension would be for moving signed patches through the
> system to help avoid another SCO problem. Any hints on where the
> future is going? Can BK be extended to further automate the kernel
> development workflow?

While BK has been stable that doesn't mean it is even remotely close to
being done.  We've got more people working on BK now than ever before.
I think you might be used to scm systems sucking so you look at BK and
say it's better therefor it's done.  We don't agree.

Things we are working on include performance (Wayne has a hot cache
linux-2.5 tree consistency check down to around 2 seconds, that's
about a 10x improvement over what it is now), we're revamping the GUIs
to be useable by normal humans, we're working on scaling to >500,000
changesets in one tree, we're working on scaling the number of files and
source to millions of files and GB of source (we just had to recompile
with largefile support for a customer this weekend, while it worked,
we thought the performance on a 2GB file was pathetic, it is pathetic,
it should run at the platter speed but as I dug into I found it out
wasn't that easy), we're working bug database integration, we're working
on review queues, we're working on project management, we're working on
large binary management, etc.

The list goes on, if anyone wants to come work on it we are always looking
for good systems people and we pay well.  Try userland, you might like it :)

As for digital signatures, we quietly added that a long time ago,
every push by Linus or Marcelo to bkbits.net is digitally signed twice,
once over all the data including BK metadata and once over the checked
out files.  The reason we do both is so people not using BK can verify
the signatures.  If you want to be on the mailing list which gets these
signatures send me mail, if I get swamped I'll push it over to mailman.
Right now they go to Linus, Ted T'so, AndrewM, and Marcelo.  They should
go more places so we have more people who can archive them in case 
something goes wrong.

As for handling AndrewM's workflow, we're very interested in that
area because there seems to be a sort of bimodal development model,
changes which are not yet "frozen" (best managed by something like
quilt it seems) and changes which are frozen (best managed by BK).
We do well at part of it and suck at the other part.  I've always 
excepted arch to come into use for the unfrozen part but for some
reason people seem to like quilt better.  I haven't played with 
quilt enough to know why yet.

The unfrozen management works for Adrew because he is doing all the work,
the tools help as much as they can but he is really very much in control.
That model doesn't scale to a distributed/replicated development model, at
least it doesn't scale as well as BK scales, it scales as well as diff &
patch & wiggle scale.  For Andrew, it's more or less fine, but if Andrew
tried to scale that to a few hundred developers all doing additional
work on the moving target of patches he'd go nuts.  As it is I can't
imagine how he doesn't go nuts.

We'd like to handle it better and I've had conversations with various
people over the years and so far no lightbulb has come on.  If there is
one, we'll find it, some of the problems we solved in BK felt sort of
similar and had to cook for around 3 years before the lightbulb came on.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Chris Wedgwood]

On Mon, Oct 25, 2004 at 04:01:28PM -0700, Larry McVoy wrote:

> Things we are working on include performance (Wayne has a hot cache
> linux-2.5 tree consistency check down to around 2 seconds, that's
> about a 10x improvement over what it is now),

i'm still at 16s here, i would *love* to see this performance speed
increase in the free version that is made available for kernel people

> we're revamping the GUIs to be useable by normal humans, we're
> working on scaling to >500,000 changesets in one tree

one thing i wondered about, is there some way you can optimize
performance knowing for repositories like the kernel tree where the
access patterns are pretty much (for me anyhow) pull in new stuff,
look back a few weeks, maybe clone back as far as a month but beyond
that i rarely pay any attention?

i guess what i'm doing a bad job of saying is that it seems i'm using
only the most recent weeks/days of changes 99% of the time --- can i
do something knowing this that makes my day to day life easier at
maybe the expensive of cloning something really old?

> As for handling AndrewM's workflow, we're very interested in that
> area because there seems to be a sort of bimodal development model,
> changes which are not yet "frozen" (best managed by something like
> quilt it seems) and changes which are frozen (best managed by BK).

right now i use quilt and bk together, i'm still trying to refine a
nice way of doing that (which i should document) but on the whole they
don't conflict as a rule and it's really not that bad.  previously i
was using bk like quilt using a script to make csets from patches and
then i would undo to roll back before pulling and what-not but this
was error-prone at times (sometimes i would pull from the parent which
would do a merge so i couldn't roll back after that)


i really don't know why people bitch so much about bk personally, i
really like it, it's much more reliable than svn for me (bk checksums
whilst i might complain about them have found fs bogons a number of
times, with svn i just have a collection of busted db files), it's
much faster than CVS and the bk development model (well, the model i
have when i use it) works better by far than anything i've used
previously

i like bk, i'll continue to use it where possible, for those that have
strong feelings against bk, well, stick with CVS (or whatever) then.
enjoy your pain.

Re: BK kernel workflow

[Jon Smirl]

On Mon, 25 Oct 2004 16:01:28 -0700, Larry McVoy <lm@bitmover.com> wrote:
> As for digital signatures, we quietly added that a long time ago,
> every push by Linus or Marcelo to bkbits.net is digitally signed twice,

Would it be useful for BK to provide more detailed tracking of who
made what changes to the kernel?

For example  a digital signature trail on change sets that tracks who did
what. Say I do some changes on my local tree, export it and
mail it out on lkml. This change set is picked up by Andrew. Andrew
munges on it some and sends it onto Linus. Linus changes another
couple of lines and puts it in his tree.  Now I go to bkbits and look
at the history for the lines changed. Can I see what Linus, Andrew and
I have all changed including digital signatures?

The final change set going into linus' tree would have to embed my
orginal change set intact but hidden since it is signed by me and
Linus doesn't have my key.  Andrew's and Linus' changes would be added
as signed diffs against my original change set.

You would also need a scheme to import signed diffs and preserve the
signature for non-bk users.

This would automate the "Signed off by" process. It would also much
more accurately track who did what to the tree.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: BK kernel workflow

[Matthias Urlichs]

Hi, Jon Smirl wrote:

> For example  a digital signature trail on change sets that tracks who did
> what. Say I do some changes on my local tree, export it and
> mail it out on lkml. This change set is picked up by Andrew. Andrew
> munges on it some and sends it onto Linus. Linus changes another
> couple of lines and puts it in his tree.  Now I go to bkbits and look
> at the history for the lines changed. Can I see what Linus, Andrew and
> I have all changed including digital signatures?

Sure you can, if you use the "bksend" script Andrew can import your
changes into a bk tree, change them, and then send the combined changes to
Linus.

The problem is that unless both Andrew's and Linus' tree are at exactly
the same version yours is, there will be some merge changesets in between
which really muddle up the change history.

That's fixable, but "bk clone" plus "bk undo" are too expensive at the
moment -- if that took a few seconds instead of a few minutes, people
would probably do it more readily.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: BK kernel workflow

[Giuseppe Bilotta]

Larry McVoy wrote:
> Things we are working on include performance (Wayne has a hot cache
> linux-2.5 tree consistency check down to around 2 seconds, that's
> about a 10x improvement over what it is now), we're revamping the GUIs
> to be useable by normal humans, we're working on scaling to >500,000
> changesets in one tree, we're working on scaling the number of files and
> source to millions of files and GB of source (we just had to recompile
> with largefile support for a customer this weekend, while it worked,
> we thought the performance on a 2GB file was pathetic, it is pathetic,
> it should run at the platter speed but as I dug into I found it out
> wasn't that easy), we're working bug database integration, we're working
> on review queues, we're working on project management, we're working on
> large binary management, etc.

Ok this is probably a very stupid proposal, but since I just 
woke up I feel like saying stupid things, and plus I'm happy 
with my 512 extra RAM, so here goes:

have you considered some kind of "open source obsolete 
versions" procedure à la Aladdin? They develop GhostScript, and 
have some sort of "dual licence" strategy: the latest version 
follows the AFPL licence, and older versions are released under 
GPL.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: BK kernel workflow

[Linus Torvalds]

On Sun, 24 Oct 2004, Paolo Ciarrocchi wrote:
> 
> Well, I'm not interested in having the list of all the bk trees used
> during the develpoment of a release.
> I was looking to the trees used by mantainers.

Well, not only is "maintainer" fairly fluid, as Larry said, even if you 
accept the fact that things will change, there's the issue that

 - I do _not_ want people to "own" subsystems. And that's not so much an 
   anti-maintainer issue (I _love_ maintainers), as more of a "conceptual" 
   issue. When people expect one person or one group of person to be the 
   only way to touch a certain subsystem, we have problems. I really 
   really want everybody (users, developers _and_ maintainers) to realize 
   that no code is an island, and work with other people touching their 
   subsystem.

   And part of that is that I do not like codifying maintainership. Even 
   something as simple as saying "this tree is the xxxx tree" is in my 
   opinion _bad_. Yes, a lot of core development for subsystems happen in 
   some specific "subsystem tree", but every time that has turned into 
   something "exclusive", it's been a _major_ problem.

   And yes, we've had that problem several times. People having CVS trees 
   for networking, sound drivers, and other special development 
   subprojects invariably ended up breakign and throwing away work that 
   happened "unofficially". And often the "unofficial" work is nearly as 
   important as the official one.

   So BK helps this model, because the distributed nature of BK means that 
   you can have several pseudo-official trees _and_ totally unofficial
   ones, and merging is automatic and basically impossible to avoid, so 
   the "official" tree never gets to drown out the unofficial work. But 
   despite that, I want to make people _aware_ that maintainership does
   not imply total ownership, and that we don't have a "hierarchy" of 
   developers but a *network* of developers.

   To make a long story short: I do not ever even WANT "official" trees. 
   Because it gives the wrong idea to people.

   I don't know if you've noticed, but I try to encourage other people to
   make their own version of _my_ "official" tree, and unlike pretty much
   all other open source projects I'm aware of, the Linux kernel
   development model has always encouraged things like the "Alan Cox" tree
   or "Andrew Morton" tree or "Andrea Arcangeli" tree. Or all the vendor 
   trees.

   Many other projects try to control "the one true tree". Linux never 
   really did, and for the last several years it's been a conscious
   decision for me to _encourage_ people to do their own trees. Exactly 
   because I don't want people to think that there are any really official
   trees. My tree perhaps comes closest, but even I don't expect to be the 
   "final word on Linux".

   This keeps us all honest.

Second, and less fundamentally:

 - Even if we had "official maintainers" (and at any one time, certain 
   sub-areas certainly tend to have pretty strong maintainership), those 
   maintainers tend to have pretty fluid trees of their own, and they
   change pretty dynamically.

   Look at how trees are merged, and you'll notice that several 
   maintainers did a special "merge these things for 2.6.9" tree that
   contained the stuff that they wanted to push out quickly, and that I
   merged for just that release. It was basically a "throw-away" tree that
   got used once.

   This happens all the time, and again, I _like_ it. It means that people 
   can react a lot more dynamically to what is going on. Again, having a 
   documented "list of trees" would not make this kind of thing
   technically impossible, but it would foster the wrong kind of "mental
   landscape".

See what I'm saying? It all boils down to the fact that I really like 
having a dynamic development model, and that I want to try to avoid 
putting in mental road-blocks to that model. I want Linux development to 
be fluid, and I think the best way to reach that goal is to make people 
_think_ of it as being fluid.

It's the old "perception changes reality" thing. It's really true. How you 
think about something quite heavily influences what you do.

Wow. That was deep. Time to go watch TV again.

		Linus

Re: BK kernel workflow

[Linus Torvalds]

On Sun, 24 Oct 2004, Linus Torvalds wrote:
> 
>    So BK helps this model, because the distributed nature of BK means that 
>    you can have several pseudo-official trees _and_ totally unofficial
>    ones, and merging is automatic and basically impossible to avoid, so 
>    the "official" tree never gets to drown out the unofficial work. But 
>    despite that, I want to make people _aware_ that maintainership does
>    not imply total ownership, and that we don't have a "hierarchy" of 
>    developers but a *network* of developers.

Btw, I've tried in the past to express why I think the BK model is so
good, and why CVS ans Subversion totally suck, and I think the previous
email perhaps explains it best.

It really is a very important conceptual thing, that "network" vs 
"hierarchy" difference.  And I know we all love bashing Larry, but give 
the guy a pat on the back for really making that difference visible.

[ Larry removed from the cc, because he's got ego enough as it is ;]

		Linus

Re: BK kernel workflow

[Michael Buesch]

Quoting Linus Torvalds <torvalds@osdl.org>:
> 
> On Sun, 24 Oct 2004, Linus Torvalds wrote:
> > 
> >    So BK helps this model, because the distributed nature of BK means that 
> >    you can have several pseudo-official trees _and_ totally unofficial
> >    ones, and merging is automatic and basically impossible to avoid, so 
> >    the "official" tree never gets to drown out the unofficial work. But 
> >    despite that, I want to make people _aware_ that maintainership does
> >    not imply total ownership, and that we don't have a "hierarchy" of 
> >    developers but a *network* of developers.
> 
> Btw, I've tried in the past to express why I think the BK model is so
> good, and why CVS ans Subversion totally suck, and I think the previous
> email perhaps explains it best.

What do kernel developers think about svk?
(Yes, it's not mature, yet.)
I mean the svk concept. Does it also suck for kernel development?

> It really is a very important conceptual thing, that "network" vs 
> "hierarchy" difference.  And I know we all love bashing Larry, but give 
> the guy a pat on the back for really making that difference visible.
> 
> [ Larry removed from the cc, because he's got ego enough as it is ;]

;)

>   Linus

Michael.

Re: BK kernel workflow

[Matthias Urlichs]

Hi, Michael Buesch wrote:

> What do kernel developers think about svk?
> (Yes, it's not mature, yet.)
> I mean the svk concept. Does it also suck for kernel development?

The basic idea seems to be "We need feature X. We have a system that's
mostly nice, but it cannot do X. Thus, graft a system to do X onto it.
Voila, one SCM which can do everything we need". Experience suggests
that if you do that, you end up with an ugly mess.

One reason why svk won't work for Linux is this:

A true peer-to-peer system requires that both branches are treated equal.
Bitkeeper got that one exactly right: if I have two repositories A and B,
then importing A to B is the same thing as importing B to A. SVN can't do
that, thus svk can't do it either.

There are others.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: BK kernel workflow

[Roman Zippel]

Hi,

On Sun, 24 Oct 2004, Linus Torvalds wrote:

>  - I do _not_ want people to "own" subsystems. And that's not so much an 
>    anti-maintainer issue (I _love_ maintainers), as more of a "conceptual" 
>    issue. When people expect one person or one group of person to be the 
>    only way to touch a certain subsystem, we have problems. I really 
>    really want everybody (users, developers _and_ maintainers) to realize 
>    that no code is an island, and work with other people touching their 
>    subsystem.

OTOH people often just send patches directly to you without bothering to 
contact the maintainer. There is no system that sends out notifications, 
if a patch touches file x/y, so that one has a chance to comment on them.
To be very clear on this, I don't want to control what goes in, I'd just 
like to know about changes _before_ they go in.

>    So BK helps this model, because the distributed nature of BK means that 
>    you can have several pseudo-official trees _and_ totally unofficial
>    ones, and merging is automatic and basically impossible to avoid, so 
>    the "official" tree never gets to drown out the unofficial work. But 
>    despite that, I want to make people _aware_ that maintainership does
>    not imply total ownership, and that we don't have a "hierarchy" of 
>    developers but a *network* of developers.

One should also add that bk is not the answer to everything, e.g. bk 
doesn't really help with maintaining separate patches. As one cannot 
remove or change information from/in bk, that makes it difficult to 
work on a series of patches, e.g. as Andrew does with -mm, a tool like 
quilt is more helpful here.
This means patches should only be put into bk, when they are ready 
(otherwise the repo accumulates useless info nobody is really interested 
in), during their development bk is about as useful as any other SCM 
system. bk simplifies mainly your work, but the further one is away from 
the core of this developer network, the more bk looses its advantage 
(and might only increase the amount of merge information bk has to 
manage in relation to patch information).

bye, Roman

Re: BK kernel workflow

[Linus Torvalds]

On Mon, 25 Oct 2004, Roman Zippel wrote:
> 
> OTOH people often just send patches directly to you without bothering to 
> contact the maintainer.

And sometimes that ends up being becaue the maintainer is unresposive. 

It happens. I'd much rather make that be the _normal_ flow of events than 
have people think that it's something horrible.

>			 There is no system that sends out notifications, 
> if a patch touches file x/y, so that one has a chance to comment on them.

Well, these days there actually _is_. No, it's not per-file, but a 
procmail filter on the patch bots will actually do a lot better than some 
random "notify me on these files", because it can be personalized any 
which way you want..

> One should also add that bk is not the answer to everything, e.g. bk 
> doesn't really help with maintaining separate patches.

Yes. I think the -mm tree and Andrew's (and other peoples) patch-
maintenance ends up being another part of the workflow, "outside" the BK
trees, exactly because of that.

		Linus

Re: BK kernel workflow

[Greg KH]

On Tue, Oct 19, 2004 at 11:54:16PM +0200, Paolo Ciarrocchi wrote:
> I know I'm pedantic but can we all see the list of bk trees ("patches
> ready for mainstream" and "patches eventually ready for mainstream")
> that we'll be used by Linus ?

The -mm releases has these as a big patch, starting with bk-*

Those should give you an idea of what is being staged, before it is sent
to Linus.

thanks,

greg k-h

Re: BK kernel workflow

[Matthias Urlichs]

Hi, Greg KH wrote:

> On Tue, Oct 19, 2004 at 11:54:16PM +0200, Paolo Ciarrocchi wrote:
>> I know I'm pedantic but can we all see the list of bk trees ("patches
>> ready for mainstream" and "patches eventually ready for mainstream")
>> that we'll be used by Linus ?
> 
> The -mm releases has these as a big patch, starting with bk-*

Umm, yeah, but it's *one* big patch (or, if you use my -mm import tree
from bk://smurf.bkbits.net/linux-2.6.X-rcY-mmZ, one BK pull which has
that as a subtree).

Paolo wants to see two distinct ones.

Andrew also does things like

bk-netdev.patch
e1000-module_param-fix.patch
ne2k-pci-pci-build-fix.patch
r8169-module_param-fix.patch

which my mind translates as "there's something stupid, incomplete or
outdated in the bk-netdev tree", or "that tree's maintainer should apply
these patches. Now." (Ideally, of course, my import script should do the
same thing.)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: BK kernel workflow

[Paolo Ciarrocchi]

On Mon, 25 Oct 2004 15:01:50 +0200, Matthias Urlichs
<smurf@smurf.noris.de> wrote:
[...]
> Paolo wants to see two distinct ones.

Yes, 
Paolo thinks that is a good idea.

But Linus already answered to my concerns ;)
-- 
Paolo
Personal home page: www.ciarrocchi.tk

Re: BK kernel workflow

[Jeff Garzik]

Matthias Urlichs wrote:
> Andrew also does things like
> 
> bk-netdev.patch
> e1000-module_param-fix.patch
> ne2k-pci-pci-build-fix.patch
> r8169-module_param-fix.patch
> 
> which my mind translates as "there's something stupid, incomplete or
> outdated in the bk-netdev tree", or "that tree's maintainer should apply
> these patches. Now." (Ideally, of course, my import script should do the
> same thing.)

Wrong on all counts.

The right answer is, "bk-netdev conflicts with some other BK tree that's 
also not yet in upstream"

	Jeff

Re: BK kernel workflow

[Matthias Urlichs]

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

Hi,

Jeff Garzik:
> Wrong on all counts.
> 
I stand corrected.

> The right answer is, "bk-netdev conflicts with some other BK tree that's 
> also not yet in upstream"
> 
That sounds somewhat painful.

Personally I'd do the BK tree integration in a somewhat more
Bitkeeper-ish way, but that's (obviously) Andrew's call.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

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

Re: BK kernel workflow

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> Matthias Urlichs wrote:
> > Andrew also does things like
> > 
> > bk-netdev.patch
> > e1000-module_param-fix.patch
> > ne2k-pci-pci-build-fix.patch
> > r8169-module_param-fix.patch
> > 
> > which my mind translates as "there's something stupid, incomplete or
> > outdated in the bk-netdev tree", or "that tree's maintainer should apply
> > these patches. Now." (Ideally, of course, my import script should do the
> > same thing.)
> 
> Wrong on all counts.

"wrong" became "right".  Those patches need to be applied now.  I'll resend them.

But Matthias has described the algorithm correctly: I try to keep "fixups"
as close as possible to the patches which they fix.

I also try to keep patches in when-to-go-to-linus order, but that's much
harder to achieve, for various reasons.

Re: BK kernel workflow

[maximilian attems]

> 3) merge the patch into the topic-specific repo, using Linus's patch 
> importing tools,
> 
>         cd 8139too && dotest < /garz/nsmail/25_Patches

where are those tools available?

they are the missing chain in Andrew's patch-scripts.



--
maks
kernel janitor  	http://janitor.kernelnewbies.org/

Re: BK kernel workflow

[Jeff Garzik]

maximilian attems wrote:
>>3) merge the patch into the topic-specific repo, using Linus's patch 
>>importing tools,
>>
>>        cd 8139too && dotest < /garz/nsmail/25_Patches
> 
> 
> where are those tools available?
> 
> they are the missing chain in Andrew's patch-scripts.


http://bktools.bkbits.net/

	Jeff

Re: BK kernel workflow

[Chuck Ebbert]

Larry McVoy wrote:

> we're working bug database integration, we're working
> on review queues, we're working on project management, we're working on
> large binary management, etc.

  How about support for backporting patches, e.g. backport csets
1.2000.4.120 and 1.2000.12.16 to kernel 2.6.9?  I could see no way to get
bk to spit out these two changes as patches against 2.6.9.  Given all the info
in there this should be trivial...

  But first you should write some actual documentation and fix your programs
so they emit error messages when something goes wrong:

[me@d4 linux-2.6]$ bk c2r -r@v2.6.9 mm/vmscan.c
[me@d4 linux-2.6]$                                               <--- what???
[me@d4 linux-2.6]$ bk tags
<snip>
ChangeSet@1.1988.97.17, 2004-10-18 11:50:06-07:00, torvalds@ppc970.osdl.org
  Linux 2.6.9
  TAG: v2.6.9
<snip>
[me@d4 linux-2.6]$ bk c2r -r1.1988.97.17 mm/vmscan.c
1.231

  'bk help terms' says a tag can be used, but apparently not and there's
no error message.

  Then there's this one:

[me@d4 linux-2.6]$ bk difftool -rv2.6.8 -rv2.6.9 mm/vmscan.c     <--- forgot the @
child process exited abnormally                                  <--- hee hee!

  I like the way the GUI flashes up on the screen then abruptly disappears, leaving
the user wondering what happened.


> The list goes on, if anyone wants to come work on it we are always looking
> for good systems people and we pay well.

  But you're located in a large American metro area, a.k.a. "hell on earth."


--Chuck Ebbert  26-Oct-04  03:19:25

Re: BK kernel workflow

[Larry McVoy]

On Tue, Oct 26, 2004 at 03:38:06AM -0400, Chuck Ebbert wrote:
> Larry McVoy wrote:
> 
> > we're working bug database integration, we're working
> > on review queues, we're working on project management, we're working on
> > large binary management, etc.
> 
>   How about support for backporting patches, e.g. backport csets
> 1.2000.4.120 and 1.2000.12.16 to kernel 2.6.9?  I could see no way to get
> bk to spit out these two changes as patches against 2.6.9.  Given all the info
> in there this should be trivial...

Trivial?  Sure, if the patches apply cleanly.  Not trivial if the changesets
have other changesets in the way.

But I have a 70 line shell script which does this, I'm not sure why you can't
write the same thing.

>   But first you should write some actual documentation and fix your programs
> so they emit error messages when something goes wrong:
> 
> [me@d4 linux-2.6]$ bk c2r -r@v2.6.9 mm/vmscan.c
> [me@d4 linux-2.6]$                                               <--- what???

That's because you didn't read the documentation which you appear to love 
so much.

work /tmp/linux-2.5 bk c2r -rv2.6.9 mm/vmscan.c
1.231

>   'bk help terms' says a tag can be used, but apparently not and there's
> no error message.

You passed a legal rev syntax to the command.  I can't help it if you don't
understand the tool.

>   Then there's this one:
> 
> [me@d4 linux-2.6]$ bk difftool -rv2.6.8 -rv2.6.9 mm/vmscan.c     <--- forgot the @
> child process exited abnormally                                  <--- hee hee!
> 
>   I like the way the GUI flashes up on the screen then abruptly disappears, leaving
> the user wondering what happened.

You know, I like the way you politely offer to help out by sending in
patches to the documentation for this tool which you get to use for free.
You are an inspiration to us and you are just the sort of user we love
to help.

> > The list goes on, if anyone wants to come work on it we are always looking
> > for good systems people and we pay well.
> 
>   But you're located in a large American metro area, a.k.a. "hell on earth."

No worries, Chuck, after careful consideration of your skills we don't see
a match at this time.  But we'll keep your resume on file and thanks for
your interest.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Ryan Anderson]

On Tue, Oct 26, 2004 at 07:23:21AM -0700, Larry McVoy wrote:
> That's because you didn't read the documentation which you appear to love 
> so much.

Well, Larry, to be perfectly honest - the documentation is ... terse, at
the moment.

Yes, I know, documentation isn't fun - it probably needs an editor to
go over it and say, "What assumptions should we make about the knowledge
a user has?" and then try really hard to keep that list *short* and
strictly adhered to in all the pages.

Oh, and I *do* play a paying customer at my day job.  Just some days I
wish the documentation was a little more helpful.  (Specifically, you
desperately need more examples of triggers.)

-- 

Ryan Anderson
  sometimes Pug Majere

Re: BK kernel workflow

[Larry McVoy]

On Tue, Oct 26, 2004 at 02:16:22PM -0400, Ryan Anderson wrote:
> On Tue, Oct 26, 2004 at 07:23:21AM -0700, Larry McVoy wrote:
> > That's because you didn't read the documentation which you appear to love 
> > so much.
> 
> Well, Larry, to be perfectly honest - the documentation is ... terse, at
> the moment.

Yes, we know.  On the other hand, we're probably pushing 60,000 users or
so who have figured it out by tinkering with the tool.  There is no 
question that there needs to be a BitKeeper book or at least a much more
expanded and updated userguide.

> Yes, I know, documentation isn't fun - it probably needs an editor to
> go over it and say, "What assumptions should we make about the knowledge
> a user has?" and then try really hard to keep that list *short* and
> strictly adhered to in all the pages.

Yup.  We have an open req for a docs person, if you know someone who
wants a fulltime job in the Bay Area or an incredibly exceptional remote
person we're very interested (and I'll shut up about that, I'm not trying
to use the list for free job advertising, just don't want to create the
impression that we don't recognize the issues).

> Oh, and I *do* play a paying customer at my day job.  Just some days I
> wish the documentation was a little more helpful.  (Specifically, you
> desperately need more examples of triggers.)

Well if you are paying your support includes that sort of help.  Call
us up and ask for examples or send mail to support and ask for help.
Even if you aren't paying you can always ask, if we can we help people
out promptly.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[Chuck Ebbert]

Larry McVoy wrote:

> But I have a 70 line shell script which does this, I'm not sure why you can't
> write the same thing.

  Shirley you jest.


>> [me@d4 linux-2.6]$ bk c2r -r@v2.6.9 mm/vmscan.c
>> [me@d4 linux-2.6]$                                               <--- what???
>
> That's because you didn't read the documentation which you appear to love 
> so much.

  So now it's MY fault I didn't get any kind of error message whatsoever?
Silent failures like this are really, really annoying...


>>   Then there's this one:
>> 
>> [me@d4 linux-2.6]$ bk difftool -rv2.6.8 -rv2.6.9 mm/vmscan.c     <--- forgot the @
>> child process exited abnormally                                  <--- hee hee!
>> 
>>   I like the way the GUI flashes up on the screen then abruptly disappears, leaving
>> the user wondering what happened.
>
> You know, I like the way you politely offer to help out by sending in
> patches to the documentation for this tool which you get to use for free.

  Are you deliberately missing my point?

  Programs should return some kind of error message when they fail.  Is that
so hard to understand?


>>   But you're located in a large American metro area, a.k.a. "hell on earth."
>
> No worries, Chuck, after careful consideration of your skills we don't see
> a match at this time.  But we'll keep your resume on file and thanks for
> your interest.

  Your loss, not mine.


--Chuck Ebbert  26-Oct-04  11:16:10

Re: BK kernel workflow

[Larry McVoy]

On Tue, Oct 26, 2004 at 11:54:46AM -0400, Chuck Ebbert wrote:
>   Shirley you jest.

Chuck, if you really want to talk about this let's take it off line,
the rest of the kernel list doesn't need to know your opinion of our
docs or tools.  Last I heard, they were pretty sick of any sort of BK
discussion that wasn't focussed on solving kernel problems.

For the rest of you, if you want something fixed in BK a few ways
to get that done: file a bug|rfe with "bk sendbug", ask questions on
bitkeeper-users at bitmover.com list, and/or send mail to support at
bitmover.

It's probably obvious but bears repeating: polite people tend to
get better support than impolite people, just something to consider.
It's not our policy to distinguish, we fix bugs regardless of how they
are reported, but if you are more or less asking us to do some work for
you we'll put the nice people at the head of the list, that's just
human nature.  FYI.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: BK kernel workflow

[walt]

On Sat, 30 Oct 2004, Adrian Bunk wrote:

> On Thu, Oct 28, 2004 at 02:35:34PM -0700, Larry McVoy wrote:
> > > Note that German copyright lay doesn't differentiate whether you paid
> > > or not - it only requires that you allowed to use the program.
> >
> > Sure, but you aren't allowed to use it if you are going to do this.
> > That's pretty unambiguous as well and we think we can make it stick,
> > or at least that's what the lawyers have told me.
> >...
>
> The German copyright law says the licence clauses are invalid - not the
> licence itself.
>
> I'm not sure how a lawyer would circumvent the law...

It can't be difficult -- most lawyers do it every day.