RE: The direction linux is taking

RE: The direction linux is taking

[Dana Lacoste]

Mostly playing devil's advocate here :)

> Merging is much easier.

how exactly?  the actual merge is done
from a patch which if it isn't cleanly
applied then it's probably not wanted
anyways :)

(on the other hand SCM makes it MUCH easier
to deal with the 'cleanly applied' part :)

> Tracking of patches is much easier.

not really : how do you make sure that all the
correct patches have been applied?  All SCM
lets you gain is knowing what patches have
been applied, not what patches were NOT applied.

> Access control is much easier.

but if it's only Linus, then this is a moot point :)

> > (If, on the other hand, we allowed multiple committers
> > and access-controlled maintainer lists, then SCM would
> > be beautiful!  but this isn't FreeBSD :) :) :) :) :)

> Actually, BK can definitely do that.

I HOPE SO!  it's kinda the whole basic essential component for
any multi-user SCM system!  The problem isn't that BK can't,
but that Linus won't :) :) :)

> In fact, that's basically exactly what
> we have on the hosting service for the PPC tree.  There are a 
> list of people
> who are administrators, a list of committers, as well as read 
> only access.
> The admins are also committers if they want to be, the admins 
> also get to
> control who is and is not a committer.

which is pretty much what FreeBSD (for example) does.
of course they're using CVS (and we won't go there :)

> And you dream up as complicated an access control model as 
> you want.  We
> can do pretty much any model you can describe.  Try me, 
> describe a work
> flow that you think would be useful, I'll write up how to do 
> it and stick
> it on a web page and you can throw stones at it and see if it breaks.

