Re: [PATCH] Remove Bitkeeper documentation from Linux tree

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> Daniel Phillips wrote:
> > On Sunday 21 April 2002 18:57, Jeff Garzik wrote:
> > > On Sat, Apr 20, 2002 at 06:46:11PM +0200, Daniel Phillips wrote:
> > > > Let's pull back a little from the proselytizing, shall we?  I'll modify
> > > > my proposal to 'include just a pointer to the bk documentation in the
> > > > kernel tree itself'.  This should satisfy everybody.
> > > 
> > > No, it doesn't.  It was put into the tree for convenience.
> > 
> > How much less convenient is it to click on a link?  So much harder that it's
> > worth pissing off some key developers?
> 
> Linus has already explained why he put it into the kernel sources.

So far the only argument I've seen is: it's convenient.  Did I miss something?

The convenience argument is bogus.  A url is just as convenient, especially as
Larry has offered an appropriate home, one which will by definition continue
to exist as long as Bitkeeper stays alive.  Plus, the url saves download
bandwidth.  A compelling argument I'd say.

> And, who are these key developers you are speaking for?

They can introduce themselves if they wish.  Or you can ask around.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

> I am asking.  My previous post was asking.  Who are you speaking for?

"Answer zee question, old man!"

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 19:55, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > > Daniel Phillips wrote:
> > > > How much less convenient is it to click on a link?  So much harder that it's
> > > > worth pissing off some key developers?
> 
> > > Linus has already explained why he put it into the kernel sources.
> 
> > So far the only argument I've seen is: it's convenient.  Did I miss something? 
> > The convenience argument is bogus.  A url is just as convenient,
>
> If you say this, then you either missed, or are willfully ignoring,
> what Linus said.  Search for the string "helsinki.fi".

Linus said:

> As to why the docs are in the kernel sources rather than on any web-sites:
> it's simply because I don't even _have_ a web page of my own (I've long
> since forgotten the password to my old helsinki.fi account ;),

Larry has offered to host it, so Linus's argument is answered.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 20:08, Larry McVoy wrote:
> On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > Plus, the url saves download
> > bandwidth.  A compelling argument I'd say.
> 
> The docs are all of 12K, I just went and looked.  If you care about
> bandwidth, you'd be arguing in favor of BK, it saves tons of bandwidth
> compared to diff and patch.

All you said is 'it doesn't waste *that* much bandwidth'.  Remember, this is
the place we spend days arguing over a cycle or two.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 20:15, Jeff Garzik wrote:
> On Sat, Apr 20, 2002 at 08:13:48PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 19:55, Jeff Garzik wrote:
> > > On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > > > On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > > > > Daniel Phillips wrote:
> > > > > > How much less convenient is it to click on a link?  So much harder that it's
> > > > > > worth pissing off some key developers?
> > > 
> > > > > Linus has already explained why he put it into the kernel sources.
> > > 
> > > > So far the only argument I've seen is: it's convenient.  Did I miss something? 
> > > > The convenience argument is bogus.  A url is just as convenient,
> > >
> > > If you say this, then you either missed, or are willfully ignoring,
> > > what Linus said.  Search for the string "helsinki.fi".
> > 
> > Linus said:
> > 
> > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > it's simply because I don't even _have_ a web page of my own (I've long
> > > since forgotten the password to my old helsinki.fi account ;),
> > 
> > Larry has offered to host it, so Linus's argument is answered.
> 
> These are docs-about-Linus, not docs-about-Larry.
> 
> Do you propose to move SubmittingPatches and all info related to CVS, to
> Larry's web site?

Which part of 'Larry offered to host it' was not completely clear?

CVS does not have the license issues.  Red herring.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > it's simply because I don't even _have_ a web page of my own (I've long
> > > since forgotten the password to my old helsinki.fi account ;),
> > 
> > Larry has offered to host it, so Linus's argument is answered.
> 
> Larry hereby retracts his offer until you back up your claims and answer
> the questions you have been asked.  You've made one unsubstantiated
> claim after another and when challenged, you tell the challenger to do
> the legwork to support your unsubstantiated claim.

So the offer was not in good faith.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 20:36, Larry McVoy wrote:
> On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > > since forgotten the password to my old helsinki.fi account ;),
> > > > 
> > > > Larry has offered to host it, so Linus's argument is answered.
> > > 
> > > Larry hereby retracts his offer until you back up your claims and answer
> > > the questions you have been asked.  You've made one unsubstantiated
> > > claim after another and when challenged, you tell the challenger to do
> > > the legwork to support your unsubstantiated claim.
> > 
> > So the offer was not in good faith.
> 
> Like I said, Daniel, put up or shut up.  Would you like me to go through
> the thread and come up with a list of claims you have made, been challenged
> on, and refuse to substantiate?

Larry, you just lathered on a bunch of new conditions of dubious merit.  I
understand by this that you had no real intention of following through on
your offer because you thought that it would never get close to becoming
reality.

> We can discuss the good-faith issue *after* you answer the questions.

Riiiiight.  I have at least forwarded your demands to those who have
expressed their positions to me privately.  If you think I'm going to
violate their confidence on your whim, you can think again.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 20:36, Larry McVoy wrote:
> On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> > On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > > since forgotten the password to my old helsinki.fi account ;),
> > > > 
> > > > Larry has offered to host it, so Linus's argument is answered.
> > > 
> > > Larry hereby retracts his offer until you back up your claims and answer
> > > the questions you have been asked.  You've made one unsubstantiated
> > > claim after another and when challenged, you tell the challenger to do
> > > the legwork to support your unsubstantiated claim.
> > 
> > So the offer was not in good faith.
> 
> Like I said, Daniel, put up or shut up.  Would you like me to go through
> the thread and come up with a list of claims you have made, been challenged
> on, and refuse to substantiate?

Yes.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Sunday 21 April 2002 21:06, dean gaudet wrote:
> personally i probably wouldn't be so interested in bk if it weren't for
> all the zealots telling me it's something i shouldn't even consider using.
> your approach is about as effective as the war on drugs, or minimum
> alcohol consumption age limits.  tell what i can't do and i'm damn well
> going to go investigate what it is that's supposedly so bad for me.
> 
> thanks to all of you for pointing me in the direction of a tool which
> looks to be a huge step forward in SCM.  i believe "paradigm shift" would
> be an apt term for bk.

You seem to think I'm against Bitkeeper, or its use, or that I think
Bitkeeper isn't helping linux.  You're wrong.  I am against carrying what
*appears* to be a big advertisement for Bitkeeper itself in the Linux
source tree.  This I see as akin to putting up a commercial billboard in a
public park.  Would you be comfortable with that?

If my comments have caused increased interest in Bitkeeper and spiked up
Larry's downloads, I am glad.  Now everybody is happy except a number of
those whose involvement with Linux is based on some kind of philosophical
belief in the freeness of software (or at least in the freeness of Linux)
and who have been on the butt end of numerous insults in this thread,
your insult above ("zealots") being a good example.

I have suggested carrying a URL instead.  Is it reasonable?  Who is being
extreme here?

Furthermore, who is making the vicious attacks, and why?

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

Daniel Phillips wrote:
> On Sunday 21 April 2002 18:57, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 06:46:11PM +0200, Daniel Phillips wrote:
> > > Let's pull back a little from the proselytizing, shall we?  I'll modify
> > > my proposal to 'include just a pointer to the bk documentation in the
> > > kernel tree itself'.  This should satisfy everybody.
> > 
> > No, it doesn't.  It was put into the tree for convenience.
> 
> How much less convenient is it to click on a link?  So much harder that it's
> worth pissing off some key developers?

Linus has already explained why he put it into the kernel sources.

And, who are these key developers you are speaking for?


> > It therefore stands to reason that removing it creates inconvenience.
> > Further, the only reason to remove it is ideology.  i.e. something
> > other than technical merit.  So your proposal is still a no-go.
> 
> According to you, yes.  I'll leave it on the table.

Linus has already explained he isn't applying your patch.

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Monday 22 April 2002 19:03, Jeff Garzik wrote:
> Let us separate that fact from the notion that it is a BK
> advertisement, and discuss that part, since that seems to be the
> important issue.  As the author of the doc, I state the doc was
> not written as an advertisement, and was not paid for, directly
> or indirectly.
> 
> That said, it certainly can been seen as an advertisement.

OK, we've established that then.

> I like BK, and like to encourage others to use it.
> 
> So let us term the BK doc as, "not intended as an advertisement,
> but can easily be considered such."  I hope we agree so far?  :)
> 
> Now that we have that...
> 
> Q. What is the justification for removing an admittedly-useful
>    advertisement?

  1) It would be equally as useful as a URL
  2) It would not consume download bandwidth
  3) It would show some sensitivity to the concerns of those who are
     uncomfortable with the license.

> There is no dispute that the doc is useful, only dispute with certain
> beliefs.  Disagreement is fine... encouraged, even.  But that's a
> poor justification to remove the doc from the tree.
> 
> I hear your point, I really do.  I just feel very strongly that
> removing the BK docs from the tree is the worst way to go about
> supporting this point of view.

I really don't see how changing out the files for a url qualifies as
the "worst way" of addressing the issue.  If Larry unretracts his offer
to host the files - and I fully expect he will do that after some period
of indulging in his wounded bird act - then by definition the documentation
will always be available exactly when and where needed.  Is there *anybody*
here who'd have further license-related complaints about Bitkeeper if that
were done?  (Speak or forever hold your peace.)

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Monday 22 April 2002 19:30, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> > Is there *anybody*
> > here who'd have further license-related complaints about Bitkeeper if that
> > were done?  (Speak or forever hold your peace.)
> 
> Oh boy oh boy oh boy, if you can deliver a commitment that this is the
> last time we have a BK license-related complaint from a kernel hacker,
> I'll be the first to argue vehemently for that patch you want.
> 
> I'd like to know how you are going to deliver on that offer you just made.

Clearly I'm not going to shut anyone up.  However, only somebody with a very
limited perception of the situation could fail to note that you're being
tested, and what you do next is going to help form attitudes for some time
to come.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > Daniel Phillips wrote:
> > > How much less convenient is it to click on a link?  So much harder that it's
> > > worth pissing off some key developers?

> > Linus has already explained why he put it into the kernel sources.

> So far the only argument I've seen is: it's convenient.  Did I miss something?

> The convenience argument is bogus.  A url is just as convenient,

If you say this, then you either missed, or are willfully ignoring,
what Linus said.  Search for the string "helsinki.fi".


> > And, who are these key developers you are speaking for?
> 
> They can introduce themselves if they wish.  Or you can ask around.

I am asking.  My previous post was asking.  Who are you speaking for?

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Monday 22 April 2002 19:40, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> >   1) It would be equally as useful as a URL
> 
> Maybe 5% less useful or so.  There are reasons we move other
> (non-controversial) docs into the kernel source.  100% of these docs can
> be URLs.
> 
> >   2) It would not consume download bandwidth
> 
> This is a silly argument that dean gaudet dismembered.  It's 12K
> compressed and not your main argument at all.
> 
> 
> >   3) It would show some sensitivity to the concerns of those who are
> >      uncomfortable with the license.
> 
> I agree.
> 
> So, I believe points #1 and #2 are silly, and #3 is your core argument.

I think you stated that #1 is only 5% silly, by implication, 95% unsilly.
Two out of three ain't bad.

> And I agree that it would show sensitivity towards those people who
> dislike the BK license.
> 
> That said, I still think removing the doc is a hideously wrong thing
> to do.

I agree.  (/me listens for sound of garzik hitting floor)  The doc was never
to be removed, it was to be moved.  Read the original mail please.  I repeat:
I *like* your docs, in fact I think they are excellent docs.  I just don't
like to see them sitting in Documentation, for reasons we've been over in
some detail.

> I see the action of BK doc removal as encouraging some strict
> notion of what we can and cannot discuss, inside the kernel sources.
> _That_ is the free speech aspect.
> 
> I see enforcing a strict notion of acceptable speech in the kernel
> sources as a very bad thing for the Linux project.
> 
> I'm not asking you to agree -- but do you even understand my viewpoint here?

I do.  I don't agree with you that any of this has something to do with free 
speech, but I'm willing to accept that you view the kernel source as a kind of
podium.

> > I really don't see how changing out the files for a url qualifies as
> > the "worst way" of addressing the issue.  If Larry unretracts his offer
> > to host the files - and I fully expect he will do that after some period
> > of indulging in his wounded bird act - then by definition the documentation
> > will always be available exactly when and where needed.  Is there *anybody*
> > here who'd have further license-related complaints about Bitkeeper if that
> > were done?  (Speak or forever hold your peace.)
> 
> First, I can host the doc.  And will, if there is justification.
> I do not see a justification.  Larry is irrelevant.

To this discussion?  Debatable.  I'll go with you on that for now though, and
see where it leads.

> Second, I guarantee that license-related complaints about BitKeeper will
> continue to exist, regardless of the doc's location.  Moving the doc
> does absolutely nothing to assauge bad feelings about the BK license.

It would for me, others mileage may vary.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Larry McVoy]

On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> Plus, the url saves download
> bandwidth.  A compelling argument I'd say.

The docs are all of 12K, I just went and looked.  If you care about
bandwidth, you'd be arguing in favor of BK, it saves tons of bandwidth
compared to diff and patch.

In fact, your path to remove them proves that.  If you cared about bandwidth,
you would have posted a BK patch to do it.  :-)
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sat, Apr 20, 2002 at 08:13:48PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 19:55, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 07:48:44PM +0200, Daniel Phillips wrote:
> > > On Sunday 21 April 2002 19:22, Jeff Garzik wrote:
> > > > Daniel Phillips wrote:
> > > > > How much less convenient is it to click on a link?  So much harder that it's
> > > > > worth pissing off some key developers?
> > 
> > > > Linus has already explained why he put it into the kernel sources.
> > 
> > > So far the only argument I've seen is: it's convenient.  Did I miss something? 
> > > The convenience argument is bogus.  A url is just as convenient,
> >
> > If you say this, then you either missed, or are willfully ignoring,
> > what Linus said.  Search for the string "helsinki.fi".
> 
> Linus said:
> 
> > As to why the docs are in the kernel sources rather than on any web-sites:
> > it's simply because I don't even _have_ a web page of my own (I've long
> > since forgotten the password to my old helsinki.fi account ;),
> 
> Larry has offered to host it, so Linus's argument is answered.

These are docs-about-Linus, not docs-about-Larry.

Do you propose to move SubmittingPatches and all info related to CVS, to
Larry's web site?

If not... (see the last line of Linus's first response in this thread)

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Larry McVoy]

> > As to why the docs are in the kernel sources rather than on any web-sites:
> > it's simply because I don't even _have_ a web page of my own (I've long
> > since forgotten the password to my old helsinki.fi account ;),
> 
> Larry has offered to host it, so Linus's argument is answered.

Larry hereby retracts his offer until you back up your claims and answer
the questions you have been asked.  You've made one unsubstantiated
claim after another and when challenged, you tell the challenger to do
the legwork to support your unsubstantiated claim.

If you think I'm going to aid in your silliness, think again.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Larry McVoy]

On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 20:21, Larry McVoy wrote:
> > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > since forgotten the password to my old helsinki.fi account ;),
> > > 
> > > Larry has offered to host it, so Linus's argument is answered.
> > 
> > Larry hereby retracts his offer until you back up your claims and answer
> > the questions you have been asked.  You've made one unsubstantiated
> > claim after another and when challenged, you tell the challenger to do
> > the legwork to support your unsubstantiated claim.
> 
> So the offer was not in good faith.

Like I said, Daniel, put up or shut up.  Would you like me to go through
the thread and come up with a list of claims you have made, been challenged
on, and refuse to substantiate?

We can discuss the good-faith issue *after* you answer the questions.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[yodaiken]

On Sat, Apr 20, 2002 at 08:29:04PM +0200, Daniel Phillips wrote:
> > Larry hereby retracts his offer until you back up your claims and answer
> > the questions you have been asked.  You've made one unsubstantiated
> > claim after another and when challenged, you tell the challenger to do
> > the legwork to support your unsubstantiated claim.
> 
> So the offer was not in good faith.

Daniel: I thought better of you.


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

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sat, Apr 20, 2002 at 08:26:58PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 20:15, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 08:13:48PM +0200, Daniel Phillips wrote:
> > > Linus said:
> > > 
> > > > As to why the docs are in the kernel sources rather than on any web-sites:
> > > > it's simply because I don't even _have_ a web page of my own (I've long
> > > > since forgotten the password to my old helsinki.fi account ;),
> > > 
> > > Larry has offered to host it, so Linus's argument is answered.
> > 
> > These are docs-about-Linus, not docs-about-Larry.
> > 
> > Do you propose to move SubmittingPatches and all info related to CVS, to
> > Larry's web site?
> 
> Which part of 'Larry offered to host it' was not completely clear?
> 
> CVS does not have the license issues.  Red herring.

No, this is, to me, _the_ issue.  And something you keep ignoring.
And proving that you ignored the point of Linus's first post in
this thread.

We have docs describing how kernel developers should merge with Linus.
In your opinion, if those docs describe closed source software,
they should be treated differently than other docs.  Regardless of
relevance.

They _are_ relevant, everyone admits that.  Therefore treating them
differently only introduces additional barriers and violates the
Principle of Least Surprise.

You are, in effect, trying to disallow politically incorrect speech
from the kernel sources.

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[dean gaudet]

On Sat, 20 Apr 2002, Daniel Phillips wrote:

> Riiiiight.  I have at least forwarded your demands to those who have
> expressed their positions to me privately.  If you think I'm going to
> violate their confidence on your whim, you can think again.

so then you're having private discussions in email, and one of your
complaints is about other private discussions in email?


On Sat, 20 Apr 2002, Daniel Phillips wrote:

> All you said is 'it doesn't waste *that* much bandwidth'.  Remember, this is
> the place we spend days arguing over a cycle or two.

this bk thread alone has so far consumed 597023 bytes just for the message
bodies... plus who knows how many bytes for TCP/IP headers, SMTP overhead,
and DNS overhead.  that's uncompressed, and multiplied by the, hmm,
approximately 2000 subscribers to l-k plus the dozen or two web archives
of l-k?

what was that you were saying about wasting bandwidth?  if you cared at
all about bandwidth you might want to consider not replying.

personally i probably wouldn't be so interested in bk if it weren't for
all the zealots telling me it's something i shouldn't even consider using.
your approach is about as effective as the war on drugs, or minimum
alcohol consumption age limits.  tell what i can't do and i'm damn well
going to go investigate what it is that's supposedly so bad for me.

thanks to all of you for pointing me in the direction of a tool which
looks to be a huge step forward in SCM.  i believe "paradigm shift" would
be an apt term for bk.

-dean

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Larry McVoy]

On Sat, Apr 20, 2002 at 08:46:40PM +0200, Daniel Phillips wrote:
> > > > > Larry has offered to host it, so Linus's argument is answered.
> > > > 
> > > > Larry hereby retracts his offer until you back up your claims and answer
> > > > the questions you have been asked.  You've made one unsubstantiated
> > > > claim after another and when challenged, you tell the challenger to do
> > > > the legwork to support your unsubstantiated claim.
> > > 
> > > So the offer was not in good faith.
> > 
> > Like I said, Daniel, put up or shut up.  Would you like me to go through
> > the thread and come up with a list of claims you have made, been challenged
> > on, and refuse to substantiate?
> 
> Larry, you just lathered on a bunch of new conditions of dubious merit.  I
> understand by this that you had no real intention of following through on
> your offer because you thought that it would never get close to becoming
> reality.

Larry hereby retracts his offer until you back up your claims and answer
the questions you have been asked.  You've made one unsubstantiated
claim after another and when challenged, you tell the challenger to do
the legwork to support your unsubstantiated claim.

(follow up again, get the same response, cut and paste is easy).
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Andrew Morton]

dean gaudet wrote:
> 
> On Sat, 20 Apr 2002, Daniel Phillips wrote:
> 
> > Riiiiight.  I have at least forwarded your demands to those who have
> > expressed their positions to me privately.  If you think I'm going to
> > violate their confidence on your whim, you can think again.
> 
> so then you're having private discussions in email, and one of your
> complaints is about other private discussions in email?
> 

The reason why people do not express their disquiet is very plain - any
time anyone dares comes out, they promptly get their head kicked in.

Guys, this problem is permanent, and it's not going away.

Larry has stated that kernel's use of bitkeeper is not providing
collateral sales, and nor was it intended for that.  Fair enough.
But it's inevitable that, in some people's eyes, kernel's very
public use of bitkeeper be viewed as promotion of bitmover's
product, and as endorsement of bitmover's licensing innovations.

Some people don't like this, and never will.  I'm tempted here to
say "get over it".  This disagreement is a permanent part of the
kernel landscape.

Linus took the work of others and used it in a way which they did
not expect, without their permission, and contrary to their wishes.
He knew what he was doing, and he knew that some wouldn't like it.
If he had chosen any other path, he'd be juggling ascii diffs
until the end of time.

My take on Daniel's patch is that it is addressing the symptoms,
not the problem.  And the problem is unsolveable.  The differences
of opinion are irreconcilable.  Both sides are populated by 
perfectly sensible people with perfectly legitimate points of view.

So.  Life goes on.  We will have regular bitkeeper flamewars, and
that's a good thing - it reminds everyone that there are different
opinions and different work practices which need to be accommodated.

Oh.  And the problem of stealth patches is a human one, not a tool
one.  Tree owners should prefer to drop unreviewed patches. Not just
because said patches may have bugs which they miss.  Not just because
having others check the work lightens their workload. Not just because
others may have other, different implementations in the works.  But
also because it keeps everyone informed as to what's going on, and
generally makes for a better development team.

It would help to avoid, say, the situation where random fs maintainer
"A" is amazed to discover one day that a patch from random VFS maintainer
"B" had caused said filesystem to be doing a surprise "up" on a non-downed
semaphore.  Not that this could ever happen.

-

Re: double-standard? (Re: [PATCH] Remove Bitkeeper documentation from Linux tree)

[Daniel Phillips]

On Monday 22 April 2002 22:37, dean gaudet wrote:
> i happen to put food on my table working at a hardware company; larry puts
> food on his working at a software company.  i happen to work at the same
> hardware company as linus does:  transmeta.  every kernel for the past,
> uh, 6 or 7 years, has included an advertisement for transmeta.  could we
> possibly conceive of removing all references to transmeta from the kernel,
> mailing lists and archives?

How big is the Transmeta ad?  Does it have its own file?  Would you be
satisfied if Bitkeeper had the same size advertisement as Transmeta?

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Daniel Phillips]

On Monday 22 April 2002 22:47, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 07:57:55PM +0200, Daniel Phillips wrote:
> > I do.  I don't agree with you that any of this has something to do with free 
> > speech, but I'm willing to accept that you view the kernel source as a kind of
> > podium.
> 
> I conjecture, then, that moving the BK doc to satisfy sensitivies is
> also acknowledge of the kernel sources as a podium :)

More like a monument.  Currently, with a billboard on it.

-- 
Daniel

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Larry McVoy]

On Sun, Apr 21, 2002 at 01:22:37PM -0700, Andrew Morton wrote:
> The reason why people do not express their disquiet is very plain - any
> time anyone dares comes out, they promptly get their head kicked in.

In the "let's be fair" department, it's obvious that there is enough 
head kicking to go around on all sides, right?  No answer needed...

> So.  Life goes on.  We will have regular bitkeeper flamewars, and
> that's a good thing - it reminds everyone that there are different
> opinions and different work practices which need to be accommodated.

If Daniel had started out this thread with

    Hey, I've noticed that the BK patches aren't getting as much review
    or notification on the lk list, is there something we can do about
    that?

He would have gotten a useful answer in a few minutes, and we would have
moved on.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sun, Apr 21, 2002 at 04:53:05PM +0200, Daniel Phillips wrote:
> You seem to think I'm against Bitkeeper, or its use, or that I think
> Bitkeeper isn't helping linux.  You're wrong.  I am against carrying what
> *appears* to be a big advertisement for Bitkeeper itself in the Linux
> source tree.  This I see as akin to putting up a commercial billboard in a
> public park.  Would you be comfortable with that?

No, poor analogy -- the doc has proven useful time and time to kernel
developers.  It's in the kernel source because of that.

Let us separate that fact from the notion that it is a BK
advertisement, and discuss that part, since that seems to be the
important issue.  As the author of the doc, I state the doc was
not written as an advertisement, and was not paid for, directly
or indirectly.

That said, it certainly can been seen as an advertisement.  I like BK,
and like to encourage others to use it.

So let us term the BK doc as, "not intended as an advertisement,
but can easily be considered such."  I hope we agree so far?  :)

Now that we have that...


Q. What is the justification for removing an admittedly-useful
   advertisement?
A. Some people disagree with the author's point of view
   (that POV being, "it's ok to use BK in the open source Linux project")

There is no dispute that the doc is useful, only dispute with certain
beliefs.  Disagreement is fine... encouraged, even.  But that's a
poor justification to remove the doc from the tree.

I hear your point, I really do.  I just feel very strongly that
removing the BK docs from the tree is the worst way to go about
supporting this point of view.

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Larry McVoy]

On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> Is there *anybody*
> here who'd have further license-related complaints about Bitkeeper if that
> were done?  (Speak or forever hold your peace.)

Oh boy oh boy oh boy, if you can deliver a commitment that this is the
last time we have a BK license-related complaint from a kernel hacker,
I'll be the first to argue vehemently for that patch you want.

I'd like to know how you are going to deliver on that offer you just made.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
>   1) It would be equally as useful as a URL

Maybe 5% less useful or so.  There are reasons we move other
(non-controversial) docs into the kernel source.  100% of these docs can
be URLs.

>   2) It would not consume download bandwidth

This is a silly argument that dean gaudet dismembered.  It's 12K
compressed and not your main argument at all.


>   3) It would show some sensitivity to the concerns of those who are
>      uncomfortable with the license.

I agree.

So, I believe points #1 and #2 are silly, and #3 is your core argument.

And I agree that it would show sensitivity towards those people who
dislike the BK license.

That said, I still think removing the doc is a hideously wrong thing
to do.  I see the action of BK doc removal as encouraging some strict
notion of what we can and cannot discuss, inside the kernel sources.
_That_ is the free speech aspect.

I see enforcing a strict notion of acceptable speech in the kernel
sources as a very bad thing for the Linux project.

I'm not asking you to agree -- but do you even understand my viewpoint here?


> > There is no dispute that the doc is useful, only dispute with certain
> > beliefs.  Disagreement is fine... encouraged, even.  But that's a
> > poor justification to remove the doc from the tree.
> > 
> > I hear your point, I really do.  I just feel very strongly that
> > removing the BK docs from the tree is the worst way to go about
> > supporting this point of view.
> 
> I really don't see how changing out the files for a url qualifies as
> the "worst way" of addressing the issue.  If Larry unretracts his offer
> to host the files - and I fully expect he will do that after some period
> of indulging in his wounded bird act - then by definition the documentation
> will always be available exactly when and where needed.  Is there *anybody*
> here who'd have further license-related complaints about Bitkeeper if that
> were done?  (Speak or forever hold your peace.)

First, I can host the doc.  And will, if there is justification.
I do not see a justification.  Larry is irrelevant.

Second, I guarantee that license-related complaints about BitKeeper will
continue to exist, regardless of the doc's location.  Moving the doc
does absolutely nothing to assauge bad feelings about the BK license.

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sun, Apr 21, 2002 at 01:22:37PM -0700, Andrew Morton wrote:
> The reason why people do not express their disquiet is very plain - any
> time anyone dares comes out, they promptly get their head kicked in.

> Guys, this problem is permanent, and it's not going away.

Yeah, it's a problem with religious perspectives at this point, things
can occasionally get ugly :)

I'm really glad you are speaking up, though...


> Larry has stated that kernel's use of bitkeeper is not providing
> collateral sales, and nor was it intended for that.  Fair enough.
> But it's inevitable that, in some people's eyes, kernel's very
> public use of bitkeeper be viewed as promotion of bitmover's
> product, and as endorsement of bitmover's licensing innovations.

Agreed -- but one can also see it just as real life, a compromise
with proven open source productivity gains.  Linus, myself, and
others have repeatedly been saying that we would use a superior free
software tool...

At the end of the day, I think the open source cause is advanced by
this non-open-source tool, because Linux kernel development (or at
least the rate of patch application) is by all measures "faster."

By extension, discouraging use of BitKeeper when it is clearly useful
potentially harms the cause of open source.


> Linus took the work of others and used it in a way which they did
> not expect, without their permission, and contrary to their wishes.
> He knew what he was doing, and he knew that some wouldn't like it.

I think that's a bit unfair :(  All Linus did was add an additional
method of patch transport... the source code is still the same
bitrotten hunk of poo we all know, love, and work on :)


> My take on Daniel's patch is that it is addressing the symptoms,
> not the problem.  And the problem is unsolveable.  The differences
> of opinion are irreconcilable.  Both sides are populated by 
> perfectly sensible people with perfectly legitimate points of view.

Pretty much my conclusion...

	Jeff

double-standard? (Re: [PATCH] Remove Bitkeeper documentation from Linux tree)

[dean gaudet]

On Sun, 21 Apr 2002, Daniel Phillips wrote:

> You seem to think I'm against Bitkeeper, or its use, or that I think
> Bitkeeper isn't helping linux.  You're wrong.  I am against carrying what
> *appears* to be a big advertisement for Bitkeeper itself in the Linux
> source tree.  This I see as akin to putting up a commercial billboard in a
> public park.  Would you be comfortable with that?

part of what i'm reacting to in this debate is what i perceive as a
different set of standards which people apply to software versus, say,
hardware.

linux-kernel (and the kernel itself, and the zillions of websites out
there with supporting documentation) are chock full of "advertisements"
for hardware.  pro and con.  i've made many hardware purchase decisions
based on stuff i read here, and stuff i find when searching for linux
documentation.

maybe someday we'll get scifi technology such as nanotech or replicators
(and "limitless" fusion energy) which can move us into a new economy in
which even open hardware is possible... but that's not the case today --
and i doubt many of you are using anything that could be considered open
hardware... almost certainly nobody is able to build an open hardware
platform with the same performance and quality standards as proprietary
hardware can achieve.

isn't there a bit of a double standard in place here?

i happen to put food on my table working at a hardware company; larry puts
food on his working at a software company.  i happen to work at the same
hardware company as linus does:  transmeta.  every kernel for the past,
uh, 6 or 7 years, has included an advertisement for transmeta.  could we
possibly conceive of removing all references to transmeta from the kernel,
mailing lists and archives?  (oh i know if i go back that far in the
archives there was probably a big uproar when linus changed his email
address :)

-dean

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Jeff Garzik]

On Sun, Apr 21, 2002 at 07:57:55PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:40, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 07:27:37PM +0200, Daniel Phillips wrote:
> > >   1) It would be equally as useful as a URL
> > 
> > Maybe 5% less useful or so.  There are reasons we move other
> > (non-controversial) docs into the kernel source.  100% of these docs can
> > be URLs.
> > 
> > >   2) It would not consume download bandwidth
> > 
> > This is a silly argument that dean gaudet dismembered.  It's 12K
> > compressed and not your main argument at all.
> > 
> > 
> > >   3) It would show some sensitivity to the concerns of those who are
> > >      uncomfortable with the license.
> > 
> > I agree.
> > 
> > So, I believe points #1 and #2 are silly, and #3 is your core argument.
> 
> I think you stated that #1 is only 5% silly, by implication, 95% unsilly.
> Two out of three ain't bad.

I will grant you that :) but clarify:

Making is a URL is no big deal and shouldn't be a point of discussion,
as I think #2 is no big deal and shouldn't be a point of discussion.

The real question, as I understand it, is whether or not the kernel doc
should be in the kernel source or not.  If the answer is 'no', then I
fully support making it a URL, or printing it out the back of
phonebooks, or whatever means of distribution :)

But I am arguing that the answer 'no' has not been justified yet...


> > And I agree that it would show sensitivity towards those people who
> > dislike the BK license.
> > 
> > That said, I still think removing the doc is a hideously wrong thing
> > to do.
> 
> I agree.  (/me listens for sound of garzik hitting floor)  The doc was never
> to be removed, it was to be moved.  Read the original mail please.  I repeat:
> I *like* your docs, in fact I think they are excellent docs.  I just don't
> like to see them sitting in Documentation, for reasons we've been over in
> some detail.

This is really a semantic argument...  I shorten "removing from kernel
sources" as "removing", because (correct me here) we are discussing what
we want to see in the kernel sources, and what we do not want to see in
the kernel sources.

Even without an official web site, the BK doc would live on in kernel
archives if nowhere else.

If it makes things more clear, I can use my same arguments, and do a
search-n-replace of "remove from kernel sources" to "move from kernel
sources to elsewhere."  To me, it's the same thing.


> > I see the action of BK doc removal as encouraging some strict
> > notion of what we can and cannot discuss, inside the kernel sources.
> > _That_ is the free speech aspect.
> > 
> > I see enforcing a strict notion of acceptable speech in the kernel
> > sources as a very bad thing for the Linux project.
> > 
> > I'm not asking you to agree -- but do you even understand my viewpoint here?
> 
> I do.  I don't agree with you that any of this has something to do with free 
> speech, but I'm willing to accept that you view the kernel source as a kind of
> podium.

I conjecture, then, that moving the BK doc to satisfy sensitivies is
also acknowledge of the kernel sources as a podium :)


> > > I really don't see how changing out the files for a url qualifies as
> > > the "worst way" of addressing the issue.  If Larry unretracts his offer
> > > to host the files - and I fully expect he will do that after some period
> > > of indulging in his wounded bird act - then by definition the documentation
> > > will always be available exactly when and where needed.  Is there *anybody*
> > > here who'd have further license-related complaints about Bitkeeper if that
> > > were done?  (Speak or forever hold your peace.)
> > 
> > First, I can host the doc.  And will, if there is justification.
> > I do not see a justification.  Larry is irrelevant.
> 
> To this discussion?  Debatable.  I'll go with you on that for now though, and
> see where it leads.

hehe


> > Second, I guarantee that license-related complaints about BitKeeper will
> > continue to exist, regardless of the doc's location.  Moving the doc
> > does absolutely nothing to assauge bad feelings about the BK license.
> 
> It would for me, others mileage may vary.

Interesting.  And I will claim up-front that I don't understand this
one bit.  BitKeeper would still be in use with its odious license,
and people will still say the "BitKeeper mafia" exists, even if the
document is moved.

	Jeff

Re: [PATCH] Remove Bitkeeper documentation from Linux tree

[Davide Libenzi]

On Mon, 22 Apr 2002, Jeff Garzik wrote:

> The real question, as I understand it, is whether or not the kernel doc
> should be in the kernel source or not.  If the answer is 'no', then I
> fully support making it a URL, or printing it out the back of
> phonebooks, or whatever means of distribution :)

i really tried to remain out of this. in theory, like Linus said, we
should not even know that he's using bk. it should be completely hidden.
the only method described inside the kernel tarbal should be the
old diff+patch one. main maintainers ( i mean the group of at most 10 that
are handling huge number of patches and that are highly interacting with
Linus ) will very likely get benefits from using bk instead of diff+patch,
but for these one no doc is necessary. either they know or Larry can
provide them with all the docs they need. for all the remaining crew, bk
adoption is simply a trend followup.




- Davide

There is no cabal (was: the BK flamewar)

[Jeff Garzik]

On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> On Mon, 22 Apr 2002, Jeff Garzik wrote:
> 
> > The real question, as I understand it, is whether or not the kernel doc
> > should be in the kernel source or not.  If the answer is 'no', then I
> > fully support making it a URL, or printing it out the back of
> > phonebooks, or whatever means of distribution :)
> 
> i really tried to remain out of this. in theory, like Linus said, we
> should not even know that he's using bk. it should be completely hidden.
> the only method described inside the kernel tarbal should be the
> old diff+patch one. main maintainers ( i mean the group of at most 10 that
> are handling huge number of patches and that are highly interacting with
> Linus ) will very likely get benefits from using bk instead of diff+patch,
> but for these one no doc is necessary. either they know or Larry can
> provide them with all the docs they need. for all the remaining crew, bk
> adoption is simply a trend followup.

Nope, the kernel doc was created precisely for the kernel maintainers,
cuz most of them (like me) had no clue about how to use BK nicely
for the kernel.  Honestly, we were all lazy (except the PPC guys
and GregKH, I guess :)) and let Linus figure out kernel development
under BK.

If we attempt to pretend that BK is not widely usage, you do a
dissservice to other kernel developers, sysadmins, and power users --
and possibly _increase_ the barrier to entry of the "group of at most
10" you describe above.

That "10" does not need do, and should never be, an exclusive club...
it just sorta evolved over time as the people who work best with
Linus.  I want to spread knowledge about working well with Linus
as far and as wide as possible -- that benefits all Linux users,
and open source overall.

I think I have proven that I am working towards that goal, of
publishing "Linus knowledge" -- I wrote not only the BK version of
Doc/SubmittingPatches, but also Doc/SubmittingPatches itself.

Let the knowledge out there, and let people make their own decisions...

	Jeff

Re: There is no cabal (was: the BK flamewar)

[Davide Libenzi]

On Mon, 22 Apr 2002, Jeff Garzik wrote:

> On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> > On Mon, 22 Apr 2002, Jeff Garzik wrote:
> >
> > > The real question, as I understand it, is whether or not the kernel doc
> > > should be in the kernel source or not.  If the answer is 'no', then I
> > > fully support making it a URL, or printing it out the back of
> > > phonebooks, or whatever means of distribution :)
> >
> > i really tried to remain out of this. in theory, like Linus said, we
> > should not even know that he's using bk. it should be completely hidden.
> > the only method described inside the kernel tarbal should be the
> > old diff+patch one. main maintainers ( i mean the group of at most 10 that
> > are handling huge number of patches and that are highly interacting with
> > Linus ) will very likely get benefits from using bk instead of diff+patch,
> > but for these one no doc is necessary. either they know or Larry can
> > provide them with all the docs they need. for all the remaining crew, bk
> > adoption is simply a trend followup.
>
> Nope, the kernel doc was created precisely for the kernel maintainers,
> cuz most of them (like me) had no clue about how to use BK nicely
> for the kernel.  Honestly, we were all lazy (except the PPC guys
> and GregKH, I guess :)) and let Linus figure out kernel development
> under BK.
>
> If we attempt to pretend that BK is not widely usage, you do a
> dissservice to other kernel developers, sysadmins, and power users --
> and possibly _increase_ the barrier to entry of the "group of at most
> 10" you describe above.
>
> That "10" does not need do, and should never be, an exclusive club...
> it just sorta evolved over time as the people who work best with
> Linus.  I want to spread knowledge about working well with Linus
> as far and as wide as possible -- that benefits all Linux users,
> and open source overall.

Jeff, did you really mean this ?

"If we attempt to pretend that BK is not widely usage ..."

It did not seem to me that Linus required BK to interact with him. So to
be or not to be inside the above group does not depend at all from BK
usage. BK can make life a lot easier for guys handling huge number of
patches with complex hierarchies, but forcing the one working with 1-5
patches to use it, it reflects the "trend followup" i was talking about.




- Davide

Re: There is no cabal (was: the BK flamewar)

[Jeff Garzik]

On Mon, Apr 22, 2002 at 04:22:29PM -0700, Davide Libenzi wrote:
> On Mon, 22 Apr 2002, Jeff Garzik wrote:
> 
> > On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> > > On Mon, 22 Apr 2002, Jeff Garzik wrote:
> > >
> > > > The real question, as I understand it, is whether or not the kernel doc
> > > > should be in the kernel source or not.  If the answer is 'no', then I
> > > > fully support making it a URL, or printing it out the back of
> > > > phonebooks, or whatever means of distribution :)
> > >
> > > i really tried to remain out of this. in theory, like Linus said, we
> > > should not even know that he's using bk. it should be completely hidden.
> > > the only method described inside the kernel tarbal should be the
> > > old diff+patch one. main maintainers ( i mean the group of at most 10 that
> > > are handling huge number of patches and that are highly interacting with
> > > Linus ) will very likely get benefits from using bk instead of diff+patch,
> > > but for these one no doc is necessary. either they know or Larry can
> > > provide them with all the docs they need. for all the remaining crew, bk
> > > adoption is simply a trend followup.
> >
> > Nope, the kernel doc was created precisely for the kernel maintainers,
> > cuz most of them (like me) had no clue about how to use BK nicely
> > for the kernel.  Honestly, we were all lazy (except the PPC guys
> > and GregKH, I guess :)) and let Linus figure out kernel development
> > under BK.
> >
> > If we attempt to pretend that BK is not widely usage, you do a
> > dissservice to other kernel developers, sysadmins, and power users --
> > and possibly _increase_ the barrier to entry of the "group of at most
> > 10" you describe above.
> >
> > That "10" does not need do, and should never be, an exclusive club...
> > it just sorta evolved over time as the people who work best with
> > Linus.  I want to spread knowledge about working well with Linus
> > as far and as wide as possible -- that benefits all Linux users,
> > and open source overall.
> 
> Jeff, did you really mean this ?
> 
> "If we attempt to pretend that BK is not widely usage ..."
> 
> It did not seem to me that Linus required BK to interact with him. So to
> be or not to be inside the above group does not depend at all from BK
> usage. BK can make life a lot easier for guys handling huge number of
> patches with complex hierarchies, but forcing the one working with 1-5
> patches to use it, it reflects the "trend followup" i was talking about.

If you read that from what I wrote, you are mistaken...

I'm saying that removing the BK doc from the kernel sources removes
description of one, _optional_ avenue to Linus.  That is denying
people information.

Which is completely contrary to one of my goals, spreading knowledge
about working with Linus to decrease the barrier of entry.

BK is not a requirement, even for regular submittors.  Optional.

	Jeff