BK kernel workflow
Jeff Garzik
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
> On Tue, 19 Oct 2004 12:06:49 -0400, Jeff Garzik <jga...@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.
>
> - 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
Paolo Ciarrocchi
> On Tue, Oct 19, 2004 at 11:33:40PM +0200, Paolo Ciarrocchi wrote:
> > On Tue, 19 Oct 2004 12:06:49 -0400, Jeff Garzik <jga...@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
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
Greg KH
> 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
Paolo Ciarrocchi
<torv...@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
maximilian attems
> 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/
Jeff Garzik
>>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.
Jeff
Larry McVoy
>
>
> 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
Paolo Ciarrocchi
> 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
Larry McVoy
> On Sat, 23 Oct 2004 09:12:53 -0700, Larry McVoy <l...@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
Paolo Ciarrocchi
> 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
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
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 ;]
Michael Buesch
>
> 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.
Roman Zippel
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
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
Larry McVoy
> 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
Matthias Urlichs
> 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 | sm...@smurf.noris.de
Andrea Arcangeli
> the BK license haters have finally admitted that, [..]
dream on
Joe Perches
> 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.
Matthias Urlichs
> 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 | sm...@smurf.noris.de
-
Andrea Arcangeli
> 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.
Paolo Ciarrocchi
<sm...@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
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
Larry McVoy
> 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
Jeff Garzik
> 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
Matthias Urlichs
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.
Andrea Arcangeli
> The implication that Andrew doesn't use BK is incorrect, we see him in
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.
Larry McVoy
> 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
Andrea Arcangeli
>
>
> On Mon, 25 Oct 2004, Andrea Arcangeli wrote:
> >
>
> 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.
Andrea Arcangeli
> We think that that is not true and you yourself prove our point. 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.
Andrea Arcangeli
> 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.
Jon Smirl
> 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
jons...@gmail.com
Matthias Urlichs
> 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 | sm...@smurf.noris.de
-
Jeff Garzik
> 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
Andrew Morton
>
> 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.
Larry McVoy
> On Mon, 25 Oct 2004 09:20:22 -0700, Larry McVoy <l...@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
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
Andrea Arcangeli
> 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).
Larry McVoy
> 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
Chris Wedgwood
> 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.
Miles Bader
>> 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
Miles Bader
> 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
Jon Smirl
> 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
jons...@gmail.com
Miles Bader
> 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."
Matthias Urlichs
> 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 | sm...@smurf.noris.de
-
Matthias Urlichs
> 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.
Chuck Ebbert
> 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 -...@v2.6.9 mm/vmscan.c
[me@d4 linux-2.6]$ <--- what???
[me@d4 linux-2.6]$ bk tags
<snip>
Chan...@1.1988.97.17, 2004-10-18 11:50:06-07:00, torv...@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
Giuseppe Bilotta
> 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)
Larry McVoy
> 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 -...@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
Chuck Ebbert
> 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 -...@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
Ryan Anderson
> 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
Larry McVoy
> 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
Larry McVoy
> 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
Roman Zippel
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
Roman Zippel
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
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
Larry McVoy
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
Larry McVoy
> 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
Matthias Urlichs
> 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 | sm...@smurf.noris.de
-
Buddy Lucas
> 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
Joe Perches
> 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.
Roman Zippel
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
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
Alan Cox
> 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
Larry McVoy
> 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.
Theodore Ts'o
>
> 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.
> 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
Roman Zippel
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
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
Roman Zippel
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
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
Larry McVoy
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
James Bruce
>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.)
Geert Uytterhoeven
> 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 -- ge...@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
Larry McVoy
> 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
Xavier Bestel
> 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
Larry McVoy
> 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
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
Kevin P. Fleming
> 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.
Adrian Bunk
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-----
Alan Cox
> 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
Alan Cox
> "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
Roman Zippel
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
Larry McVoy
> 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
Eric Mudama
<zip...@linux-m68k.org> wrote:
[munch]
> CVS by itself can't of course represent this history
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
Larry McVoy
> [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
Roman Zippel
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
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
David S. Miller
"David Schwartz" <dav...@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.
David Schwartz
> > 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
Manu Abraham
> On Thu, Oct 28, 2004 at 11:03:42PM +0200, Roman Zippel wrote:
> > [complaints about the awful horrible evil BK2CVS tool]
>
> You
>
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
Scott Lockwood
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.
Xavier Bestel
> 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
Roman Zippel
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
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
Scott Lockwood
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.
-
Ramón Rey Vicente
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 rrey...@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-----
Valdis.K...@vt.edu
> 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.
Larry McVoy
> 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