ok, i have to go learn bitkeeper now so i can answer this
intelligently, but i'll give some examples from perforce
(which is what i'm using now :) 

Common task 1 : usability
perforce tracks what everyone has.  this means that if you want
to do a sync to current, it only gives you what's changed since
your last sync, because it knows, and you didn't do anything
without telling it, right?

well, what if i'm working on 2.5 stuff for my magical danaDriver?
It's really intense, has a lot of files all over the place, and I
don't want to hurt anything.  Then someone asks me about the
interaction between danaDriver and reiserFS in 2.4.17 and I want
to make sure I can see exactly what they're talking about.

so what i want to do (and i can't do in perforce, well, not easily)
is to make a clean checkout of the last 'official release' of the
whole project from SCM _without_ affecting my workspace.

i.e. i do NOT want to create a new workspace, i do not want to create
a special directory, i just want to do :
	mkdir linux
	cvs checkout linux -tag 2.4.17
and get the whole linux-2.4.17 source code, without affecting my working
directory 'linux-2.5' which also has the linux/* (main)branch checked out.

In perforce, for example, I have to :
(yes, with branches this can be done MUCH easier, but i'm trying to
prove a point here :)
1 - make a new client spec.  although this is effectively a plaintext file
    and can be automated with scripts, it's really dumb that i have to do
    this.
2 - set my environment variables to use this new client spec.
3 - run a p4 sync -tag 2.4.17 (the server says "hey, there's no files
there!"
    and checks out the whole thing for me)
4 - change my environment variables back and go on working in 2.5
danaDriver.
    essentially having 2 workspaces, with the environment variable the diff
    between them.

of course there's no .CVS directories here, as perforce doesn't use them,
so the checkout is 'clean' :)

Common Task 2 : Accountability

This is something perforce does REALLY well.
I can do this :
- set it up so anyone can submit a change request [patch] but it has
  to be approved by the directory/file's owner first.  if it's not
  approved, it can't be submitted.
  this means that ANYONE can submit a patch, and everyone gets to
  participate, and accountability is maintained.
- set it up so that interested parties get notified of every change
  that is submitted, including a web link to the full diffs of that
  change.  notification is file/directory based, and can have 'excludes'
  so rik can get notified every time 'virtualmemory.c' is changed so
  that way he can start flaming andrea right away :) :) :) :) :)

Can you do these things with bitkeeper?  (yeah, i'll go read the website
info :)

Dana Lacoste
Ottawa, Canada

BK stuff [was Re: The direction linux is taking]

[Larry McVoy]

My apologies to the list if this is considered off topic.  I changed the 
subject so you can kill this thread if you like.  I know how popular BK
discussions are :-)

On Thu, Dec 27, 2001 at 01:24:27PM -0800, Dana Lacoste wrote:
> Mostly playing devil's advocate here :)
> 
> > Merging is much easier.
> 
> how exactly?  

It's probably an off topic conversation, but in the interesting case (i.e.,
it won't patch cleanly), both text based and GUI based tools are available
to help with the merge.  They are better than anything you're used to or
I'll eat my hat.  For example, if you are a CVS user, you are used to this:

    <<<<<<< local slib.c 1.645
                  sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                  assert(HASGRAPH(sc));
                  sccs_sdelta(sc, sccs_ino(sc), file);
    <<<<<<< remote slib.c 1.642.2.1
                  sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                  assert(sc->tree);
                  sccs_sdelta(sc, sc->tree, file);
    >>>>>>>

but we can give you this:

    <<<<<<< local slib.c 1.642.1.6 vs 1.645
                  sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
    -             assert(sc->tree);
    -             sccs_sdelta(sc, sc->tree, file);
    +             assert(HASGRAPH(sc));
    +             sccs_sdelta(sc, sccs_ino(sc), file);
    <<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1
    -             sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
    +             sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                  assert(sc->tree);
                  sccs_sdelta(sc, sc->tree, file);
    >>>>>>>

Why is that better?  It's essentially two inline context diffs, so you can
see what each side did.  Much easier to merge when you can tell what is 
going on.

The GUI tools give you the second style as well as some extra windows
so you can see the checkin comments associated with both the deleted and
the added lines, which gives you yet more information.

> (on the other hand SCM makes it MUCH easier
> to deal with the 'cleanly applied' part :)
> 
> > Tracking of patches is much easier.
> 
> not really : how do you make sure that all the
> correct patches have been applied?  All SCM
> lets you gain is knowing what patches have
> been applied, not what patches were NOT applied.

You're assuming the common denominator of SCM systems.  That's not BK.
The easiest way to see if your patch is in Linus's BK tree is this:

	bk push -nl bk://bk.kernel.org/released

That will list everything in your tree which is not in his tree.  There are
other ways to do it as well, but you get the idea.

> > Access control is much easier.
> 
> but if it's only Linus, then this is a moot point :)

But it isn't only Linus.  Again, you are assuming a CVS/Perforce/etc style
SCM system.  BK isn't like that.  Each workspace is a repository and you
can move data between them in any way that you want.  That's the whole
point, you can put staging areas between Linus and the unwashed masses.
And if the structure you come up with turns out to be wrong, hey, no
worries, just change it.  BK does the right thing.

> ok, i have to go learn bitkeeper now so i can answer this
> intelligently, but i'll give some examples from perforce

I strongly urge you to go to www.bitkeeper.com, click on Test Drive,
download BK, and try it.  It walks you through all the basics as well
as a merge, demo-ing the GUI file merge.

> Common task 1 : usability
> perforce tracks what everyone has.  this means that if you want
> to do a sync to current, it only gives you what's changed since
> your last sync, because it knows, and you didn't do anything
> without telling it, right?

Right.

> well, what if i'm working on 2.5 stuff for my magical danaDriver?
> It's really intense, has a lot of files all over the place, and I
> don't want to hurt anything.  Then someone asks me about the
> interaction between danaDriver and reiserFS in 2.4.17 and I want
> to make sure I can see exactly what they're talking about.
> 
> so what i want to do (and i can't do in perforce, well, not easily)
> is to make a clean checkout of the last 'official release' of the
> whole project from SCM _without_ affecting my workspace.
> 
> i.e. i do NOT want to create a new workspace, i do not want to create
> a special directory, i just want to do :
> 	mkdir linux
> 	cvs checkout linux -tag 2.4.17
> and get the whole linux-2.4.17 source code, without affecting my working
> directory 'linux-2.5' which also has the linux/* (main)branch checked out.

Trivial in bk, do a "bk help clone".  And it doesn't have to be a tagged
release either, all changes (aka cvs commits) are reproducible snapshots
of the tree.  It's like you followed every cvs commit with a cvs tag 
except lots lots faster.

> This is something perforce does REALLY well.
> I can do this :
> - set it up so anyone can submit a change request [patch] but it has
>   to be approved by the directory/file's owner first.  if it's not
>   approved, it can't be submitted.

bk help triggers

>   this means that ANYONE can submit a patch, and everyone gets to
>   participate, and accountability is maintained.

Yup.

> - set it up so that interested parties get notified of every change
>   that is submitted, including a web link to the full diffs of that
>   change.  notification is file/directory based, and can have 'excludes'
>   so rik can get notified every time 'virtualmemory.c' is changed so
>   that way he can start flaming andrea right away :) :) :) :) :)

bk help triggers
http://linux.bkbits.net
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

BK scales, Bitmover doesn't [was Re: BK stuff ]

[Troy Benjegerdes]

On Thu, Dec 27, 2001 at 01:39:51PM -0800, Larry McVoy wrote:
> My apologies to the list if this is considered off topic.  I changed the 
> subject so you can kill this thread if you like.  I know how popular BK
> discussions are :-)

(I'm quite sure this is off-topic, but oh well :-/ )

I want to make a note about something that concerns me, and I haven't 
really seen discussed much..

BK is quite nice, and from it's design, could probably scale to haveing 
every linux developer on the planet using the same 'base' linux kernel 
tree with no problem. (Please don't argue with this point, it's not what 
I'm concerned about)

However, the real problem I see is that althought Bitkeeper (the product)  
scales very well, Bitmover (the company) does NOT. Bitmover needs income 
to scale, and I'm worried that if BK takes off for kernel development, 
the demands on Bitmover from kernel developers will far outstrip the 
increase in income they get from 'commercial' developers. If this happens, 
it's only going to end in everyone getting pissed off. 

I can't think of any 'win/win' solutions for this, problem only 
'lose/lose' ones. Is anyone else worried about this, or am I just a 
pessimist? 

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

Re: BK scales, Bitmover doesn't [was Re: BK stuff ]

[Larry McVoy]

On Thu, Dec 27, 2001 at 03:59:56PM -0600, Troy Benjegerdes wrote:
> (I'm quite sure this is off-topic, but oh well :-/ )

Seems like your outgoing mail filter needs some work if you know it's
off topic and you post anyway, but what the hey, it's Christmas.

> However, the real problem I see is that althought Bitkeeper (the product)  
> scales very well, Bitmover (the company) does NOT. Bitmover needs income 
> to scale, and I'm worried that if BK takes off for kernel development, 
> the demands on Bitmover from kernel developers will far outstrip the 
> increase in income they get from 'commercial' developers. If this happens, 
> it's only going to end in everyone getting pissed off. 

This is way off topic.  I could make similar claims about people using
what your company, Monta Vista, does but you don't see me posting in the
kernel list about their layoffs, business practices, etc.  I certainly
could, but it shows no class (not that I've been accused of having lots
of class, but FUD seems too tasteless for me).

Regardless, to put minds at ease, we're fine.  While we would welcome
more revenue (who wouldn't?), we've never had a layoff in our 4 year
history and aren't planning any.  In addition, we've managed to support
you and the PPC team for almost 2 years without it being a problem,
I'm not sure why it should become a problem now.  Oh yeah, tack on MySQL
as well, that's been under BK for longer than Linux/PPC.  Of course, if
you are worried about it, since Monta Vista has gotten so much benefit
out of BK, they could help ensure the continued development by buying
a support contract.  Hint, hint.

What if we do go out of business?  What's wrong with that?  If we go
under, BK reverts to a pure GPL license.  That can't be a problem,
right?

Seems to me it's a win/win.  We either stick around and support it because
the business model is sound, or we go under and you get it like any other
open source product.  Yeah, it's better if we stick around because BK
is pretty complex, but if the open source crowd can handle the kernel,
gcc, X, etc, they can handle the BK source base, so I really don't see
the problem here.  What am I missing?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK scales, Bitmover doesn't [was Re: BK stuff ]

[Troy Benjegerdes]

On Thu, Dec 27, 2001 at 02:23:59PM -0800, Larry McVoy wrote:
> On Thu, Dec 27, 2001 at 03:59:56PM -0600, Troy Benjegerdes wrote:
> > (I'm quite sure this is off-topic, but oh well :-/ )
> 
> Seems like your outgoing mail filter needs some work if you know it's
> off topic and you post anyway, but what the hey, it's Christmas.
> 
> > However, the real problem I see is that althought Bitkeeper (the product)  
> > scales very well, Bitmover (the company) does NOT. Bitmover needs income 
> > to scale, and I'm worried that if BK takes off for kernel development, 
> > the demands on Bitmover from kernel developers will far outstrip the 
> > increase in income they get from 'commercial' developers. If this happens, 
> > it's only going to end in everyone getting pissed off. 
> 
> This is way off topic.  I could make similar claims about people using
> what your company, Monta Vista, does but you don't see me posting in the
> kernel list about their layoffs, business practices, etc.  I certainly
> could, but it shows no class (not that I've been accused of having lots
> of class, but FUD seems too tasteless for me).

<disclaimer>I am NOT trying to represent MontaVista here in any way.. I'd
have these same issues if I was working for them or not. I really didn't
want to bring MontaVista into this due to previous incidents.</disclaimer>

I suppose you could make similiar claims. However, there is a very
important and subtle difference.  MontaVista is NOT in any position to
tell developers using 'MontaVista' kernels that they must STOP using our
kernel, since it is GPL'ed.

Bitmover, however, is VERY MUCH in a position to tell developers to STOP 
using Bitkeeper. As a matter of fact, it's in your license.

> Regardless, to put minds at ease, we're fine.  While we would welcome
> more revenue (who wouldn't?), we've never had a layoff in our 4 year
> history and aren't planning any.  In addition, we've managed to support
> you and the PPC team for almost 2 years without it being a problem,
> I'm not sure why it should become a problem now.  Oh yeah, tack on MySQL
> as well, that's been under BK for longer than Linux/PPC.  Of course, if
> you are worried about it, since Monta Vista has gotten so much benefit
> out of BK, they could help ensure the continued development by buying
> a support contract.  Hint, hint.
> 
> What if we do go out of business?  What's wrong with that?  If we go
> under, BK reverts to a pure GPL license.  That can't be a problem,
> right?

But potentially not for 6 months, during which time the use of bitkeeper 
is legally dubious, and probably not possible without altering the binary 
(i.e., if openlogging.org goes down), opening up another mess.

> Seems to me it's a win/win.  We either stick around and support it because
> the business model is sound, or we go under and you get it like any other
> open source product.  Yeah, it's better if we stick around because BK
> is pretty complex, but if the open source crowd can handle the kernel,
> gcc, X, etc, they can handle the BK source base, so I really don't see
> the problem here.  What am I missing?

If you don't stick around, OR get unhappy with us using BK, we have a 
problem. Yes, you have some very nice fallbacks, which I thank you for, 
but the fallbacks are still going to cause a great deal of pain.

The real problem is what if you have 300 kernel developers that suddenly 
start costing you support costs of $5,000 a month?

According to the license, that's only 4 months before the 'group of 
licensees' using BK for the kernel cost you $20,000, at which point the 
BKL allows you to cut them off.

If Bitmover ever has to tell someone to quit using BK under the BKL, that, 
IMHO, is a lose/lose situation, for everyone.

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

Re: BK scales, Bitmover doesn't [was Re: BK stuff ]

[Larry McVoy]

[Troy's worries deleted]

Unless someone other than Troy objects, I think this is better handled 
offline.  Troy has some issues that have nothing to do with the kernel
team.  If anyone has any issues with our products, please take them up
with me, the kernel list really doesn't care.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm