Re: BK, deltas, snapshots and fate of -pre...

Re: BK, deltas, snapshots and fate of -pre...

[Petr Vandrovec]

On 21 Apr 02 at 19:34, Daniel Phillips wrote:
> 
> True, but I'm a contributor and so I have an interest in it.  It would be
> better if you didn't pursue that line of argument.
> 
> How about the URL?

Why we have kernel tarball at all, then? Just put URLs where you can 
download different pieces of kernel, and we are done. You finally
solved problem how to help users who do not want to download different
arch subdirectories, or different drivers, as they do not need them
for their hardware, and downloading them takes a precious time.

As there is definitely at least one developer who uses Bitkeeper, and
as this information is seen useful at least by some people (me including),
I see no reason why this information should not be part of kernel.

Otherwise we must remove ncpfs and matroxfb from the kernel immediately, as
they both use proprietary protocol/interface, and there is available only 
one vendor on the world who provides/supports this protocol/interface 
(Novell resp. Matrox), and matroxfb documentation is just hidden advertising
of Matrox corp.
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz

Re: BK, deltas, snapshots and fate of -pre...

[Ian Molton]

Petr Vandrovec Awoke this dragon, who will now respond:

> 
>  Why we have kernel tarball at all, then? Just put URLs where you can 
>  download different pieces of kernel, and we are done. You finally

Actually, the kernel tarball is full of crap we dont need.

Sooner or later its going to get too big and be split up into

core kernel
drivers (drivers/net, drivers/video etc.)
arch specifics
documentation

all for seperate download.

Re: BK, deltas, snapshots and fate of -pre...

[Anton Altaparmakov]

At 19:19 22/04/02, Ian Molton wrote:
>Petr Vandrovec Awoke this dragon, who will now respond:
>
> >
> >  Why we have kernel tarball at all, then? Just put URLs where you can
> >  download different pieces of kernel, and we are done. You finally
>
>Actually, the kernel tarball is full of crap we dont need.
>
>Sooner or later its going to get too big and be split up into
>
>core kernel
>drivers (drivers/net, drivers/video etc.)
>arch specifics
>documentation
>
>all for seperate download.

That is never going to happen, at least not as long as Linus is the kernel 
maintainer. I believe he has said so more than once before...

One of the reasons being that such an act would make changing global APIs a 
virtual impossiblity. And such changes happen often in Linux during the 
unstable kernel series. And those changes are good changes... Otherwise we 
will end up with Windows having backwards compatibility with DOS for 
virtually all eternity...

Best regards,

Anton


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

Re: BK, deltas, snapshots and fate of -pre...

[Thunder from the hill]

Hi,

Could please someone have this patch applied instead of arguing all day
and all of the night?

Regards,
Thunder

--- bk-kernel-howto.txt~	Mon Apr 22 12:26:50 2002
+++ bk-kernel-howto.txt	Mon Apr 22 12:26:11 2002
@@ -15,6 +15,14 @@
 "bk help <command>" or in X "bk helptool <command>" for reference
 documentation.
 
+    Also, BitKeeper is not free software.  You may use it for free, subject
+    to the licensing rules (bk help bkl will display them), but it is
+    not open source.  If you feel strongly about 100% free software
+    tool chain, then don't use BitKeeper.  Linus has repeatedly stated
+    that he will continue to accept and produce traditional "diff -Nur"
+    style patches.  It is explicitly not a requirement that you use
+    BitKeeper to do kernel development, people may choose whatever tool
+    works best for them.
 
 BitKeeper Concepts
 ------------------

-- 
                                                  Thunder from the hill.
Not a citizen of any town.                   Not a citizen of any state.
Not a citizen of any country.               Not a citizen of any planet.
                         Citizen of our universe.

Re: BK, deltas, snapshots and fate of -pre...

[Roman Zippel]

Hi,

Thunder from the hill wrote:

> --- bk-kernel-howto.txt~        Mon Apr 22 12:26:50 2002
> +++ bk-kernel-howto.txt Mon Apr 22 12:26:11 2002
> @@ -15,6 +15,14 @@

I'd prefer this to be a separate document (e.g. README) and not
somewhere inbetween.

> +    Also, BitKeeper is not free software.  You may use it for free, subject
> +    to the licensing rules (bk help bkl will display them), but it is
                               ^^^^^^^^^^^

At that point it's already too late, the user must have the chance to
read this, before he installs bk.

> +    not open source.  If you feel strongly about 100% free software
> +    tool chain, then don't use BitKeeper.  Linus has repeatedly stated
                                                   
^^^^^^^^^^^^^^^^^^^^^

That has a "for all these idiots, that don't want to understand"
aftertaste, I'm certain Linus doesn't want to imply that.

bye, Roman

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Mon, Apr 22, 2002 at 09:40:43PM +0200, Roman Zippel wrote:
> > +    Also, BitKeeper is not free software.  You may use it for free, subject
> > +    to the licensing rules (bk help bkl will display them), but it is

-    to the licensing rules (bk help bkl will display them), but it is
+    to the licensing rules (http://www.bitkeeper.com/manpages/bk-bkl-1.html)

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

Re: BK, deltas, snapshots and fate of -pre...

[Kai Henningsen]

thiagop@stampede.org (Kiss The Blade)  wrote on 28.04.02 in <FCYTRNJE041Y54TSRNOMZTEAG1Z3VTR.3ccc5e20@kingston>:

> Why people continue bitching about this? It's just a tool. Maybe we should
> just start flaming Coca-Cola because it does not open source the formula of
> the soft drink.

Maybe if they did, someone could design something actually drinkable from  
that ... then again, the result would be so different, one might as well  
start from scratch. And nobody seems interested anyway (or else someone  
*would* have started from scratch and produced something that doesn't try  
to be a very close clone).

And I'm probably not interested enough to make ot a commercial success  
anyway, even if everybody were like me.

MfG Kai

Re: BK, deltas, snapshots and fate of -pre...

[Kai Henningsen]

thiagop@stampede.org (Kiss The Blade)  wrote on 28.04.02 in <FCYTRNJE041Y54TSRNOMZTEAG1Z3VTR.3ccc5e20@kingston>:

> Why people continue bitching about this? It's just a tool. Maybe we should
> just start flaming Coca-Cola because it does not open source the formula of
> the soft drink.

Maybe if they did, someone could design something actually drinkable from  
that ... then again, the result would be so different, one might as well  
start from scratch. And nobody seems interested anyway (or else someone  
*would* have started from scratch and produced something that doesn't try  
to be a very close clone).

And I'm probably not interested enough to make ot a commercial success  
anyway, even if everybody were like me.

MfG Kai

Re: BK, deltas, snapshots and fate of -pre...

[Kiss The Blade]

28/4/2002 17:11:05, Roman Zippel <zippel@linux-m68k.org> wrote:
>Linus Torvalds wrote:
>
>> I don't want a kernel howto quoting the FSF.
>
>Would you please explain then, what you want?

I'm not Linus, but i think he does not want nothing of this at all. He cares about 
the kernel. The kernel does not know about politics, the kernel knows about 
HARDWARE.

Why people continue bitching about this? It's just a tool. Maybe we should 
just start flaming Coca-Cola because it does not open source the formula of the 
soft drink.

--
Fast, cheap, good. Pick two.

Re: BK, deltas, snapshots and fate of -pre...

[Roman Zippel]

Hi,

Linus Torvalds wrote:

> I don't want a kernel howto quoting the FSF.

Would you please explain then, what you want?

bye, Roman

Re: BK, deltas, snapshots and fate of -pre...

[Roman Zippel]

Hi,

Richard Gooch wrote:

> OK, I'll add this link, but I'd feel more comfortable adding this if
> there was a URL I could quote for the opposing view, and hence be more
> balanced. But I guess no-one has bothered to write a manifesto. If
> someone has or does, let me know.
> 
> The purpose of the FAQ entry isn't to support a particular view, but
> to serve as a "State of the Community" notice.

Then you should remove the "all software wants to be free (and hence all
non-free/proprietary software is evil)" part, that was hardly demanded
by the "Community". Read the link I gave you, it's about protecting free
software, it's not about forcing our views onto others.

bye, Roman

Re: BK, deltas, snapshots and fate of -pre...

[tomas szepe]

> Remember: we're not the Judean People's Front, we're the People's Front of
> Judea. Or maybe we're the Popular Front for the Liberation of Judea. I get
> confused.


"Listen. If you really wanted to join the People's Front of Judea,
you'd have to really hate [BK-Usage/]."

"I do!!"

"Oh yeah? How much?"

"_A_ _LOT_."

"Right. You're in. The only people we hate more than the ones who
wrote the files in that damn dir are the f#@$%ing Judean People's Front!"



t.

Re: BK, deltas, snapshots and fate of -pre...

[Kiss The Blade]

28/4/2002 16:27:09, Linus Torvalds <torvalds@transmeta.com> wrote:

>Remember: we're not the Judean People's Front, we're the People's Front of
>Judea. Or maybe we're the Popular Front for the Liberation of Judea. I get
>confused.

Don't try to understand this whole mess. It's way more complicated than kernel 
hacking. Trust me,  i know a lot about war and freedom fighting since i have a 
older brother ;)

--
Fast, cheap, good. Pick two.

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Kiss The Blade writes:
> 28/4/2002 16:27:09, Linus Torvalds <torvalds@transmeta.com> wrote:
> 
> >Remember: we're not the Judean People's Front, we're the People's Front of
> >Judea. Or maybe we're the Popular Front for the Liberation of Judea. I get
> >confused.
> 
> Don't try to understand this whole mess. It's way more complicated
> than kernel hacking. Trust me, i know a lot about war and freedom
> fighting since i have a older brother ;)

Just nuke him from orbit. It's the only way to be sure.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Linus Torvalds writes:
> 
> 
> On Sun, 28 Apr 2002, Kiss The Blade wrote:
> > 28/4/2002 15:47:43, Richard Gooch <rgooch@ras.ucalgary.ca> wrote:
> >
> > >It already has, for years. Like it or not, certain questions/issues
> > >*do* get raised. If the FAQ can capture at least some of these, it
> > >saves bandwidth on the list.
> >
> > I think Linus actually does not want to endorse the FSF stance about how
> > software must be ethically correct.
> 
> Right. Besides, as the whole notion of "free software" has very
> little to do with the kernel, please just link to some open source
> site. One of the more neutral ones is
> "http://www.debian.org/social_contract.html", for example.

To add more "balance" (and to show that people will never agree:-),
I've added links to the above Debian URL as well as one from OSI.

> Remember: we're not the Judean People's Front, we're the People's
> Front of Judea. Or maybe we're the Popular Front for the Liberation
> of Judea. I get confused.

No, we're the Libertarian Front for the People of Judea. Get it right.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Linus Torvalds]

On Sun, 28 Apr 2002, Kiss The Blade wrote:
> 28/4/2002 15:47:43, Richard Gooch <rgooch@ras.ucalgary.ca> wrote:
>
> >It already has, for years. Like it or not, certain questions/issues
> >*do* get raised. If the FAQ can capture at least some of these, it
> >saves bandwidth on the list.
>
> I think Linus actually does not want to endorse the FSF stance about how
> software must be ethically correct.

Right. Besides, as the whole notion of "free software" has very little to
do with the kernel, please just link to some open source site. One of the
more neutral ones is "http://www.debian.org/social_contract.html", for
example.

Remember: we're not the Judean People's Front, we're the People's Front of
Judea. Or maybe we're the Popular Front for the Liberation of Judea. I get
confused.

			Linus

Re: BK, deltas, snapshots and fate of -pre...

[Kiss The Blade]

28/4/2002 15:47:43, Richard Gooch <rgooch@ras.ucalgary.ca> wrote:

>It already has, for years. Like it or not, certain questions/issues
>*do* get raised. If the FAQ can capture at least some of these, it
>saves bandwidth on the list.

I think Linus actually does not want to endorse the FSF stance about how 
software must be ethically correct.

Thanks God, at least a guy with good sense =]

--
Fast, cheap, good. Pick two.

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Linus Torvalds writes:
> 
> 
> On Sun, 28 Apr 2002, Richard Gooch wrote:
> >
> > > http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
> > > free software is.
> >
> > OK, I'll add this link
> 
> Please don't.
> 
> I don't want a kernel howto quoting the FSF.

It already has, for years. Like it or not, certain questions/issues
*do* get raised. If the FAQ can capture at least some of these, it
saves bandwidth on the list.

Anyway, since both you and Daniel are unhappy about the entry, I
figure it averages out to be neutral :-)

It's kind of like the Australian Senate, which for the last 15 years
or so has managed to piss-off governments of both of the major
parties, and has been called "obstructionist" and "unrepresentative
swill" at various times, with government calls for "reform" (read:
transformed into a rubber stamp) from both sides. This probably means,
on average, they are doing the right thing. Certainly the voting
public seems to be happy with the situation.

Not that I should compare myself with the Australian Senate. What I do
is far more important.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Linus Torvalds]

On Sun, 28 Apr 2002, Richard Gooch wrote:
>
> > http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
> > free software is.
>
> OK, I'll add this link

Please don't.

I don't want a kernel howto quoting the FSF.

		Linus

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Daniel Phillips writes:
> On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> > I've added two subsections to the FAQ about this, which I hope will
> > avoid some future flamewars:
> > http://www.tux.org/lkml/#s1-20
> > http://www.tux.org/lkml/#s1-21
> 
> Perhaps the message would be more credible if this were toned down:
> 
>   no matter how loud or how many times you scream,

Actually, those words were carefully chosen. There *has* been a lot of
repeated shouting about this topic. I want to highlight the stupidity
and futility of dragging the list through another pointless flamewar.
I've used similar language elsewhere in the FAQ for other repeat
flamewars or pointless debates.

The bottom line is: no matter how many times you scream, Linus won't
change his mind because of the BK licence. The FAQ entry is accurate.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Daniel Phillips writes:
> On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> > I've added two subsections to the FAQ about this, which I hope will
> > avoid some future flamewars:
> > http://www.tux.org/lkml/#s1-20
> > http://www.tux.org/lkml/#s1-21
> 
> 
> > it's better that those who feel stronly about it
>                                   ^^^^^^^--------- typo

Bugger! Thanks.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Roman Zippel writes:
> Hi,
> 
> On Sat, 27 Apr 2002, Richard Gooch wrote:
> 
> > I've added two subsections to the FAQ about this, which I hope will
> > avoid some future flamewars:
> > http://www.tux.org/lkml/#s1-21
> 
> You should fix the first paragraph, read

You should learn to not say "you should" but instead "I suggest".

> http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
> free software is.

OK, I'll add this link, but I'd feel more comfortable adding this if
there was a URL I could quote for the opposing view, and hence be more
balanced. But I guess no-one has bothered to write a manifesto. If
someone has or does, let me know.

The purpose of the FAQ entry isn't to support a particular view, but
to serve as a "State of the Community" notice.

> "at no charge" is questionable, Larry wants no money in some cases,
> but he wants log entries, so please just link to the license ("bk
> help bkl" is useless, if one just to know the licence) and advise
> the user to carefully read it, before using bk.

Adding a URL is good. Fortunately, some other people have sent me the
URL, so I can include that as well now.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sat, Apr 27, 2002 at 12:59:17PM -0600, Richard Gooch wrote:
> I've added two subsections to the FAQ about this, which I hope will
> avoid some future flamewars:
> http://www.tux.org/lkml/#s1-20
> http://www.tux.org/lkml/#s1-21

Looks good, nice addition, thanks.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Roman Zippel]

Hi,

On Sat, 27 Apr 2002, Richard Gooch wrote:

> I've added two subsections to the FAQ about this, which I hope will
> avoid some future flamewars:
> http://www.tux.org/lkml/#s1-21

You should fix the first paragraph, read
http://www.gnu.org/philosophy/free-sw.html if you don't know anymore what
free software is.
"at no charge" is questionable, Larry wants no money in some cases, but he
wants log entries, so please just link to the license ("bk help bkl" is
useless, if one just to know the licence) and advise the user to
carefully read it, before using bk.

bye, Roman

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

Larry McVoy writes:
> On Sun, Apr 21, 2002 at 06:21:27PM +0200, Daniel Phillips wrote:
> > > It's not my call to make.
> > 
> > I know that.  I was wondering if *you personally* would have any objection.
> 
> Daniel, I won't be nagged into supporting your point of view, sorry.
> I didn't even know that the doc was in the tree until you raised the
> point.  I don't see a problem with it being in the tree and I do *not*
> support your attempts to remove it.
> 
> You seem to think it has some great value to BitMover to have it in
> the tree.  Sorry, that's not true.  It's true to some small extent, in
> that it may reduce the number of support queries that we get related to
> the kernel.  So we'd prefer it stayed in the tree.
> 
> Why don't you ask Jeff to stick in the doc saying something like
> 
>     BitKeeper is not free software.  You may use it for free, subject
>     to the licensing rules (bk help bkl will display them), but it is
>     not open source.  If you feel strongly about 100% free software
>     tool chain, then don't use BitKeeper.  Linus has repeatedly stated
>     that he will continue to accept and produce traditional "diff -Nur"
>     style patches.  It is explicitly not a requirement that you use
>     BitKeeper to do kernel development, people may choose whatever tool
>     works best for them.

I've added two subsections to the FAQ about this, which I hope will
avoid some future flamewars:
http://www.tux.org/lkml/#s1-20
http://www.tux.org/lkml/#s1-21

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> I've added two subsections to the FAQ about this, which I hope will
> avoid some future flamewars:
> http://www.tux.org/lkml/#s1-20
> http://www.tux.org/lkml/#s1-21

Perhaps the message would be more credible if this were toned down:

  no matter how loud or how many times you scream,

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Saturday 27 April 2002 20:59, Richard Gooch wrote:
> I've added two subsections to the FAQ about this, which I hope will
> avoid some future flamewars:
> http://www.tux.org/lkml/#s1-20
> http://www.tux.org/lkml/#s1-21


> it's better that those who feel stronly about it
                                  ^^^^^^^--------- typo

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Kai Henningsen]

dledford@redhat.com (Doug Ledford)  wrote on 22.04.02 in <20020422165327.A914@redhat.com>:

> On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 21:53, Doug Ledford wrote:
> > > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > > How about a URL instead?  Any objection?
> > >
> > > Yes.  Why should I have to cut and paste (assuming I'm in X) or
> > > write down
> >
> > What???   What kind of system are you running?  Err... redhat supports
> > cut and paste I thought. <-- funnny.
>
> Depends on what you use to read the file containing the URL.  Obviously,
> if I'm Al Viro I'm on a text console and wouldn't use a mouse if you
> cemented it in my hand, so cut and paste isn't an option.

I have no idea about Al, but while I do spend most of my time on the  
console, I do use a mouse there for cut and paste. Long live gpm.

> real docs, switch to X or install lynx on my system, go to URL.  It's a

You don't have lynx installed on a development machine?! *boggle*

How about links? W3m? Hell, wget?

> Those were the relevant points you blithely skipped because you know they
> are true and hurt your position.  Selective response is something you've
> been practicing in this entire thread.

The debating tactics used in this thread - on more than one side - are  
nothing to be proud about.

Could we not try to figure out ways to make Linux better, instead of  
digging for ways to make each other look bad?

MfG Kai

Re: BK, deltas, snapshots and fate of -pre...

[Rik van Riel]

On Thu, 25 Apr 2002, Ian Molton wrote:
> Rik van Riel Awoke this dragon, who will now respond:
>
> >
> >  "Why should I waste my disk space with SCSI drivers?"
> >  "Why should I waste my disk space with MIPS support?"
> >  "Why should I waste my disk space with bluetooth drivers?"
> >
> >  In each of these cases you'll get the same answer that I gave
> >  to your question.
>
> Actually, I dont get that.

	[snip "Couldn't the kernel be split in various tarballs?"]

> Here is my answer for the record:
>
> I shouldnt. its a pointless waste of bandwidth.
>
> Now, whats YOUR answer?

You'll find the answer in the lkml FAQ:

	http://www.tux.org/lkml/#s7-7

cheers,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

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

Re: BK, deltas, snapshots and fate of -pre...

[Richard Gooch]

> spyro@armlinux.org said:
> > Why SHOULD I download ten different architectures when I only want two
> > (ARM and X86).? Why SHOULD I download SCSI when I dont use anything
> > but IDE? (cost reasons) Why SHOULD I download bluetooth stuff when I
> > will probably wont own a bluetooth device in the near future?
> 
> > Why dont you try to provide a satisfactory answer to those questions
> > instead of avoiding them and turning them around? 

Why don't you Read The Fucking FAQ???!!!???
http://www.tux.org/lkml/#s7-7

For someone who's so concerned about bandwidth, why didn't you read
the FAQ first? You would have seen that this question is already
answered and should not be asked on the list, and you would have saved
developer bandwidth. With your post, a large number of busy people had
to download your email, read it, process it and reach the conclusion
"Luser asking repeat, dumb and useless question. Remember to ignore in
future". That wastes people's time. And it's not even in your best
interests.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: BK, deltas, snapshots and fate of -pre...

[David Woodhouse]

spyro@armlinux.org said:
> Why SHOULD I download ten different architectures when I only want two
> (ARM and X86).? Why SHOULD I download SCSI when I dont use anything
> but IDE? (cost reasons) Why SHOULD I download bluetooth stuff when I
> will probably wont own a bluetooth device in the near future?

> Why dont you try to provide a satisfactory answer to those questions
> instead of avoiding them and turning them around? 

Linus has categorically stated that he will not split up the kernel sources.
The GPL gives you the freedom to fork the kernel and do so if you wish.

Please do not continue this pointless debate here. You will not achieve 
anything which was not achieved in all the other numerous times some troll 
has brought it up.

Do, or do not. There is no troll.

--
dwmw2

Re: BK, deltas, snapshots and fate of -pre...

[Ian Molton]

Olivier Galibert Awoke this dragon, who will now respond:

>  > I shouldnt. its a pointless waste of bandwidth.
>  > 
>  > Now, whats YOUR answer?
> 
>  Developpers need complete sources.  No questions about that.  If they
>  don't have the complete sources, they'll fuck things up.  So the
>  developpers have zero use for partial downloadings.

Sorry, that doesnt fly. If I dont work on SCSI, only on networking, I
/dont/ need the SCSI code. Even if I had it, I wouldnt read it.

I deleted all the arch directories except ARM and X86 on my machine to
speed up grepping the kernel.

so, not having all the source can speed thigs up.

>  Some users may like to be able to download only the core code and
>  drivers/filesystems/architectures they use.

This developer would too.

>  Ignoring the obvious
>  version drift problems that will happen,

Why would they happen?

> proposing such a service
>  requires work and a large amount of bandwidth.  Do you volunteer?

Surely it requires LESS bandwidth than if people are sucking the WHOLE
kernel ?

Re: BK, deltas, snapshots and fate of -pre...

[Olivier Galibert]

On Thu, Apr 25, 2002 at 04:51:20AM +0100, Ian Molton wrote:
>[usual I-want-to-download-only-what-I-use rant]
> Here is my answer for the record:
> 
> I shouldnt. its a pointless waste of bandwidth.
> 
> Now, whats YOUR answer?

Developpers need complete sources.  No questions about that.  If they
don't have the complete sources, they'll fuck things up.  So the
developpers have zero use for partial downloadings.

Some users may like to be able to download only the core code and
drivers/filesystems/architectures they use.  Ignoring the obvious
version drift problems that will happen, proposing such a service
requires work and a large amount of bandwidth.  Do you volunteer?

  OG.

Re: BK, deltas, snapshots and fate of -pre...

[Ian Molton]

Rik van Riel Awoke this dragon, who will now respond:

> 
>  "Why should I waste my disk space with SCSI drivers?"
>  "Why should I waste my disk space with MIPS support?"
>  "Why should I waste my disk space with bluetooth drivers?"
> 
>  In each of these cases you'll get the same answer that I gave
>  to your question.

Actually, I dont get that.

Why SHOULD I download ten different architectures when I only want two (ARM
and X86).?
Why SHOULD I download SCSI when I dont use anything but IDE? (cost reasons)
Why SHOULD I download bluetooth stuff when I will probably wont own a
bluetooth device in the near future?

Why dont you try to provide a satisfactory answer to those questions
instead of avoiding them and turning them around?

Here is my answer for the record:

I shouldnt. its a pointless waste of bandwidth.

Now, whats YOUR answer?

Especially in light of the 2.5 kernel becomming ever more modular.

Re: BK, deltas, snapshots and fate of -pre...

[Linus Torvalds]

On Sun, 21 Apr 2002, Pavel Machek wrote:
>
> I believe -pre's are still important. Daily snapshots are too likely to be
> broken, and "real" releases are different from -pre ones (with *usefull*
> difference): you can ignore -pre release, but you can't ignore real release
> (because real releases are relative to each other).

Considering how even real releases in the development tree are likely to
be broken (never mind the _trivial_ brokenness of applying the same patch
to init/main.c twice, I'm talking about the more fundamental brokenness of
just broken drivers and filesystems due to development), I'm not sure how
big a deal that is.

And I do make full tar-files of real releases, so that people can skip a
few (although unless you have a fast connection it usually only makes
sense after 10 full releases or so).

> Having slightly more frequent real releases would be nice, but I believe
> it is not feasible to make them as common as pre- patches.

I'll try to keep them coming a bit more often.

		Linus

Re: BK, deltas, snapshots and fate of -pre...

[Pete Zaitcev]

>> > The well-defined resync points are the 2.5.N releases.  If -pre goes away,
>> > then the dot-releases might need to come a little closer together, that's all.
>> 
>> I agree.
>> 
>> I've told myself that I shouldn't have done "-preX" releases at all in
>> 2.5.x - the "real" numbers have become diluted by them, and I suspect the
>> -pre's are really just because I got used to making them during the
>> over-long 2.4.x time.
> 
> I believe -pre's are still important. Daily snapshots are too likely to be
> broken, and "real" releases are different from -pre ones (with *usefull*
> difference): you can ignore -pre release, but you can't ignore real release
> (because real releases are relative to each other).

Pavel, I think it is an delusion. In practical terms we have
a string of -pre and traditional releases which differ really
little in terms of reliability. I number of 2.5.x without -pre
fail to compile different non-core modules. 2.5.9 hangs on boot
on my machine, while -preX worked.

Marcelo pays more attention to stabilizing suffixless releases,
and as well he should. However, I do not see how this can
be meaningfuly done in 2.5.x. I am not going to shed any tears
over the demise of -pre in unstable series, provided that
releases get spaced tighter, with smaller patch size between them.

-- Pete

Re: BK, deltas, snapshots and fate of -pre...

[Rik van Riel]

On Sun, 21 Apr 2002, Pavel Machek wrote:

> > > How about a URL instead?  Any objection?
> >
> > Yes.  Why should I have to cut and paste (assuming I'm in X) or
> > write down and transpose some URL from a file that used to contain
>
> And why should I waste my disk space with BK docs?

Because they're useful for many people.

It's easy to rephrase that question to:

"Why should I waste my disk space with SCSI drivers?"
"Why should I waste my disk space with MIPS support?"
"Why should I waste my disk space with bluetooth drivers?"

In each of these cases you'll get the same answer that I gave
to your question.

regards,

Rik
-- 
	http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid.  Go buy yourself a real t-shirt"

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

Re: BK, deltas, snapshots and fate of -pre...

[Andreas Dilger]

On Apr 23, 2002  14:57 +1000, Andre Pang wrote:
> After reading the thread in its entirety (boy, that was fun),
> here's a summary of points that you're trying to make, all of
> which are independent issues:

Oh, come on now...  You're being too logical and level headed.
If everyone were like you, suddenly the volume of l-k would drop
by half, we wouldn't be wasting thousands of Linux developer-hours,
and we might actually get some coding done.

Please don't try this again.  Go back and read any one of the dozens
of lengthy flame wars on l-k for more appropriate methods of not
solving an unsolvable problem.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: BK, deltas, snapshots and fate of -pre...

[Andre Pang]

On Sun, Apr 21, 2002 at 08:16:28PM +0200, Daniel Phillips wrote:

> Please don't assign me membership in any anti-bitkeeper crew.  I am not
> anti-BitKeeper.  If you must have an epithet, try "anti-advertising-in-the-tree"
> crew.

As Larry has said, if you are anti-advertising-in-the-tree, then
start submitting patches regarding reiserfs, because of the large
amount of advertising to Namesys and their sponsors.

After reading the thread in its entirety (boy, that was fun),
here's a summary of points that you're trying to make, all of
which are independent issues:

    1. BK is not GPL; it is commercial software

    2. Having the BK doc in Documentation/ is advertising in the tree
    
    3. Having the BK doc in Documentation/ is advertising for
       commercial software

    4. Commercial software should be used as little as possible
       in such a large-scale GPL project like the Linux kernel

    5. Existence of BK doc will promote BK-style patches instead
       of the more traditional diff-style patches

    6. BK enables less discussion of patches because Linus can
       pull them from other BK trees

    7. From point 6, BK therefore makes it easier to have less
       public review (i.e. mails to LKML with "[RFC]") on patches

    8. Because of point 7, there is in fact less public review on
       patches

    9. Less public review on patches is bad

    10. Non-BK users feel left out because they feel that many
        patches are getting into the tree without their knowledge
        and/or less public review

    11. Pulling BK doc in the tree would make less users aware of
	BK and thus solve most of these problems

As Andrew Morton has said, some of these problems are simply
unsolvable, like BK being commercial software.  Your ideology vs
Jeff's is probably not reconcilable.

So, what are the problems that can be solved?  Perhaps adding
some lines to the BitKeeper doc saying "Unless your patch is
trivial, please post it to linux-kernel for peer review, because
this is one of the great strengths of open-source software" would
be a good idea.

Supply a shell script in the BK docs which generates a diff-style
patch and send that off to LKML if you update a BK tree.

Add that patch which was floating around earlier in the thread
saying that BK is non-free, and that it is only one alternative
for doing things.

Or maybe set up another separate mailing list (e.g.
linux-bk-updates), run by a bot which emails that list whenever
a patch to a BK tree is submitted.  People who don't use BK, such
as yourself, can subscribe to the list and initiate discussion on
such patches by bringing the mail to linux-kernel.

BK is here to stay; no doubt about that.  Doing something
completely controversial like removing the docs for it is not the
way to go if you want to solve the problems that it has created.
I think it's good that you vocalised the problems with using BK,
but you're going about fixing the symptoms in the wrong way.

I'm sure people (Jeff and Larry, in particular) would be much
more happy if you addressed those issues by adding things to the
BK docs highlighting the problems that it causes, and include
ways of fixing them.  You say that you're not anti-BK, and
I believe you're not, but your actions are indicating otherwise.

BK is not the problem: BK is a new way of working with Linus,
which is causing problems for people who are used to the non-BK
way of working with him.  Fix that problem, not BK itself.


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: BK, deltas, snapshots and fate of -pre...

[Chris Adams]

Once upon a time, Daniel Phillips <phillips@bonn-fries.net> said:
>Would everybody with no mouse on their system please stand up, and leave
>the room.
>
>Seriously, you're trolling.

Would everyone that complains about 11Kb (4683 bytes bzip2 compressed)
when downloading 144Mb (26Mb bzip2 compressed) please stand up, and leave
the room.

Seriously, you're trolling.

BTW: why no rightous indignation about the "Hideous Commercial Pitch" in
fs/reiserfs/README?  Code in that directory is dual licensed under the
GPL and a strictly commercial license, similar to BK, and is actually
_included_ with the kernel, as opposed to BK which is merely useful with
the kernel.
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Mon, Apr 22, 2002 at 05:45:41PM -0400, Alexander Viro wrote:
> Daniel, if you will ever get a legitimate reason to send me mail -
> try to convince somebody sane to forward it.  I'm serious - taking
> you out of killfile was a bad mistake and I'm not going to repeat
> it.

In 19 years of being on mailing lists, this is the first and
only time I've actually implemented a killfile.  Kind of sad,
but I can't say that I (or anyone else) am/is going to miss
me rising to Daniel's baiting.

> *PLONK*

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

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 11:37:29PM +0200, Daniel Phillips wrote:
> I just don't support the part that turns Documentation
> into a billboard.

Can we agree, that this is a fundamental disagreement you and I (and
others) will never agree on?

I see helpful documentation was added to the kernel sources to be more helpful.
You see an advertisement.

Would that be an accurate assessment of a main point of this thread?

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Doug Ledford]

On Sun, Apr 21, 2002 at 11:37:29PM +0200, Daniel Phillips wrote:
> Well.  Could always start now, and please count the places in the thread
> where I say BitKeeper is a good thing for Linux.  Commerical breaks in 
> in the source tree itself are considerably less good.

Establishing that something is a commercial break requires more than 
saying "Hey, that talks about features of X commercial product".  It 
involves *also* establishing that the commercial break doesn't apply those 
features to linux kernel programming in an instructional manner.  If you 
haven't done both, then you haven't done enough to justify removing said 
"commercial break" from the kernel archive.  As long as the "commercial 
break" is an instructional document I'll advocate that it stays where it 
is.  The *most* you will ever get me to agree to is the possible removal 
of obviously superflous and advocacy related statements that don't 
contribute to the instructional nature of the document.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: BK, deltas, snapshots and fate of -pre...

[Alexander Viro]

[snip the drivel]

Daniel, if you will ever get a legitimate reason to send me mail -
try to convince somebody sane to forward it.  I'm serious - taking
you out of killfile was a bad mistake and I'm not going to repeat
it.

*PLONK*

Re: BK, deltas, snapshots and fate of -pre...

[Nicholas Harring]

Daniel Phillips wrote:
> On Monday 22 April 2002 22:53, Doug Ledford wrote:
> 
>>On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
>>
>>>On Monday 22 April 2002 21:53, Doug Ledford wrote:
>>>
>>>>On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
>>>>
>>>>>How about a URL instead?  Any objection?
>>>>
>>>>Yes.  Why should I have to cut and paste (assuming I'm in X) or
>>>>write down
>>>
>>>What???   What kind of system are you running?  Err... redhat supports
>>>cut and paste I thought. <-- funnny.
>>
>>Depends on what you use to read the file containing the URL.  Obviously, 
>>if I'm Al Viro I'm on a text console and wouldn't use a mouse if you 
>>cemented it in my hand, so cut and paste isn't an option.
> 
> 
> Would everybody with no mouse on their system please stand up, and leave
> the room.
> 
> Seriously, you're trolling.
> 
> 
>>>>and transpose some URL from a file that used to contain
>>>>the exact instructions I need in order to get those instructions now
>>>
>>>Bogus.  You'd have to do the same to edit/list the file.
>>
>>No, I wouldn't.  In one case I would do "less <filename>" and in the other 
>>case I would do "less <filename>", ohh damn, it's only a pointer to the 
>>real docs, switch to X or install lynx on my system, go to URL.  It's a 
>>matter of having the appropriate documentation at hand vs. having to 
>>retrieve it.
> 
> 
> lynx <url>
> 
> What's the difference?
The difference is that currently linux/Documentation/SubmittingPatches 
currently exists and advocates the usage of diff. Linus no longer 
prefers diff, he has made it clear he likes BK output.
Would it be acceptable to simply modify said file to include both 
instructions for using diff, which I believe Linus has said he will 
continue to accept, as well as to include basic commands for BK to get 
output such as Linus wants emailed to him. No feature listing, no 
advertising, no advocacy, just simple usage.

> 
> 
>>I put my docs on my web site because that's what I owned/controlled and it 
>>was relevant to people already coming to my web site.  That in no way 
>>indicates that your position is correct, especially since you ignored to 
>>truly relevant item in my email:
> 
> 
> I'm actually trying to do a little work as well as handle all the input
> from the Bitkeeper moonies, thankyou.
> 
> Err, did I say moonies, sorry I meant advocates, err, apologists, umm.
> Sorry, I just meant I've been getting a lot of email lately, some of it
> is too long to read every word.  Unless you are a spectacularly good
> writer, expect some of your deathless prose to drop through the cracks.
> 
> 
>>>>information so that the whole picture, from start to finish, was all 
>>>>described in one easy to access place.
>>>
>>One place for relevant information, from start to finish.
> 
> 
> Right.  bitkeeper.com, any argument?
> 
> 
>>>You haven't read the thread closely, this was described before.  There are
>>>one documentation file and three scripts.  The documentation file is about
>>>half general description of Bitkeeper - which is quite unabashedly
>>>promotional and the author does describe it as an adverisement - and half
>>>how to use for submitting kernel patches.
>>
>>Now, now Daniel, let's not put words into people's mouths.  Jeff has said 
>>he does like BitKeeper, and he said he could *see how you think his 
>>description is an advertisement* but that he *didn't write it as an 
>>advertisement*.
> 
> 
> He agreed it was an advertisement.
> 

Re: BK, deltas, snapshots and fate of -pre...

[Doug Ledford]

On Mon, Apr 22, 2002 at 05:25:37PM -0400, Jeff Garzik wrote:
> To imply that the BK doc is an intentioned advertisement is silly.
> It's in the kernel source tree to help people with, like it or not, what
> is a part of kernel development.  An _optional_ part.

Which is *exactly* why it belongs with the kernel docs, and not on 
bitkeeper's web site.  It's an optional part of the kernel process, and 
just because BK has a license some people don't like is no reason to 
*not* document how that optional process works.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 11:05:11PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 22:53, Doug Ledford wrote:
> > On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> > > You haven't read the thread closely, this was described before.  There are
> > > one documentation file and three scripts.  The documentation file is about
> > > half general description of Bitkeeper - which is quite unabashedly
> > > promotional and the author does describe it as an adverisement - and half
> > > how to use for submitting kernel patches.
> > 
> > Now, now Daniel, let's not put words into people's mouths.  Jeff has said 
> > he does like BitKeeper, and he said he could *see how you think his 
> > description is an advertisement* but that he *didn't write it as an 
> > advertisement*.
> 
> He agreed it was an advertisement.

To clear things up:

* The intent of the doc is to help kernel developers
* The intent was NOT to advertise BK
* An unavoidable side effect of the doc's presence is implicit advertisement
* I certainly promote the use of BitKeeper

Please keep these things separate...

To imply that the BK doc is an intentioned advertisement is silly.
It's in the kernel source tree to help people with, like it or not, what
is a part of kernel development.  An _optional_ part.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Doug Ledford]

On Sun, Apr 21, 2002 at 11:05:11PM +0200, Daniel Phillips wrote:
> Would everybody with no mouse on their system please stand up, and leave
> the room.
> 
> Seriously, you're trolling.

No more so than your bandwidth argument...pot->kettle.

> > I put my docs on my web site because that's what I owned/controlled and it 
> > was relevant to people already coming to my web site.  That in no way 
> > indicates that your position is correct, especially since you ignored to 
> > truly relevant item in my email:
> 
> I'm actually trying to do a little work as well as handle all the input
> from the Bitkeeper moonies, thankyou.
> 
> Err, did I say moonies, sorry I meant advocates, err, apologists, umm.

Right, nice personal attack to deflect the arguments I actually wrote.  If 
you aren't going to answer the arguments, then why do you even bother to 
reply?  If you are falling behind due to the load of incoming mail then it 
seems bass-ackwards to make non-sense replies and arguments that are 
unnecessary instead of actually responding to the real arguments made.

BTW, I've never used BK.  I've never actually even gone to the BK web 
site.  That's probably why I haven't bothered to read the submitting 
patches using BK *HOWTO* doc in the kernel doc area.

> Sorry, I just meant I've been getting a lot of email lately, some of it
> is too long to read every word.  Unless you are a spectacularly good
> writer, expect some of your deathless prose to drop through the cracks.

Wow, more personal attack whilst cutting the actual arguments out.  That's 
always a good way to win an argument.  <imagine the sarcastic tone of 
voice>  Of course, that's why I repeated the two points, one of which you 
again cut.

> > > > information so that the whole picture, from start to finish, was all 
> > > > described in one easy to access place.
> > 
> > One place for relevant information, from start to finish.
> 
> Right.  bitkeeper.com, any argument?

Yeah.  I'll go to bitkeeper.com to learn about how to use bitkeeper.  I 
don't expect nor want to go there to learn about how to send a patch to 
Linus.  It's not the appropriate venue for that information.

> He agreed it was an advertisement.
> 
> -- 
> Daniel

Hmmm....Daniel stopped his reply before he even got to the really
important arguments in my email.  Guess that just means I win those points
by default which should pretty much settle this entire issue.  All BK 
advocacy docs need to be transferred to bitkeeper.com.  All valid HOWTO 
docs relating to kernel patch submission (whether via diff+email or via 
BK) should report to the kernel doc directory where they belong.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: BK, deltas, snapshots and fate of -pre...

[Anton Altaparmakov]

At 21:42 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > > Should we remove all advertisements from the kernel?  A Big Penguin
> > > > would probably object to the removal of this printk advertisement
> > > > for Swansea:
> > > >
> > > >   Linux NET4.0 for Linux 2.4
> > > >   Based upon Swansea University Computer Society NET3.039
> > > >
> > > > If the answer is no, then you are targetting BitKeeper specifically...
> > >
> > > Excellent point.  If the BitKeeper advertising in the kernel source were
> > > held to that level, I would be satisfied.
> >
> > <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> > pointless advertisement.
>
>You'd want to get rid of the url that points at your docs?

I think you misunderstood Jeff. I would also not be happy if I suddenly saw 
a bitkeeper advertisement during kernel bootup, which is what is quoted above.

It is not a piece of the kernel so it shouldn't be advertised as such. It 
is a tool that is used in combination with the kernel and the docs for such 
tool are rightfully in the kernel. docs != advertising. How many people 
will read the docs? Not many. And certainly not many who would be 
purchasing bitkeeper. How many people will see the above show copyright 
messages on boot? A LOT. Anyone booting Linux in fact...

Best regards,

Anton


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

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 10:42:46PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > > Should we remove all advertisements from the kernel?  A Big Penguin
> > > > would probably object to the removal of this printk advertisement
> > > > for Swansea:
> > > > 
> > > > 	Linux NET4.0 for Linux 2.4
> > > > 	Based upon Swansea University Computer Society NET3.039
> > > > 
> > > > If the answer is no, then you are targetting BitKeeper specifically...
> > > 
> > > Excellent point.  If the BitKeeper advertising in the kernel source were
> > > held to that level, I would be satisfied.
> > 
> > <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> > pointless advertisement.
> 
> You'd want to get rid of the url that points at your docs?

"that level" was assuming you were referring to the URL-free printk
advertisement I quoted above.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Doug Ledford]

On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 21:53, Doug Ledford wrote:
> > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > How about a URL instead?  Any objection?
> > 
> > Yes.  Why should I have to cut and paste (assuming I'm in X) or
> > write down
> 
> What???   What kind of system are you running?  Err... redhat supports
> cut and paste I thought. <-- funnny.

Depends on what you use to read the file containing the URL.  Obviously, 
if I'm Al Viro I'm on a text console and wouldn't use a mouse if you 
cemented it in my hand, so cut and paste isn't an option.

> > and transpose some URL from a file that used to contain
> > the exact instructions I need in order to get those instructions now
> 
> Bogus.  You'd have to do the same to edit/list the file.

No, I wouldn't.  In one case I would do "less <filename>" and in the other 
case I would do "less <filename>", ohh damn, it's only a pointer to the 
real docs, switch to X or install lynx on my system, go to URL.  It's a 
matter of having the appropriate documentation at hand vs. having to 
retrieve it.

> > I made a few docs that attempted to answer these questions and put them on 
>                                                                  ^^^^^^^^^^^
> > my web site along side the patches themselves.  These docs most generally 
>   ^^^^^^^^^^^
> Thanks for your story.  It's exactly what I've suggested, put the BK docs
> on a web site.

I put my docs on my web site because that's what I owned/controlled and it 
was relevant to people already coming to my web site.  That in no way 
indicates that your position is correct, especially since you ignored to 
truly relevant item in my email:

> > information so that the whole picture, from start to finish, was all 
> > described in one easy to access place.

One place for relevant information, from start to finish.

> >  So, as a result, even though I 
> > could have pointed the reader to the patch man page, I didn't bother to 
> > make them read a large document full of options and possible means of 
> > screwing things up when all I really wanted them to know was "All of my 
> > patches are generated so that if you go into the top level of the linux 
> > source directory and type 'patch -p1 < patchname' then things will work 
> > properly".

Limited scope "How to use in this specific case" documentation.

Those were the relevant points you blithely skipped because you know they 
are true and hurt your position.  Selective response is something you've 
been practicing in this entire thread.

> You haven't read the thread closely, this was described before.  There are
> one documentation file and three scripts.  The documentation file is about
> half general description of Bitkeeper - which is quite unabashedly
> promotional and the author does describe it as an adverisement - and half
> how to use for submitting kernel patches.

Now, now Daniel, let's not put words into people's mouths.  Jeff has said 
he does like BitKeeper, and he said he could *see how you think his 
description is an advertisement* but that he *didn't write it as an 
advertisement*.

>  No matter, Bitkeeper is *all*
> nonfree and the issue is whether documentation for it should live in our
> kernel tree or on a web site.  I.e., should Linux be advertising Bitkeeper
> through the kernel source.

And I've already given you my answer.  If the documentation in question is
specific to how to perform my patch work in a BK environment specifically
so that I can interface with Linus' BK environment directly, then I don't
really care less what the BK license itself is, the document is *still* a
HOWTO submit a patch using BK document and belongs with the linux kernel
docs, not with BitKeeper's web site.

> E) What is the license?

That's relevant to the decision of whether or not I use BK.  It is not 
relevant to *how* I would use BK, should I choose to do so, in order to 
submit patches/interface with Linus.  Since the document in question is 
suppossed to be about how to use BK to interface with Linus, and not a 
general discussion of whether or not any given individual *should* use BK, 
this point is irrelevant in determining where the document should live.

> > Like I said, I haven't read the document.  But, if I did and it turned out 
> > that it was similar to my description of how to use patch to apply my 
> > aic7xxx patches, IOW if it truly was a limited scope "How to use BK to 
> > send patches to Linus" and provided just the needed BK information to 
> > teach the user the real goal, which is how to integrate their work into 
> > Linus' BK patch process, then I would be greatly offended should the 
> > document be moved out it's appropriate location in the linux kernel 
> > documentation directory to some web site where it doesn't really belong.  
> 
> Because you can't follow a url?  Give me a break.

No, because I detest censorship, and that's all that your spewing has 
amounted to so far.  Because from every description I've heard so far the 
document is a valid HOWTO about patch submission.  Because the various 
HOWTO documents about the linux kernel *belong* in the kernel 
documentation tree.  Because if we are going to change the proper location 
of kernel HOWTO documents then we need to do it on a universal basis, not 
by discriminating against BK because of it's license (which, again, is a 
"Should I use" not "How do I use" relevant issue only).

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > Should we remove all advertisements from the kernel?  A Big Penguin
> > would probably object to the removal of this printk advertisement
> > for Swansea:
> > 
> > 	Linux NET4.0 for Linux 2.4
> > 	Based upon Swansea University Computer Society NET3.039
> > 
> > If the answer is no, then you are targetting BitKeeper specifically...
> 
> Excellent point.  If the BitKeeper advertising in the kernel source were
> held to that level, I would be satisfied.

<chuckle> -- and if that occurred, _I_ would fight to remove it as a
pointless advertisement.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Doug Ledford]

On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> How about a URL instead?  Any objection?

Yes.  Why should I have to cut and paste (assuming I'm in X) or
write down and transpose some URL from a file that used to contain
the exact instructions I need in order to get those instructions now just
to satisfy your sensitivity?  (And let's not get me started on
"sensitivity" and how personally I think that it's nothing more than a
politically correct way of saying "I don't want to hear what you have to
say so shut up" and is nothing more than another form of censorship that
should be beaten out of all children until it is once and for all
eliminated from this earth)

So let me tell a little story for a second.  I used to maintain the 
aic7xxx driver.  In so doing, I created a web site for disseminating my 
patches and what not.  As people would grab my patches, I would get 
regular (and annoying to me) questions like "how do I apply your 
patches", "what patch version should I grab", "how do I compile my 
kernel after I apply your patch," etc.  So, after enough of the same 
question, the question itself becomes a "frequently asked question".  So, 
I made a few docs that attempted to answer these questions and put them on 
my web site along side the patches themselves.  These docs most generally 
described how the linux kernel versioning worked, how my patch versioning 
worked, how to select patches, how to use the patch command, etc.  Now, 
obviously, some of this was very aic7xxx specific, but large parts of it 
were background knowledge that was required in order to apply that 
specific aic7xxx information.  It made sense therefore to include that 
information so that the whole picture, from start to finish, was all 
described in one easy to access place.  So, as a result, even though I 
could have pointed the reader to the patch man page, I didn't bother to 
make them read a large document full of options and possible means of 
screwing things up when all I really wanted them to know was "All of my 
patches are generated so that if you go into the top level of the linux 
source directory and type 'patch -p1 < patchname' then things will work 
properly".

So, I haven't read this "BitKeeper advertisement" you have been 
complaining about.  However, I have heard claims that it deals more 
specifically with how to interface your own personal BK setup with Linus 
than it does with usage of BK in general.  If I were to sit down and read 
that document now, the questions I would attempt to answer would be things 
like A) does it describe BK in general and how to set it up for general 
use, or does it describe how to set BK up for a specific use related to 
kernel developement, B) does it describe how that setup is then integrated 
into a kernel patch submission process, C) is the description relevant 
to all BK setups (not just linux kernel setups) or is it geared 
specifically towards linux kernel setups, and D) would the description of 
BK found in the document be of general use to BK deployments in evil 
proprietary company "X" or would evil company "X" likely need a more 
general description of BK capabilities not as it is related to linux 
kernel development.  From those questions, and possibly a few more similar 
ones, a person can determine if the document belongs on the BK web site, 
or in the linux documentation directory.

Like I said, I haven't read the document.  But, if I did and it turned out 
that it was similar to my description of how to use patch to apply my 
aic7xxx patches, IOW if it truly was a limited scope "How to use BK to 
send patches to Linus" and provided just the needed BK information to 
teach the user the real goal, which is how to integrate their work into 
Linus' BK patch process, then I would be greatly offended should the 
document be moved out it's appropriate location in the linux kernel 
documentation directory to some web site where it doesn't really belong.  


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: BK, deltas, snapshots and fate of -pre...

[Anton Altaparmakov]

<cc list trimmed because this is getting silly>

At 19:47 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 20:29, Anton Altaparmakov wrote:
> > >Please don't assign me membership in any anti-bitkeeper crew.  I am not
> > >anti-BitKeeper.  If you must have an epithet, try
> > >"anti-advertising-in-the-tree"
> > >crew.
> >
> > Oh I wasn't refering just to you.
>
>Don't refer to me at all in that context, thankyou.

Ok, no problem.

> > I was refering to the "silently seething"
> > kernel hackers you mentioned but refused to name...
>
>Indeed.  Please get a clue a read the thread.  Sheesh.  No, I'm still not 
>going to name anybody, figure it out yourself.

Anyone not prepared to say their name obviously doesn't care enough about 
the issue therefore their needs need not be considered (pun intended). 
Considering you are speaking for others who as we said before do not care 
enough you don't speak for any one who cares anough so you should stop now. 
Sounds harsh? It's the truth. Think about it. At least you claim to not be 
an anti-bk person but that you speak for the many anti-bk people. I have to 
still read from a single line from one of those imaginary figures you have 
in your head...

> > > > then moving the
> > > > document out won't either, so moving it out would be a waste of time in
> > > > addition to penalizing people who want to use bitkeeper, which is 
> unfair
> > > > and incorrect.
> > >
> > >Changing the documents for a url penalizes you exactly how?
> >
> > You obviously didn't read my mail properly. )-:
> >
> > It is an inconvenience having to go lookup some website instead of having
> > the doc right there.
>
>Good thing you've got a computer to look it up for you then, isn't it.
>(moral of this, don't say really stupid things if you don't want an even
>stupider reply).

I didn't say anything stupid. You did. And your reply is out of context 
because I am talking about disconnectedness.

> > What part of that do you not understand?
>
>I don't understand the part where you find clicking a url difficult.  Please
>tell me it ain't so.

I click URL and wait and wait and I get "could not contact server". No 
internet connection damn!

> > Perhaps you
> > have a 24x7 internet connection, many people don't. Perhaps this is a
> > surpise to you?
>
>OK, let me get this straight.  You've got BitKeeper loaded on your system
>and you've got a kernel tree, and you've made a patch, and you eventually
>want to push it to Linus, or have him pull it, but you can't get the docs
>because you're not connected?  Yeesh.  I can't believe I responded to this.

There are people who work without an internet connection and just carry a 
floppy around to internet cafes / work, etc. On occasion they use a CDR. I 
know people who do that. I do that when I go on holiday. Last holiday 
before leaving I burned the bk tree on a CDR and took it with me together 
with my laptop.

I worked for two weeks completely disconnected. The only means of 
connection would have been going to an internet cafe and using a floppy. I 
chose not to go into an internet cafe, I wanted piece and quiet for two 
weeks. Going to lookup a URL would have wasted time and money. If that 
isn't an inconvenience I don't know what is...

If you can't see how disconnectedness can be a problem perhaps you don't 
take enough holidays? (-;

Best reagards,

Anton


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

Re: BK, deltas, snapshots and fate of -pre...

[Anton Altaparmakov]

At 19:16 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 20:01, Anton Altaparmakov wrote:
> > At 18:17 21/04/02, Daniel Phillips wrote:
> > >The other example specifically mentioned was the CVS documentation for 
> jfs,
> > >and yes, I think that moving those instructions to the web site in 
> question
> > >would make a lot of sense, leaving a URL wherever the docs once were.  By
> > >definition, the CVS instructions will be available on that site as long as
> > >they are useful, and not a moment longer.
> >
> > Personally I find it _extremely_ annoying having to go and lookup web 
> sites
> > which the kernel points me to instead of just having the docs in the 
> kernel
> > in the first place.
>
>But they are instructions for CVS, you're just about to go to some effort to
>download over the web.  Bogus.

I was refering to the BK docs, not CVS and yes, BK works disconected. Which 
was for me one of the important decision points in in switching ntfs driver 
development to it. Together with easy merging of new kernel releases, etc, 
etc...

> > I would much rather see a disclaimer put in Jeff's document stating that
> > "you don't need to use it, gnu patches are just fine with everyone, 
> etc" as
> > others have already suggested.
>
>Well, maybe it's really the best thing, or perhaps it's the best I can hope
>for if I want to stop getting beaten up by the BitKeeper mafia.
>
> > If such disclaimer doesn't appease the anti-bitkeeper crew
>
>Please don't assign me membership in any anti-bitkeeper crew.  I am not
>anti-BitKeeper.  If you must have an epithet, try 
>"anti-advertising-in-the-tree"
>crew.

Oh I wasn't refering just to you. I was refering to the "silently seething" 
kernel hackers you mentioned but refused to name...

> > then moving the
> > document out won't either, so moving it out would be a waste of time in
> > addition to penalizing people who want to use bitkeeper, which is unfair
> > and incorrect.
>
>Changing the documents for a url penalizes you exactly how?

You obviously didn't read my mail properly. )-:

It is an inconvenience having to go lookup some website instead of having 
the doc right there. What part of that do you not understand? Perhaps you 
have a 24x7 internet connection, many people don't. Perhaps this is a 
surpise to you? I have the luxury of living in college provided 
accomodation with local lan connections in place, but this summer I will 
have to move into my own accomodation and it is very well possible I will 
not be able to have 24x7 internet... (I will try to find accomodation where 
I can get a cable modem but it may not be feasible for financial reasons.) 
For anyone not connected to the net it would be an inconvenience to have to 
look up the net. I think that this is self-evident but you obvious don't 
think so...

Best regards,

Anton


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

Re: BK, deltas, snapshots and fate of -pre...

[Anton Altaparmakov]

At 18:17 21/04/02, Daniel Phillips wrote:
>On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 17:44, Larry McVoy wrote:
> > > > On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > > > > I hope I made it clear that I believe BK is helping 
> Linux.  Furthermore, I
> > > > > don't see why Larry should not collect some advertising for his 
> contribution.
> > > > > Within limits.  IMHO, we're on the wrong side of the limit at the 
> moment,
> > > > > and moving further with no sign of moderating.
> > > >
> > > > Yes, because so many purchasing managers spend their time reading the
> > > > Documentation subdirectory of the Linux kernel in order to decide what
> > > > SCM system they should use.
> > > >
> > > > The existence (or non-existence) of the docs has absolutely no 
> marketing
> > > > value to BK.
> > >
> > > So you have no problem with moving them to a website, leaving a url in
> > > SubmittingPatches?
> >
> > Do you have a problem with moving other docs out to Websites, which are
> > describing closed-spec hardware?  Such hardware (and their vendors) are
> > actively anti-open source, yet we have documents describing those, too.
>
>The other example specifically mentioned was the CVS documentation for jfs,
>and yes, I think that moving those instructions to the web site in question
>would make a lot of sense, leaving a URL wherever the docs once were.  By
>definition, the CVS instructions will be available on that site as long as
>they are useful, and not a moment longer.

Personally I find it _extremely_ annoying having to go and lookup web sites 
which the kernel points me to instead of just having the docs in the kernel 
in the first place.

For source code to additional utilities, ok, fair enough, we can't have 
everything in the tree but for documentation, which is a pre-requisite or 
at least a help to understanding something about the kernel, I don't see 
why people have to just be referred out of the tree.

Especially because I only need to look up some URL just when I have no 
internet access for a week or two (and hence have the time to look things 
up)... Having documentation on some random web site is not going to help 
there at all. And guess what? I learned how to use bitkeeper when I was on 
holiday for two weeks. And guess also what? It was Jeff's document which 
was my main guide on how to do it in combination with the bk kernel tree. I 
would have been well pissed off if I had found that I needed to get the 
document off the web after I had gone away...

As a complete different, general point, the probability of documentation 
being updated when it is outside the tree is _much_ lower than when it is 
inside the tree. Admittedly the bitkeeper document itself is unlikely to 
change over time but the scripts helping submissions which are in the same 
place as the document may very well change over time.

I would much rather see a disclaimer put in Jeff's document stating that 
"you don't need to use it, gnu patches are just fine with everyone, etc" as 
others have already suggested.

If such disclaimer doesn't appease the anti-bitkeeper crew then moving the 
document out won't either, so moving it out would be a waste of time in 
addition to penalizing people who want to use bitkeeper, which is unfair 
and incorrect.

Finally, if you object to this _that_ much, why not fork the tree remove 
the document, and live happy ever after? Perhaps all the anti-bk people 
will follow you... (-;

Best regards,

Anton


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

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

> > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > How about a URL instead?  Any objection?
> > 
> > Yes.
> 
> And that objection is?  

My objection is that you are singling out one thing that you don't like and
attempting to impose your will on a project which is not under your control.
In the US, we still have some semblance of free speech rights and you are 
stomping all over those rights.  Your position would be somewhat stronger
if you were applying the same metric to all aspects of the kernel, which
you are not, but even then I would object based on the fact that it isn't
your job to police the kernel for political correctness.  If you want that
to be your job, go form your own project and impose whatever rules you see
fit.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

(Linus CC removed)

On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> Focussed on BitKeeper.  It's the license.  Simple, we can all coexist happily,
> and profit from each other's endeavors, but our little commons here should not
> be carrying Bitkeeper ads.

Should we remove all mention of .com email addresses too?

On of the very few requirements of my job at mandrakesoft is to use
a mandrakesoft.com email address... as advertisement.  Many other
email addresses are used similarly.  reiserfs included _blatant_
advertisements in printk, for the sponsors of the code.  A ton of
other code has similar advertisements, though not at

Should we remove all advertisements from the kernel?  A Big Penguin
would probably object to the removal of this printk advertisement
for Swansea:

	Linux NET4.0 for Linux 2.4
	Based upon Swansea University Computer Society NET3.039

If the answer is no, then you are targetting BitKeeper specifically...

The Linux kernel is not a commons.  Thankfully.  Linus prevents that.
Otherwise, we _would_ have the infamous Tragedy of the Commons.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> > > > Do you have a problem with moving other docs out to Websites, which are
> > > > describing closed-spec hardware?  Such hardware (and their vendors) are
> > > > actively anti-open source, yet we have documents describing those, too.
> 
> As far as I can see: question about moving the jfs CVS docs out of the tree
> as well, answered fully and, imho, correctly by me.

What part of "describing closed-spec hardware" did you not understand?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 07:37:47PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:19, Jeff Garzik wrote:
> > (Linus removed from CC)
> > 
> > On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> > > On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > > > Do you have a problem with moving other docs out to Websites, which are
> > > > describing closed-spec hardware?  Such hardware (and their vendors) are
> > > > actively anti-open source, yet we have documents describing those, too.
> > > 
> > > The other example specifically mentioned was the CVS documentation for jfs,
> > > and yes, I think that moving those instructions to the web site in question
> > > would make a lot of sense, leaving a URL wherever the docs once were.  By
> > > definition, the CVS instructions will be available on that site as long as
> > > they are useful, and not a moment longer.
> > > 
> > > This is all irrespective of the fact that CVS does not have the problem of
> > > having a restrictive license, but since you asked...
> > 
> > Well, in order to prove you're being fair, your patch should have
> > included removal of those CVS instructions, too :)
> 
> Would it satisfy you (just talking about *you* now) if I ammended it so it did?
> This would be purely to satisfy you of course, since the license issue does not
> exist with CVS, and it would be contingent on negotiating a new home for the
> jfs CVS instructions.
> 
> > That's the point Linus made in his first message, and one I agree with.
> 
> You want it, you got it.  Deal?

You are misunderstanding me and Linus.

The point is that your patch was singling out BK unfairly,
and the mention of CVS was an _example_ of that.

I do not support the removal of the BK docs, nor the CVS docs.
Linus does not appear to, either.

In fact, if someone wrote a general doc describing productive kernel
development under CVS, I would support the addition of that.  (though
Linus may not, since it's not vaguely equivalent to SubmittingPatches)

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> How about a URL instead?  Any objection?

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

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

(Linus removed from the CC... nudge nudge, Larry and Daniel)


On Mon, Apr 22, 2002 at 10:17:50AM -0700, Larry McVoy wrote:
> Why don't you ask Jeff to stick in the doc saying something like
> 
>     BitKeeper is not free software.  You may use it for free, subject
>     to the licensing rules (bk help bkl will display them), but it is
>     not open source.  If you feel strongly about 100% free software
>     tool chain, then don't use BitKeeper.  Linus has repeatedly stated
>     that he will continue to accept and produce traditional "diff -Nur"
>     style patches.  It is explicitly not a requirement that you use
>     BitKeeper to do kernel development, people may choose whatever tool
>     works best for them.

Roman Zippel suggested something like this, I am perfectly fine with
putting a "disclaimer" like this in the doc.

It was _never_ my intention to imply that BK is required for kernel
development.

I want to actively dispute that notion... while encouraging its use,
since I believe BK is a useful tool for kernel development.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > Do you have a problem with moving other docs out to Websites, which are
> > describing closed-spec hardware?  Such hardware (and their vendors) are
> > actively anti-open source, yet we have documents describing those, too.
> 
[response not answering the question deleted]

Daniel, this is yet another example of you not answering the question asked.
Let's try it again.  Please answer the following question, since you seem
to have elected yourself to position of license policeman:

There are number of different places in the linux kernel source tree
where there are docs/code/whatever related to non-open source features
included in the tree.  Are you advocating a "cleansing" of all of these
or are you specifically targetting BitKeeper.  If you are only focussed
on BitKeeper, why?

That's two questions, just answer those, nothing but those.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

(Linus removed from CC)

On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > Do you have a problem with moving other docs out to Websites, which are
> > describing closed-spec hardware?  Such hardware (and their vendors) are
> > actively anti-open source, yet we have documents describing those, too.
> 
> The other example specifically mentioned was the CVS documentation for jfs,
> and yes, I think that moving those instructions to the web site in question
> would make a lot of sense, leaving a URL wherever the docs once were.  By
> definition, the CVS instructions will be available on that site as long as
> they are useful, and not a moment longer.
> 
> This is all irrespective of the fact that CVS does not have the problem of
> having a restrictive license, but since you asked...

Well, in order to prove you're being fair, your patch should have
included removal of those CVS instructions, too :)  That's the point
Linus made in his first message, and one I agree with.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 06:21:27PM +0200, Daniel Phillips wrote:
> > It's not my call to make.
> 
> I know that.  I was wondering if *you personally* would have any objection.

Daniel, I won't be nagged into supporting your point of view, sorry.
I didn't even know that the doc was in the tree until you raised the
point.  I don't see a problem with it being in the tree and I do *not*
support your attempts to remove it.

You seem to think it has some great value to BitMover to have it in
the tree.  Sorry, that's not true.  It's true to some small extent, in
that it may reduce the number of support queries that we get related to
the kernel.  So we'd prefer it stayed in the tree.

Why don't you ask Jeff to stick in the doc saying something like

    BitKeeper is not free software.  You may use it for free, subject
    to the licensing rules (bk help bkl will display them), but it is
    not open source.  If you feel strongly about 100% free software
    tool chain, then don't use BitKeeper.  Linus has repeatedly stated
    that he will continue to accept and produce traditional "diff -Nur"
    style patches.  It is explicitly not a requirement that you use
    BitKeeper to do kernel development, people may choose whatever tool
    works best for them.

> > Take it up with the people who own the tree.
> 
> That's all of us, last I heard.  Administrating it is, of course, another story.

You are, as has been repeatedly pointed out, able to create your own tree,
with your own rules, and see if you develop a following.  It's way past time
that you do so, it should be crystal clear to anyone with a clue that you
are not the administrator of this tree.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> On Monday 22 April 2002 17:44, Larry McVoy wrote:
> > On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > > I hope I made it clear that I believe BK is helping Linux.  Furthermore, I
> > > don't see why Larry should not collect some advertising for his contribution.
> > > Within limits.  IMHO, we're on the wrong side of the limit at the moment,
> > > and moving further with no sign of moderating.
> > 
> > Yes, because so many purchasing managers spend their time reading the
> > Documentation subdirectory of the Linux kernel in order to decide what
> > SCM system they should use.
> > 
> > The existence (or non-existence) of the docs has absolutely no marketing
> > value to BK.
> 
> So you have no problem with moving them to a website, leaving a url in
> SubmittingPatches?

Do you have a problem with moving other docs out to Websites, which are
describing closed-spec hardware?  Such hardware (and their vendors) are
actively anti-open source, yet we have documents describing those, too.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > The existence (or non-existence) of the docs has absolutely no marketing
> > value to BK.
> 
> So you have no problem with moving them to a website, leaving a url in
> SubmittingPatches?

It's not my call to make.  Take it up with the people who own the tree.

Personally, I think a patch like this is more of what you need:

===== bk-kernel-howto.txt 1.2 vs edited =====
--- 1.2/Documentation/BK-usage/bk-kernel-howto.txt      Fri Mar 15 09:08:54 2002
+++ edited/bk-kernel-howto.txt  Mon Apr 22 09:04:26 2002
@@ -1,5 +1,9 @@
+To placate some pedantic people who feel that this document is an
+advertisement, the name of the source management system has been
+replaced with "groovy SCM".
 
-                  Doing the BK Thing, Penguin-Style
+
+                  Doing the groovy SCM Thing, Penguin-Style
 
 
 
@@ -11,48 +15,48 @@
 Due to the author's background, an operation may be described in terms
 of CVS, or in terms of how that operation differs from CVS.
 
-This is -not- intended to be BitKeeper documentation.  Always run
+This is -not- intended to be groovy SCM documentation.  Always run
 "bk help <command>" or in X "bk helptool <command>" for reference
 documentation.
 
 
-BitKeeper Concepts
-------------------
+groovy SCM Concepts
+-------------------

etc.

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

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> I hope I made it clear that I believe BK is helping Linux.  Furthermore, I
> don't see why Larry should not collect some advertising for his contribution.
> Within limits.  IMHO, we're on the wrong side of the limit at the moment,
> and moving further with no sign of moderating.

Yes, because so many purchasing managers spend their time reading the
Documentation subdirectory of the Linux kernel in order to decide what
SCM system they should use.

The existence (or non-existence) of the docs has absolutely no marketing
value to BK.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Russell King]

On Sun, Apr 21, 2002 at 03:05:27PM +0200, Daniel Phillips wrote:
> On Sunday 21 April 2002 10:31, Russell King wrote:
> > We have hourly snapshots, thanks to the work David Woodhouse and
> > Rik van Riel did at a moments notice.  Does this satisfy your
> > concerns above?
> 
> Interesting.  How does that work, exactly?

If you want details of this, go grab the publically accessible
scripts that these guys worked on.  Just don't ask me.

I'm no longer interested in this BK anti BK crap.  Take it elsewhere.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Tuesday 23 April 2002 06:57, Andre Pang wrote:
> On Sun, Apr 21, 2002 at 08:16:28PM +0200, Daniel Phillips wrote:
>     11. Pulling BK doc in the tree would make less users aware of
> 	BK and thus solve most of these problems

Brilliant summary, up to point 11.  A url to the 'Using Bitkeeper with
Linux' docs/scripts would stay in the tree, perhaps in the
SubmittingPatches file, so there is no attempt to cut down BK usage
by hiding documentation.  There is an attempt to keep the tree free of
commercial advertising, and no I am *not* going to go attack what you
or anyone else perceives as a problem with ReiserFS.  Anybody who is
concerned about that can speak for themselves.

> So, what are the problems that can be solved?  Perhaps adding
> some lines to the BitKeeper doc saying "Unless your patch is
> trivial, please post it to linux-kernel for peer review, because
> this is one of the great strengths of open-source software" would
> be a good idea.

Yes, that would help.

> Supply a shell script in the BK docs which generates a diff-style
> patch and send that off to LKML if you update a BK tree.

Too much 'automatic' traffic for lkml, however something similar is
being worked on by the patchbot group.

> Add that patch which was floating around earlier in the thread
> saying that BK is non-free, and that it is only one alternative
> for doing things.

Yes.

> Or maybe set up another separate mailing list (e.g.
> linux-bk-updates), run by a bot which emails that list whenever
> a patch to a BK tree is submitted.  People who don't use BK, such
> as yourself, can subscribe to the list and initiate discussion on
> such patches by bringing the mail to linux-kernel.

Right, linux-patches, with a view to providing notification of
*proposed* patches before they become formally part of a tree.

> BK is here to stay; no doubt about that.  Doing something
> completely controversial like removing the docs for it is not the
> way to go if you want to solve the problems that it has created.
> I think it's good that you vocalised the problems with using BK,
> but you're going about fixing the symptoms in the wrong way.

Probably.  A deeper fix is needed, indeed.

> I'm sure people (Jeff and Larry, in particular) would be much
> more happy if you addressed those issues by adding things to the
> BK docs highlighting the problems that it causes, and include
> ways of fixing them.  You say that you're not anti-BK, and
> I believe you're not, but your actions are indicating otherwise.

Sorry, I am anti-bitkeeper now; two days ago I was not.

I now believe that the move to BitKeeper constitutes a creeping
takeover of the means of developing linux by commercial interests.
I did not believe that going in, but went out of his way to convince
me of it.  I should have realized earlier, during the period in
which Larry was putting considerable energy into discrediting and
discouraging the Arch project, and Subversion for that matter.

I now firmly believe that we must have our own tools, and that we are
in a transitory period where we are using proprietary tools because
free ones are not available.  So the path forward is to build the
tools we need, or join with others to build them.  That's the path I'm
taking.  I will not suggest that anyone stop using BitKeeper, and
especially, I will not advocate that Linus stop using BitKeeper.  We
need the efficiency, and until there is a functional replacement,
BitKeeper is the only game in town.

> BK is not the problem: BK is a new way of working with Linus,
> which is causing problems for people who are used to the non-BK
> way of working with him.  Fix that problem, not BK itself.

Thanks for your advice.

Hopefully this is the end of the thread.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Rusty Russell]

On Sun, 21 Apr 2002 00:05:27 -0400 (EDT)
Alexander Viro <viro@math.psu.edu> wrote:

> As one of the guys who doesn't use BK _and_ had submitted a lot of patches
> since Linus had started using it, I'm probably qualified to tell whether it
> hurts or not, right?  Well, it doesn't.  So far the only difference was
> in the quality (and latency) of changelogs and that was definitely welcome.

"me too".  Actually, I found it easier to get the Trivial patches in, and
about the same for per-cpu and futex patches.  I don't bk.

When patches didn't go in, it's more due to Mingo Theorum[1] than being
non-bk.  And that's a Good Thing for calibrating my coding tastes upwards.

Rusty.
[1] Message-ID: <Pine.LNX.4.33.0201291324560.3610-100000@localhost.localdomain>
-- 
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Re: BK, deltas, snapshots and fate of -pre...

[Pavel Machek]

Hi!

> > How about a URL instead?  Any objection?
> 
> Yes.  Why should I have to cut and paste (assuming I'm in X) or
> write down and transpose some URL from a file that used to contain

And why should I waste my disk space with BK docs?

When they are on website, they can be easily updated, and they don't waste
space/bandwidth for people that do not care. As BK only makes sense if you
have good connection to the Net, its more easily put on web page than other
docs (other docs is mostly usefull even for people without net).

So IMO bk docs should go to website somewhere.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: BK, deltas, snapshots and fate of -pre...

[Pavel Machek]

Hi!

> > The well-defined resync points are the 2.5.N releases.  If -pre goes away,
> > then the dot-releases might need to come a little closer together, that's all.
> 
> I agree.
> 
> I've told myself that I shouldn't have done "-preX" releases at all in
> 2.5.x - the "real" numbers have become diluted by them, and I suspect the
> -pre's are really just because I got used to making them during the
> over-long 2.4.x time.

I believe -pre's are still important. Daily snapshots are too likely to be
broken, and "real" releases are different from -pre ones (with *usefull*
difference): you can ignore -pre release, but you can't ignore real release
(because real releases are relative to each other).

Having slightly more frequent real releases would be nice, but I believe
it is not feasible to make them as common as pre- patches.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 23:21, Doug Ledford wrote:
> On Sun, Apr 21, 2002 at 11:05:11PM +0200, Daniel Phillips wrote:
> > Would everybody with no mouse on their system please stand up, and leave
> > the room.
> > 
> > Seriously, you're trolling.
> 
> No more so than your bandwidth argument...pot->kettle.

I'll stick with the bandwidth argument.  99.99% of the people who download Linux
don't need the Bitkeeper docs at all.  Waste of cycles.  Think what happens to
the source if we don't care at all about extra bulk.  Hint: I've got a 75 meg
compressed source file here from an embedded systems vendor that has about 5
meg that I actually use.

If Jeff wants to give me only 2.95 out of 3 points for my arguments, that's
his business.

> > > I put my docs on my web site because that's what I owned/controlled and it 
> > > was relevant to people already coming to my web site.  That in no way 
> > > indicates that your position is correct, especially since you ignored to 
> > > truly relevant item in my email:
> > 
> > I'm actually trying to do a little work as well as handle all the input
> > from the Bitkeeper moonies, thankyou.
> > 
> > Err, did I say moonies, sorry I meant advocates, err, apologists, umm.
> 
> Right, nice personal attack to deflect the arguments I actually wrote.

It was fuhhhhhneee.  Get a grip please.

> BTW, I've never used BK.  I've never actually even gone to the BK web 
> site.  That's probably why I haven't bothered to read the submitting 
> patches using BK *HOWTO* doc in the kernel doc area.

Well.  Could always start now, and please count the places in the thread
where I say BitKeeper is a good thing for Linux.  Commerical breaks in 
in the source tree itself are considerably less good.

> > > > > information so that the whole picture, from start to finish, was all 
> > > > > described in one easy to access place.
> > > 
> > > One place for relevant information, from start to finish.
> > 
> > Right.  bitkeeper.com, any argument?
> 
> Yeah.  I'll go to bitkeeper.com to learn about how to use bitkeeper.  I 
> don't expect nor want to go there to learn about how to send a patch to 
> Linus.  It's not the appropriate venue for that information.

Could have fooled me.  I thought that getting Linux developers to endorse
BitKeeper was a key part of Larry's business plan, which, by the way, I
fully support.  I just don't support the part that turns Documentation
into a billboard.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 22:57, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 10:42:46PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> > > On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > > > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > > > Should we remove all advertisements from the kernel?  A Big Penguin
> > > > > would probably object to the removal of this printk advertisement
> > > > > for Swansea:
> > > > > 
> > > > > 	Linux NET4.0 for Linux 2.4
> > > > > 	Based upon Swansea University Computer Society NET3.039
> > > > > 
> > > > > If the answer is no, then you are targetting BitKeeper specifically...
> > > > 
> > > > Excellent point.  If the BitKeeper advertising in the kernel source were
> > > > held to that level, I would be satisfied.
> > > 
> > > <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> > > pointless advertisement.
> > 
> > You'd want to get rid of the url that points at your docs?
> 
> "that level" was assuming you were referring to the URL-free printk
> advertisement I quoted above.

Oh, I was thinking "a few lines", regardless of content.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 22:53, Doug Ledford wrote:
> On Sun, Apr 21, 2002 at 10:29:19PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 21:53, Doug Ledford wrote:
> > > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > > How about a URL instead?  Any objection?
> > > 
> > > Yes.  Why should I have to cut and paste (assuming I'm in X) or
> > > write down
> > 
> > What???   What kind of system are you running?  Err... redhat supports
> > cut and paste I thought. <-- funnny.
> 
> Depends on what you use to read the file containing the URL.  Obviously, 
> if I'm Al Viro I'm on a text console and wouldn't use a mouse if you 
> cemented it in my hand, so cut and paste isn't an option.

Would everybody with no mouse on their system please stand up, and leave
the room.

Seriously, you're trolling.

> > > and transpose some URL from a file that used to contain
> > > the exact instructions I need in order to get those instructions now
> > 
> > Bogus.  You'd have to do the same to edit/list the file.
> 
> No, I wouldn't.  In one case I would do "less <filename>" and in the other 
> case I would do "less <filename>", ohh damn, it's only a pointer to the 
> real docs, switch to X or install lynx on my system, go to URL.  It's a 
> matter of having the appropriate documentation at hand vs. having to 
> retrieve it.

lynx <url>

What's the difference?

> I put my docs on my web site because that's what I owned/controlled and it 
> was relevant to people already coming to my web site.  That in no way 
> indicates that your position is correct, especially since you ignored to 
> truly relevant item in my email:

I'm actually trying to do a little work as well as handle all the input
from the Bitkeeper moonies, thankyou.

Err, did I say moonies, sorry I meant advocates, err, apologists, umm.
Sorry, I just meant I've been getting a lot of email lately, some of it
is too long to read every word.  Unless you are a spectacularly good
writer, expect some of your deathless prose to drop through the cracks.

> > > information so that the whole picture, from start to finish, was all 
> > > described in one easy to access place.
> 
> One place for relevant information, from start to finish.

Right.  bitkeeper.com, any argument?

> > You haven't read the thread closely, this was described before.  There are
> > one documentation file and three scripts.  The documentation file is about
> > half general description of Bitkeeper - which is quite unabashedly
> > promotional and the author does describe it as an adverisement - and half
> > how to use for submitting kernel patches.
> 
> Now, now Daniel, let's not put words into people's mouths.  Jeff has said 
> he does like BitKeeper, and he said he could *see how you think his 
> description is an advertisement* but that he *didn't write it as an 
> advertisement*.

He agreed it was an advertisement.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Skip Ford]

Russell King wrote:
> On Sun, Apr 21, 2002 at 12:40:11AM -0400, Skip Ford wrote:
> > That's only 1 aspect.  The frustrating part is bug reports mailed to the
> > list getting a response of "oh, that's fixed in the latest bk tree."
> > 
> > Daily snapshots would be great.
> 
> We have hourly snapshots, thanks to the work David Woodhouse and
> Rik van Riel did at a moments notice.  Does this satisfy your
> concerns above?

It does as long as those hourly snapshots are the official kernel.  If
the snapshots are different than what's available at kernel.org then the
problem is still there.

We need to have more frequent releases so the current kernel is
available to everyone, including non-bk users.  It doesn't matter
to me what it's called (snapshots, -pre, regular releases 2.5.X).

-- 
Skip

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 22:18, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 08:05:25PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> > > Should we remove all advertisements from the kernel?  A Big Penguin
> > > would probably object to the removal of this printk advertisement
> > > for Swansea:
> > > 
> > > 	Linux NET4.0 for Linux 2.4
> > > 	Based upon Swansea University Computer Society NET3.039
> > > 
> > > If the answer is no, then you are targetting BitKeeper specifically...
> > 
> > Excellent point.  If the BitKeeper advertising in the kernel source were
> > held to that level, I would be satisfied.
> 
> <chuckle> -- and if that occurred, _I_ would fight to remove it as a
> pointless advertisement.

You'd want to get rid of the url that points at your docs?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 21:53, Doug Ledford wrote:
> On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > How about a URL instead?  Any objection?
> 
> Yes.  Why should I have to cut and paste (assuming I'm in X) or
> write down

What???   What kind of system are you running?  Err... redhat supports
cut and paste I thought. <-- funnny.

> and transpose some URL from a file that used to contain
> the exact instructions I need in order to get those instructions now

Bogus.  You'd have to do the same to edit/list the file.

> So let me tell a little story for a second.  I used to maintain the 
> aic7xxx driver.  In so doing, I created a web site for disseminating my 
> patches and what not.  As people would grab my patches, I would get 
> regular (and annoying to me) questions like "how do I apply your 
> patches", "what patch version should I grab", "how do I compile my 
> kernel after I apply your patch," etc.  So, after enough of the same 
> question, the question itself becomes a "frequently asked question".  So, 
> I made a few docs that attempted to answer these questions and put them on 
                                                                 ^^^^^^^^^^^
> my web site along side the patches themselves.  These docs most generally 
  ^^^^^^^^^^^
> described how the linux kernel versioning worked, how my patch versioning 
> worked, how to select patches, how to use the patch command, etc.  Now, 
> obviously, some of this was very aic7xxx specific, but large parts of it 
> were background knowledge that was required in order to apply that 
> specific aic7xxx information.  It made sense therefore to include that 
> information so that the whole picture, from start to finish, was all 
> described in one easy to access place.  So, as a result, even though I 
> could have pointed the reader to the patch man page, I didn't bother to 
> make them read a large document full of options and possible means of 
> screwing things up when all I really wanted them to know was "All of my 
> patches are generated so that if you go into the top level of the linux 
> source directory and type 'patch -p1 < patchname' then things will work 
> properly".

Thanks for your story.  It's exactly what I've suggested, put the BK docs
on a web site.

> So, I haven't read this "BitKeeper advertisement" you have been 
> complaining about.  However, I have heard claims that it deals more 
> specifically with how to interface your own personal BK setup with Linus 
> than it does with usage of BK in general.  If I were to sit down and read 
> that document now, the questions I would attempt to answer would be things 
> like A) does it describe BK in general and how to set it up for general 
> use, or does it describe how to set BK up for a specific use related to 
> kernel developement,

You haven't read the thread closely, this was described before.  There are
one documentation file and three scripts.  The documentation file is about
half general description of Bitkeeper - which is quite unabashedly
promotional and the author does describe it as an adverisement - and half
how to use for submitting kernel patches.  No matter, Bitkeeper is *all*
nonfree and the issue is whether documentation for it should live in our
kernel tree or on a web site.  I.e., should Linux be advertising Bitkeeper
through the kernel source.

As has been pointed out, there are other places in the kernel where .com's
and the like appear in the form of url's.  If that's the noise level the
Bitkeeper documentation stayed at, then fine.  But that's not what we have.

> B) does it describe how that setup is then integrated 
> into a kernel patch submission process, C) is the description relevant 
> to all BK setups (not just linux kernel setups) or is it geared 
> specifically towards linux kernel setups,

It's partly generic, partly specific.  Read it, please, it's here:

http://lxr.linux.no/source/Documentation/BK-usage/bk-kernel-howto.txt?v=2.5.7

(Oh gosh, a url! Run away!)

> and D) would the description of 
> BK found in the document be of general use to BK deployments in evil 
> proprietary company "X" or would evil company "X" likely need a more 
> general description of BK capabilities not as it is related to linux 
> kernel development.  From those questions, and possibly a few more similar 
> ones, a person can determine if the document belongs on the BK web site, 
> or in the linux documentation directory.

E) What is the license?

> Like I said, I haven't read the document.  But, if I did and it turned out 
> that it was similar to my description of how to use patch to apply my 
> aic7xxx patches, IOW if it truly was a limited scope "How to use BK to 
> send patches to Linus" and provided just the needed BK information to 
> teach the user the real goal, which is how to integrate their work into 
> Linus' BK patch process, then I would be greatly offended should the 
> document be moved out it's appropriate location in the linux kernel 
> documentation directory to some web site where it doesn't really belong.  

Because you can't follow a url?  Give me a break.

Bogus.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 20:29, Anton Altaparmakov wrote:
> >Please don't assign me membership in any anti-bitkeeper crew.  I am not
> >anti-BitKeeper.  If you must have an epithet, try 
> >"anti-advertising-in-the-tree"
> >crew.
> 
> Oh I wasn't refering just to you.

Don't refer to me at all in that context, thankyou.

> I was refering to the "silently seething" 
> kernel hackers you mentioned but refused to name...

Indeed.  Please get a clue a read the thread.  Sheesh.  No, I'm still not going
to name anybody, figure it out yourself.

> > > then moving the
> > > document out won't either, so moving it out would be a waste of time in
> > > addition to penalizing people who want to use bitkeeper, which is unfair
> > > and incorrect.
> >
> >Changing the documents for a url penalizes you exactly how?
> 
> You obviously didn't read my mail properly. )-:
> 
> It is an inconvenience having to go lookup some website instead of having 
> the doc right there.

Good thing you've got a computer to look it up for you then, isn't it.
(moral of this, don't say really stupid things if you don't want an even
stupider reply).

> What part of that do you not understand?

I don't understand the part where you find clicking a url difficult.  Please
tell me it ain't so.

> Perhaps you 
> have a 24x7 internet connection, many people don't. Perhaps this is a 
> surpise to you?

OK, let me get this straight.  You've got BitKeeper loaded on your system
and you've got a kernel tree, and you've made a patch, and you eventually
want to push it to Linus, or have him pull it, but you can't get the docs
because you're not connected?  Yeesh.  I can't believe I responded to this.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Linus Torvalds]

On Sat, 20 Apr 2002, Rob Landley wrote:
>
> The well-defined resync points are the 2.5.N releases.  If -pre goes away,
> then the dot-releases might need to come a little closer together, that's all.

I agree.

I've told myself that I shouldn't have done "-preX" releases at all in
2.5.x - the "real" numbers have become diluted by them, and I suspect the
-pre's are really just because I got used to making them during the
over-long 2.4.x time.

For development stuff, I think I personally would rather have dailies
together with a higher frequency of "real" releases. But as it is now
(because it isn't automated), the dailies would be a lot of work..

		Linus

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 02:24:47PM -0400, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 11:14:50AM -0700, Larry McVoy wrote:
> > On Sun, Apr 21, 2002 at 02:07:53PM -0400, Jeff Garzik wrote:
> > > Triggers are completely useless for "show me what the next-to-last
> > > 'bk pull' downloaded, in GNU patch style."  
> 
> > All you need to do is save the starting and ending cset revs as keys,
> > and then send those into bk export -tpatch.  So a trigger which saved
> > top of trunk on a stack is all you need, the rest is a tiny amount of
> > perl/shell.  Write it, send it to me, if people like it, we'll roll it
> > into the mainline release.
> 
> In order to implement multiple 'bk undo' stack as you described, you
> need to store or deduce that info anyway.  If I wrote it, wouldn't I be
> duplicating work (or doing work for you)?

Perhaps.  You'd also be getting your needs met on your schedule, not mine.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 11:14:50AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 02:07:53PM -0400, Jeff Garzik wrote:
> > Triggers are completely useless for "show me what the next-to-last
> > 'bk pull' downloaded, in GNU patch style."  

> All you need to do is save the starting and ending cset revs as keys,
> and then send those into bk export -tpatch.  So a trigger which saved
> top of trunk on a stack is all you need, the rest is a tiny amount of
> perl/shell.  Write it, send it to me, if people like it, we'll roll it
> into the mainline release.

In order to implement multiple 'bk undo' stack as you described, you
need to store or deduce that info anyway.  If I wrote it, wouldn't I be
duplicating work (or doing work for you)?

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 20:01, Anton Altaparmakov wrote:
> At 18:17 21/04/02, Daniel Phillips wrote:
> >The other example specifically mentioned was the CVS documentation for jfs,
> >and yes, I think that moving those instructions to the web site in question
> >would make a lot of sense, leaving a URL wherever the docs once were.  By
> >definition, the CVS instructions will be available on that site as long as
> >they are useful, and not a moment longer.
> 
> Personally I find it _extremely_ annoying having to go and lookup web sites 
> which the kernel points me to instead of just having the docs in the kernel 
> in the first place.

But they are instructions for CVS, you're just about to go to some effort to
download over the web.  Bogus.

> I would much rather see a disclaimer put in Jeff's document stating that 
> "you don't need to use it, gnu patches are just fine with everyone, etc" as 
> others have already suggested.

Well, maybe it's really the best thing, or perhaps it's the best I can hope
for if I want to stop getting beaten up by the BitKeeper mafia.

> If such disclaimer doesn't appease the anti-bitkeeper crew

Please don't assign me membership in any anti-bitkeeper crew.  I am not
anti-BitKeeper.  If you must have an epithet, try "anti-advertising-in-the-tree"
crew.

> then moving the 
> document out won't either, so moving it out would be a waste of time in 
> addition to penalizing people who want to use bitkeeper, which is unfair 
> and incorrect.

Changing the documents for a url penalizes you exactly how?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 02:07:53PM -0400, Jeff Garzik wrote:
> Triggers are completely useless for "show me what the next-to-last
> 'bk pull' downloaded, in GNU patch style."  

All you need to do is save the starting and ending cset revs as keys,
and then send those into bk export -tpatch.  So a trigger which saved
top of trunk on a stack is all you need, the rest is a tiny amount of
perl/shell.  Write it, send it to me, if people like it, we'll roll it
into the mainline release.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:53, Larry McVoy wrote:
> > > On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > > > How about a URL instead?  Any objection?
> > > 
> > > Yes.
> > 
> > And that objection is?  
> 
> My objection is that you are singling out one thing that you don't like and
> attempting to impose your will on a project which is not under your control.
> In the US, we still have some semblance of free speech rights and you are 
> stomping all over those rights.

<confused>
First I don't control it, then I'm stomping on rights.  What the?

> Your position would be somewhat stronger
> if you were applying the same metric to all aspects of the kernel, which
> you are not,

If I were able, I'd fix all bugs in the kernel at once too.  But I am not able
to do that so I do what I can.  Anyway, there is only one non-open tool in the
toochain, it attracts special attention.

> but even then I would object based on the fact that it isn't
> your job to police the kernel for political correctness.  If you want that
> to be your job, go form your own project and impose whatever rules you see
> fit.

OK, so you are now requiring that I fix everything that is wrong with the
kernel before you reinstate your offer?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 10:57:06AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 01:49:55PM -0400, Jeff Garzik wrote:
> > I know, but graphical is useless to me...
> > Give me text/plain GNU-style patches, that I can spit out without
> > requiring X. :)
> 
> I did.  Install those triggers and you've got it.  Sorry to sound
> uncooperative but the trigger mechanism is there to handle this, and
> email notification, and automatic mirroring, and ...

(did you miss that we're off on a tangent?  :))

If we are talking about 'bk diffs -C' for Linus, agreed.

But you started talking about the nifty feature of seeing what you
downloaded in the last 'bk pull'.

Triggers are completely useless for "show me what the next-to-last
'bk pull' downloaded, in GNU patch style."  It's unrealistic to assume
that everybody is gonna set up triggers and their own cset GNU patch
archive, just to provide themselves with this capability.  Especally
when (IMO) bk can generate that stuff on the fly.

If BK knows a single basic unit of information -- the list of csets
downloaded in each 'bk pull' -- then it should be able to generate
patches for those csets.  Or at the very least, have a bk command
that spits out that list of csets, and user-written scripts take it
from there.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:52, Jeff Garzik wrote:
> (Linus CC removed)
> 
> On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> > Focussed on BitKeeper.  It's the license.  Simple, we can all coexist happily,
> > and profit from each other's endeavors, but our little commons here should not
> > be carrying Bitkeeper ads.
> 
> Should we remove all mention of .com email addresses too?
> 
> On of the very few requirements of my job at mandrakesoft is to use
> a mandrakesoft.com email address... as advertisement.  Many other
> email addresses are used similarly.  reiserfs included _blatant_
> advertisements in printk, for the sponsors of the code.  A ton of
> other code has similar advertisements, though not at
> 
> Should we remove all advertisements from the kernel?  A Big Penguin
> would probably object to the removal of this printk advertisement
> for Swansea:
> 
> 	Linux NET4.0 for Linux 2.4
> 	Based upon Swansea University Computer Society NET3.039
> 
> If the answer is no, then you are targetting BitKeeper specifically...

Excellent point.  If the BitKeeper advertising in the kernel source were
held to that level, I would be satisfied.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:48, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:44:43PM +0200, Daniel Phillips wrote:
> > > > > Do you have a problem with moving other docs out to Websites, which are
> > > > > describing closed-spec hardware?  Such hardware (and their vendors) are
> > > > > actively anti-open source, yet we have documents describing those, too.
> > 
> > As far as I can see: question about moving the jfs CVS docs out of the tree
> > as well, answered fully and, imho, correctly by me.
> 
> What part of "describing closed-spec hardware" did you not understand?

There is no kernel driver for Bitkeeper.  What's your point?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 01:49:55PM -0400, Jeff Garzik wrote:
> I know, but graphical is useless to me...
> Give me text/plain GNU-style patches, that I can spit out without
> requiring X. :)

I did.  Install those triggers and you've got it.  Sorry to sound
uncooperative but the trigger mechanism is there to handle this, and
email notification, and automatic mirroring, and ...

So the mechanism is there, you can make the mechanism do whatever you
want.  If you check in the triggers, they will make their way into each
tree.  So do the first one and write yourself a shell script to use it.
I wouldn't check in the second one.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 10:47:25AM -0700, Larry McVoy wrote:
> > Gnifty... I don't know that I would ever use the multiple-undo stack,
> > but being able to see a single GNU-style patch for set of "what I just
> > downloaded in the last bk pull" would definitely come in handy.
> 
> We have a graphical version of that already, sort of, do a "bk csets"
> after doing a pull.

I know, but graphical is useless to me...
Give me text/plain GNU-style patches, that I can spit out without
requiring X. :)

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:38, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:34:49PM +0200, Daniel Phillips wrote:
> > How about a URL instead?  Any objection?
> 
> Yes.

And that objection is?  You mean you'll refuse to agree with changing
out the files for a url?

If the latter is your position, then say so and I'm out of here.  I won't
even respond, not even to flamebait.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

> Gnifty... I don't know that I would ever use the multiple-undo stack,
> but being able to see a single GNU-style patch for set of "what I just
> downloaded in the last bk pull" would definitely come in handy.

We have a graphical version of that already, sort of, do a "bk csets"
after doing a pull.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 10:39:23AM -0700, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 01:32:25PM -0400, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 10:23:39AM -0700, Larry McVoy wrote:
> > > > IOW, I propose to create a "linuspush" script that replaces his current
> > > > "bk push" command.  Linus pushes batches of csets out at a time,
> > > > make these cset batches the pre-patches...
> > > 
> > > This is easily doable as a trigger.  I'm pretty sure that all you want
> > > is
> > 
> > Not quite -- pre-patches are a one-big-patch, diffed against the most
> > recently released kernel.  
> 
> That's easier yet.
> 
> 	bk diffs -Cv2.5.8
> 
> > One quality of all traditional Linus pre-patches and patches is that
> > if you have N csets modifying a single file, you see N gnu-style diff
> > modifications, instead of the single one you would get when generating
> > the patch via GNU diff.
> 
> Did you get that backwards?  Do you want to see N diffs on a single
> file or do you want one?  We can do either, diffs -C does one.

Didn't get it backwards, I misunderstood BK.

It sounds like 'bk diffs -C' does what I want.


> Also, we're planning on making a "push stack", which remembers the set of
> csets pushed each time, so you can do
> 
> 	bk undo	# remove the last push effects
> 	bk undo	# remove the last push effects
> 	..
> 	bk undo	# remove the clone effects and destroy the repository
> 
> You could use that to generate these patches you want.

Gnifty... I don't know that I would ever use the multiple-undo stack,
but being able to see a single GNU-style patch for set of "what I just
downloaded in the last bk pull" would definitely come in handy.
(substitute "last bk pull" with "a bk pull N pulls ago" if you like)

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:21, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > > Do you have a problem with moving other docs out to Websites, which are
> > > describing closed-spec hardware?  Such hardware (and their vendors) are
> > > actively anti-open source, yet we have documents describing those, too.
> > 
> [response not answering the question deleted]

Huh?  Are you reading the same mails I am?

As far as I can see: question about moving the jfs CVS docs out of the tree
as well, answered fully and, imho, correctly by me.

> Daniel, this is yet another example of you not answering the question asked.
> Let's try it again.  Please answer the following question, since you seem
> to have elected yourself to position of license policeman:
> 
> There are number of different places in the linux kernel source tree
> where there are docs/code/whatever related to non-open source features
> included in the tree.  Are you advocating a "cleansing" of all of these
> or are you specifically targetting BitKeeper.  If you are only focussed
> on BitKeeper, why?

Focussed on BitKeeper.  It's the license.  Simple, we can all coexist happily,
and profit from each other's endeavors, but our little commons here should not
be carrying Bitkeeper ads.

> That's two questions, just answer those, nothing but those.

<counts question marks>  Oh right, one missing.  Well I answered both
questionish things anyway.  Please let me know when you're done with your
cross examination and we can return to my question to you about the URL.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

On Sun, Apr 21, 2002 at 01:32:25PM -0400, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 10:23:39AM -0700, Larry McVoy wrote:
> > > IOW, I propose to create a "linuspush" script that replaces his current
> > > "bk push" command.  Linus pushes batches of csets out at a time,
> > > make these cset batches the pre-patches...
> > 
> > This is easily doable as a trigger.  I'm pretty sure that all you want
> > is
> 
> Not quite -- pre-patches are a one-big-patch, diffed against the most
> recently released kernel.  

That's easier yet.

	bk diffs -Cv2.5.8

> One quality of all traditional Linus pre-patches and patches is that
> if you have N csets modifying a single file, you see N gnu-style diff
> modifications, instead of the single one you would get when generating
> the patch via GNU diff.

Did you get that backwards?  Do you want to see N diffs on a single
file or do you want one?  We can do either, diffs -C does one.

Also, we're planning on making a "push stack", which remembers the set of
csets pushed each time, so you can do

	bk undo	# remove the last push effects
	bk undo	# remove the last push effects
	..
	bk undo	# remove the clone effects and destroy the repository

You could use that to generate these patches you want.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:19, Jeff Garzik wrote:
> (Linus removed from CC)
> 
> On Sun, Apr 21, 2002 at 07:17:45PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> > > Do you have a problem with moving other docs out to Websites, which are
> > > describing closed-spec hardware?  Such hardware (and their vendors) are
> > > actively anti-open source, yet we have documents describing those, too.
> > 
> > The other example specifically mentioned was the CVS documentation for jfs,
> > and yes, I think that moving those instructions to the web site in question
> > would make a lot of sense, leaving a URL wherever the docs once were.  By
> > definition, the CVS instructions will be available on that site as long as
> > they are useful, and not a moment longer.
> > 
> > This is all irrespective of the fact that CVS does not have the problem of
> > having a restrictive license, but since you asked...
> 
> Well, in order to prove you're being fair, your patch should have
> included removal of those CVS instructions, too :)

Would it satisfy you (just talking about *you* now) if I ammended it so it did?
This would be purely to satisfy you of course, since the license issue does not
exist with CVS, and it would be contingent on negotiating a new home for the
jfs CVS instructions.

> That's the point Linus made in his first message, and one I agree with.

You want it, you got it.  Deal?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:17, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 06:21:27PM +0200, Daniel Phillips wrote:
> > > It's not my call to make.
> > 
> > I know that.  I was wondering if *you personally* would have any objection.
> 
> Daniel, I won't be nagged into supporting your point of view, sorry.

I don't want you to, I want you to go on and get rich.  However, you might
possibly be nagged into remembering you made an offer.  Go back and look
at the offer, see if there were strings attached at the time.

> I didn't even know that the doc was in the tree until you raised the
> point.  I don't see a problem with it being in the tree and I do *not*
> support your attempts to remove it.

No, of course not, you're biased.  Expected.

> You seem to think it has some great value to BitMover to have it in
> the tree.  Sorry, that's not true.  It's true to some small extent, in
> that it may reduce the number of support queries that we get related to
> the kernel.  So we'd prefer it stayed in the tree.

How about a URL instead?  Any objection?

> Why don't you ask Jeff to stick in the doc saying something like
> 
>     BitKeeper is not free software.  You may use it for free, subject
>     to the licensing rules (bk help bkl will display them), but it is
>     not open source.  If you feel strongly about 100% free software
>     tool chain, then don't use BitKeeper.  Linus has repeatedly stated
>     that he will continue to accept and produce traditional "diff -Nur"
>     style patches.  It is explicitly not a requirement that you use
>     BitKeeper to do kernel development, people may choose whatever tool
>     works best for them.

Why ask Jeff as opposed to submitting such a patch myself?  The first thing
I'd do is edit out the 'repeatedly', perhaps the whole 'Linus stated' thing,
it's mere rhetoric.

I'd rather see the URL happen though, it just makes so much sense.

> > > Take it up with the people who own the tree.
> > 
> > That's all of us, last I heard.  Administrating it is, of course, another story.
> 
> You are, as has been repeatedly pointed out, able to create your own tree,
> with your own rules, and see if you develop a following.  It's way past time
> that you do so, it should be crystal clear to anyone with a clue that you
> are not the administrator of this tree.

True, but I'm a contributor and so I have an interest in it.  It would be
better if you didn't pursue that line of argument.

How about the URL?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 10:23:39AM -0700, Larry McVoy wrote:
> > IOW, I propose to create a "linuspush" script that replaces his current
> > "bk push" command.  Linus pushes batches of csets out at a time,
> > make these cset batches the pre-patches...
> 
> This is easily doable as a trigger.  I'm pretty sure that all you want
> is

Not quite -- pre-patches are a one-big-patch, diffed against the most
recently released kernel.  Perl could easily parse the linux/Makefile
kernel version and deduce the BK tag (used for diffing) from that.
Finally, I'm not sure that BK can generate these kind of diffs, can it?
One quality of all traditional Linus pre-patches and patches is that
if you have N csets modifying a single file, you see N gnu-style diff
modifications, instead of the single one you would get when generating
the patch via GNU diff.

Also, (assuming Linus wants this, of course) I would want the
'linuspush' script to increment the pre-patch and check in that change,
before pushing.

	Jeff

Re: BK, deltas, snapshots and fate of -pre...

[Larry McVoy]

> IOW, I propose to create a "linuspush" script that replaces his current
> "bk push" command.  Linus pushes batches of csets out at a time,
> make these cset batches the pre-patches...

This is easily doable as a trigger.  I'm pretty sure that all you want
is

	cat > BitKeeper/triggers/pre-incoming.diffs
	#!/bin/sh
	bk prs -hr+ -nd:KEY: ChangeSet > BitKeeper/log/save_key
	^D

	cat > BitKeeper/triggers/post-incoming.diffs
	#!/bin/sh
	
	i=0
	while test -f BitKeeper/tmp/diffs-$i
	do	i=`expr $i + 1`
	done
	bk diffs -C`cat BitKeeper/log/save_key` > BitKeeper/tmp/diffs-$i
	^D

	chmod +x BitKeeper/triggers/*incoming.diffs

The only reason I don't do this on bkbits.net is that regular style patches
eat a lot more bandwidth than BK patches and we can't afford to offer up
the bandwidth for free. 
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 19:10, Jeff Garzik wrote:
> On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > On Monday 22 April 2002 17:44, Larry McVoy wrote:
> > > On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > > > I hope I made it clear that I believe BK is helping Linux.  Furthermore, I
> > > > don't see why Larry should not collect some advertising for his contribution.
> > > > Within limits.  IMHO, we're on the wrong side of the limit at the moment,
> > > > and moving further with no sign of moderating.
> > > 
> > > Yes, because so many purchasing managers spend their time reading the
> > > Documentation subdirectory of the Linux kernel in order to decide what
> > > SCM system they should use.
> > > 
> > > The existence (or non-existence) of the docs has absolutely no marketing
> > > value to BK.
> > 
> > So you have no problem with moving them to a website, leaving a url in
> > SubmittingPatches?
> 
> Do you have a problem with moving other docs out to Websites, which are
> describing closed-spec hardware?  Such hardware (and their vendors) are
> actively anti-open source, yet we have documents describing those, too.

The other example specifically mentioned was the CVS documentation for jfs,
and yes, I think that moving those instructions to the web site in question
would make a lot of sense, leaving a URL wherever the docs once were.  By
definition, the CVS instructions will be available on that site as long as
they are useful, and not a moment longer.

This is all irrespective of the fact that CVS does not have the problem of
having a restrictive license, but since you asked...

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Jeff Garzik]

On Sun, Apr 21, 2002 at 12:05:27AM -0400, Alexander Viro wrote:
> "Linus documentation".
> 
> /me carefully stays the hell away from discussing whether it's a part of
> documented object or not and what would be the license on said object...

A discussion on _Linus_ licensing would be interesting ;-)

To be pedantic, though, I point out that the BK doc at the center of
this flamewar is GPL'd.


> FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is
> a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD
> oopses when..." simply because it's easier to match bug reports that way.
> Having all deltas downloadable as diff+comment is wonderful, but it doesn't
> replace well-defined (and less frequent) resync points.
> 
> Comments?

hmmm hmmm.

My alternative suggestion, which only applies to development series
kernels, is to spit out pre-patches and releases more frequently.
The releases would be your formal testing points by users, and the
pre-patches would be the sync points for developers, and test points
for developers.  i.e. make the current system work as intended ;-)

Maybe write a script for Linus that automates his side of pre-patch
publishing (if it isn't 100% automatic now)?  i.e. my guess is that
pre-patching is currently automated maybe 70% or so...  This automation
I describe increments the pre-patch number in the makefile, checks
that update into BK, rolls a patch, scp's it to master, and posts the
changelog to linux-kernel.  I could roll a demo script that does this,
if people think this is a sane alternative.

IOW, I propose to create a "linuspush" script that replaces his current
"bk push" command.  Linus pushes batches of csets out at a time,
make these cset batches the pre-patches...

	Jeff, who wouldn't mind snapshots either

Re: BK, deltas, snapshots and fate of -pre...

[dean gaudet]

On Sun, 21 Apr 2002, Skip Ford wrote:

> That's only 1 aspect.  The frustrating part is bug reports mailed to the
> list getting a response of "oh, that's fixed in the latest bk tree."

in the pre-bk past i've seen "that's fixed in my tree" with no reference
to how to get "my tree" -- this repeated by many folks, including linus.
for those of you with issues against using bk, you should just pretend
that's what you're reading.  you can even respond with "could you make a
snapshot available?" like folks used to.  you can even go pick up the new
daily snapshots.

so your frustration is either not a new thing, or has been solved.

-dean

Re: BK, deltas, snapshots and fate of -pre...

[dean gaudet]

On Sun, 21 Apr 2002, Ian Molton wrote:

> Extreme example:
>
> Include docs on 'how to avoid a pesky kernel compile' that teach how to
> install windows, not linux because its an 'all in one' install with 'no
> hassle'...

your analogy is false because in the case of the bitkeeper documentation
it explains an alternate which accomplishes something the same as
SubmittingPatches (some would say more, i.e. changelogs).  however Windows
does not accomplish the same as Linux.  for example, i can't run windows
on ARM (i take it from your mail address that ARM is of interest to you).

-dean

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 18:10, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 05:50:25PM +0200, Daniel Phillips wrote:
> > > The existence (or non-existence) of the docs has absolutely no marketing
> > > value to BK.
> > 
> > So you have no problem with moving them to a website, leaving a url in
> > SubmittingPatches?
> 
> It's not my call to make.

I know that.  I was wondering if *you personally* would have any objection.

> Take it up with the people who own the tree.

That's all of us, last I heard.  Administrating it is, of course, another story.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Monday 22 April 2002 17:44, Larry McVoy wrote:
> On Sun, Apr 21, 2002 at 02:53:13PM +0200, Daniel Phillips wrote:
> > I hope I made it clear that I believe BK is helping Linux.  Furthermore, I
> > don't see why Larry should not collect some advertising for his contribution.
> > Within limits.  IMHO, we're on the wrong side of the limit at the moment,
> > and moving further with no sign of moderating.
> 
> Yes, because so many purchasing managers spend their time reading the
> Documentation subdirectory of the Linux kernel in order to decide what
> SCM system they should use.
> 
> The existence (or non-existence) of the docs has absolutely no marketing
> value to BK.

So you have no problem with moving them to a website, leaving a url in
SubmittingPatches?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Andries.Brouwer]

> FWIW, I doubt that dropping -pre completely in favour of dayly snapshots
> is a good idea - "2.5.N-preM oopses when ..." is preferable to
> "snapshot YY/MM/DD oopses when..." simply because it's easier to match
> bug reports that way.

: Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
: please.  "-20Apr02" would suit.

= Well, hopefully it will be "-pre020420" so that increasing kernel
= versions can be sorted...  Also, skip releasing snapshots on days
= when no new deltas have been applied...

In the good old days we had frequent releases.
For example, the 1.3 series went from 1.3.1 to 1.3.100
in eleven months, an average of one patch every three days.

These days we have pre-patches (15 since Feb 1), and patches
(5 since Feb 1) showing an average of one patch every four days.
So, maybe there is a small slow-down, or maybe the testintervals
were chosen unfortunately.

If it is possible to increase the fequency with which patches are
released, then that is very good. There is no need to invent new
numbering schemes. Indeed, I would be in favour of collapsing
the present scheme (for 2.5), and call everything patch-2.5.N,
no reason to panic when N reaches into the hundreds.

The reason I object to "-20Apr02" or "-pre020420" is that it
makes it difficult to see whether there are missing patches
in a given archive. Sequential numbering is better.
(Moreover, there might be two patches on one day, there is a
handful of examples already.)

Concerning the collapsing of patches and prepatches:
For a stable series like 2.4 one needs pre-patches to have a
test-period. For an unstable series like 2.5 pre-patches only
cause a small amount of hassle (the naming is different, they
live in different directories, the patches are not incremental,
incremental patches again have a different naming scheme)
and as far as I can see the presumed advantage, namely that the
result of a patch is more stable than that of a pre-patch, is
absent so far in the 2.5 series. Maybe prepatches should first
be reinvented again shortly before the release of 2.6.

Andries

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Sunday 21 April 2002 10:31, Russell King wrote:
> On Sun, Apr 21, 2002 at 12:40:11AM -0400, Skip Ford wrote:
> > That's only 1 aspect.  The frustrating part is bug reports mailed to the
> > list getting a response of "oh, that's fixed in the latest bk tree."
> > 
> > That's happened a dozen times in the last week...no wonder non-bk users
> > feel out of the loop.  I've been staring at the code for a lot of years
> > and it's finally just starting to make sense to me, now by the time I see
> > it the core hackers have moved on to something else.
> > 
> > Daily snapshots would be great.
> 
> We have hourly snapshots, thanks to the work David Woodhouse and
> Rik van Riel did at a moments notice.  Does this satisfy your
> concerns above?

Interesting.  How does that work, exactly?

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Sunday 21 April 2002 06:20, David S. Miller wrote:
>    From: Ian Molton <spyro@armlinux.org>
>    Date: Sun, 21 Apr 2002 05:31:43 +0100
> 
>    Alexander Viro Awoke this dragon, who will now respond:
>    
>    >  As one of the guys who doesn't use BK _and_ had submitted a lot of
>    >  patches since Linus had started using it, I'm probably qualified to tell
>    >  whether it hurts orSure, except no-one cares about this point.
>    
>    Sure, except no-one cares about this point.
>    
>    the documentation is the 'sticky wicket'...
> 
> Incorrect.  The argument for the documentation was that it along with
> other things wrt. BK create some "barrier to entry" for Linux kernel
> development and almost force someone to use BK.

It was my argument, so I'm qualified to say what it was.  Ian Molton is correct,
your interpretation is strictly secondary.

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Daniel Phillips]

On Sunday 21 April 2002 06:13, Linus Torvalds wrote:
> On Sun, 21 Apr 2002, Alexander Viro wrote:
> > "Linus documentation".
> 
> In fact, we might as well have a whole subdirectory on "Managing Linus",
> which some people have become very good at.

Kidding I hope?  What would a reasonable name be?

In principle, would you accept a patch that moves the Bitkeeper docs to a web
site, with a URL and blurb in SubmittingPatches?

> The BK docs that people are so in a huff over really _are_ less about BK
> itself, and almost entirely about how to use it to interface with me. Read
> them - they are just a "SubmittingPatches" for BK, along with scripts to
> automate it to get the format that I have found to be useful.

For what it's worth, seeing all the Linus-oriented docs together in one
Documentation directory would be helpful in general.  On the downside, it
might appear to be kind of fence around your personal involvement with the
kernel, and it's hard to see why that would be good.

I think you're kidding though, it's hard to tell.

> Rememebr how many times people have asked for automated tools, and for
> getting notification about when I've applied a patch? You've got it. It's
> all there.

I hope I made it clear that I believe BK is helping Linux.  Furthermore, I
don't see why Larry should not collect some advertising for his contribution.
Within limits.  IMHO, we're on the wrong side of the limit at the moment,
and moving further with no sign of moderating.

> Side note: remember the discussion that pushed me to _try_ BK in the first
> place?
> 
> Who was it that said "Be careful what you pray for"? ;)

I pray for a truly free Bitkeeper.  Shows you what damn good praying does ;-)

-- 
Daniel

Re: BK, deltas, snapshots and fate of -pre...

[Ian Molton]

Alexander Viro Awoke this dragon, who will now respond:

> 
>  If you happen to believe in second variant, you have my condolence as
>  long as you don't force your beliefs on everybody else.

What provoked that?!!

Re: BK, deltas, snapshots and fate of -pre...

[Russell King]

On Sun, Apr 21, 2002 at 12:40:11AM -0400, Skip Ford wrote:
> That's only 1 aspect.  The frustrating part is bug reports mailed to the
> list getting a response of "oh, that's fixed in the latest bk tree."
> 
> That's happened a dozen times in the last week...no wonder non-bk users
> feel out of the loop.  I've been staring at the code for a lot of years
> and it's finally just starting to make sense to me, now by the time I see
> it the core hackers have moved on to something else.
> 
> Daily snapshots would be great.

We have hourly snapshots, thanks to the work David Woodhouse and
Rik van Riel did at a moments notice.  Does this satisfy your
concerns above?

I have a suspicion that the problem of conflicting obvious fixes
won't go away.

There's another interesting twist here... - I didn't see any of them on
linux-kernel.

<joke>
I'm a BK user!  GNU patches are being submitted behind my back without
discussion on linux-kernel.  I'm going to remove the SubmittingPatches
document!  It's harming discussion of patches on linux-kernel.
</joke>

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: BK, deltas, snapshots and fate of -pre...

[Alexander Viro]

On Sun, 21 Apr 2002, Ian Molton wrote:

> I take it as blatently obvious that BK isnt a barrier to entry, as the old
> methods still work fine.
> 
> what I /do/ appreciate is that by including directions to proprietary tools
> in the docs, we are heading down a greased incline, so to speak.


Sigh...  When it comes to software there are three systems of beliefs.
One of them:

	* Thou shalt know by your heart that all software sucks.
	* Beware of those who say that their software does not suck, for they
	  are either fools or liars.
	* Beware of those who give you garments and do not allow to mend them,
	  for sooner or later thou shalt find what needs mending.
	* But beware also of those who give you badly rotten garments and say
	  "Thou shalt prefer that above everything, for thou art allowed to
	  mend it".
	* Thou shalt not treat software as a living being, for it is not one.
	* Choose a license of thine liking for sofware thou writest and do not
	  blame those who choose differently for software they write.
	* Know when to say "It can be mended, I shalt do that" and when to
	  say "It is rotten beyond repair".
	* Choose free over non-free when it is better or when thou art willing
	  to fix what is broken.
	* When shit happens, think how to fix it.

Another:

	* All software wants to be free
	* Thou shalt not use non-free software
	* Thou shalt not mention non-free software
	* Thou shalt make all thine software free
	* Thou shalt choose free above working, even if free one is broken
	  beyond repair
	* When shit happens, add new features

and the last one:

	* Our 3133t! K3wl! Software! Does Not Suck!!!
	* Always choose our software above everything else
	* When shit happens, we add new features


If you happen to believe in second variant, you have my condolence as
long as you don't force your beliefs on everybody else.  If you choose
to emulate door-to-door pests^H^H^H^Hreachers - don't expect to be
treated differently.

Re: BK, deltas, snapshots and fate of -pre...

[Andreas Dilger]

On Apr 20, 2002  21:32 -0700, Andrew Morton wrote:
> Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
> please.  "-20Apr02" would suit.  (I suspect if that started happening,
> the -pre's would become redundant.  But that can be decided at a later
> stage)

Well, hopefully it will be "-pre020420" so that increasing kernel
versions can be sorted...  Also, skip releasing snapshots on days
when no new deltas have been applied...

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: BK, deltas, snapshots and fate of -pre...

[Ben Greear]

Ian Molton wrote:

> what I /do/ appreciate is that by including directions to proprietary tools
> in the docs, we are heading down a greased incline, so to speak.
> 
> Extreme example:
> 
> Include docs on 'how to avoid a pesky kernel compile' that teach how to
> install windows, not linux because its an 'all in one' install with 'no
> hassle'...


Come on, it's not like suddenly all the people who contribute to linux
are going to become blind and fall down the slippery slope.  Slippery
slope arguments only work in academic debates, the real world is much too
complex and robust to be susceptible, especially in the long term.

There's bugs to fix and features to add.  The day they are not accepted
because of your patch format, then we can take appropriate action.

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: BK, deltas, snapshots and fate of -pre...

[Ian Molton]

David S. Miller Awoke this dragon, who will now respond:

>    From: Ian Molton <spyro@armlinux.org>
>    Date: Sun, 21 Apr 2002 05:31:43 +0100

>    Sure, except no-one cares about this point.
>    the documentation is the 'sticky wicket'...
> 
> Incorrect.  The argument for the documentation was that it along with
> other things wrt. BK create some "barrier to entry" for Linux kernel
> development and almost force someone to use BK.  That someone just
> submitting patches is somehow "left out".
> 
> Al is showing that these claims are not well founded at all.

hmm.

I take it as blatently obvious that BK isnt a barrier to entry, as the old
methods still work fine.

what I /do/ appreciate is that by including directions to proprietary tools
in the docs, we are heading down a greased incline, so to speak.

Extreme example:

Include docs on 'how to avoid a pesky kernel compile' that teach how to
install windows, not linux because its an 'all in one' install with 'no
hassle'...

see how many people compile their own kernels afer that...

Re: BK, deltas, snapshots and fate of -pre...

[Skip Ford]

Alexander Viro wrote:
> 
> As long as "I've got a bunch of patches affecting <area>. Seeing that you've
> merged stuff touching <area> since the last -pre, resync point would be
> a Good Thing(tm)" works I couldn't care less about BK vs. diff+mail.  So
> far it seems to be working fine.

That's only 1 aspect.  The frustrating part is bug reports mailed to the
list getting a response of "oh, that's fixed in the latest bk tree."

That's happened a dozen times in the last week...no wonder non-bk users
feel out of the loop.  I've been staring at the code for a lot of years
and it's finally just starting to make sense to me, now by the time I see
it the core hackers have moved on to something else.

Daily snapshots would be great.

-- 
Skip

Re: BK, deltas, snapshots and fate of -pre...

[Andrew Morton]

"David S. Miller" wrote:
> 
>    From: Alexander Viro <viro@math.psu.edu>
>    Date: Sun, 21 Apr 2002 00:05:27 -0400 (EDT)
> 
>    FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is
>    a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD
>    oopses when..." simply because it's easier to match bug reports that way.
>    Having all deltas downloadable as diff+comment is wonderful, but it doesn't
>    replace well-defined (and less frequent) resync points.
> 
>    Comments?
> 
> I agree, make the daily's available but don't kill the -pre.

Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
please.  "-20Apr02" would suit.  (I suspect if that started happening,
the -pre's would become redundant.  But that can be decided at a later
stage)

-

Re: BK, deltas, snapshots and fate of -pre...

[Ian Molton]

Alexander Viro Awoke this dragon, who will now respond:

> 
>  As one of the guys who doesn't use BK _and_ had submitted a lot of
>  patches since Linus had started using it, I'm probably qualified to tell
>  whether it hurts orSure, except no-one cares about this point.

Sure, except no-one cares about this point.

the documentation is the 'sticky wicket'...

Re: BK, deltas, snapshots and fate of -pre...

[David S. Miller]

   From: Ian Molton <spyro@armlinux.org>
   Date: Sun, 21 Apr 2002 05:42:53 +0100
   
   what I /do/ appreciate is that by including directions to proprietary tools
   in the docs, we are heading down a greased incline, so to speak.

And Linus is telling everyone it's his tree and if you don't like it
distribute your own tree without the doc file or implement an free
source management system that he can use.

Re: BK, deltas, snapshots and fate of -pre...

[David S. Miller]

   From: Ian Molton <spyro@armlinux.org>
   Date: Sun, 21 Apr 2002 05:31:43 +0100

   Alexander Viro Awoke this dragon, who will now respond:
   
   >  As one of the guys who doesn't use BK _and_ had submitted a lot of
   >  patches since Linus had started using it, I'm probably qualified to tell
   >  whether it hurts orSure, except no-one cares about this point.
   
   Sure, except no-one cares about this point.
   
   the documentation is the 'sticky wicket'...

Incorrect.  The argument for the documentation was that it along with
other things wrt. BK create some "barrier to entry" for Linux kernel
development and almost force someone to use BK.  That someone just
submitting patches is somehow "left out".

Al is showing that these claims are not well founded at all.

Re: BK, deltas, snapshots and fate of -pre...

[Linus Torvalds]

On Sun, 21 Apr 2002, Alexander Viro wrote:
>
> "Linus documentation".

In fact, we might as well have a whole subdirectory on "Managing Linus",
which some people have become very good at.

The BK docs that people are so in a huff over really _are_ less about BK
itself, and almost entirely about how to use it to interface with me. Read
them - they are just a "SubmittingPatches" for BK, along with scripts to
automate it to get the format that I have found to be useful.

Rememebr how many times people have asked for automated tools, and for
getting notification about when I've applied a patch? You've got it. It's
all there.

Side note: remember the discussion that pushed me to _try_ BK in the first
place?

Who was it that said "Be careful what you pray for"? ;)

		Linus

BK, deltas, snapshots and fate of -pre...

[Alexander Viro]

On Sun, 21 Apr 2002, Ian Molton wrote:

> is this 'bitkeeper documentation', 'documentation about bitkeeper', or
> 'linux kernel documentation', or what?

"Linus documentation".

/me carefully stays the hell away from discussing whether it's a part of
documented object or not and what would be the license on said object...

As one of the guys who doesn't use BK _and_ had submitted a lot of patches
since Linus had started using it, I'm probably qualified to tell whether it
hurts or not, right?  Well, it doesn't.  So far the only difference was
in the quality (and latency) of changelogs and that was definitely welcome.

As long as "I've got a bunch of patches affecting <area>. Seeing that you've
merged stuff touching <area> since the last -pre, resync point would be
a Good Thing(tm)" works I couldn't care less about BK vs. diff+mail.  So
far it seems to be working fine.

FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is
a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD
oopses when..." simply because it's easier to match bug reports that way.
Having all deltas downloadable as diff+comment is wonderful, but it doesn't
replace well-defined (and less frequent) resync points.

Comments?

Re: BK, deltas, snapshots and fate of -pre...

[David S. Miller]

   From: Alexander Viro <viro@math.psu.edu>
   Date: Sun, 21 Apr 2002 00:05:27 -0400 (EDT)

   FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is
   a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot YY/MM/DD
   oopses when..." simply because it's easier to match bug reports that way.
   Having all deltas downloadable as diff+comment is wonderful, but it doesn't
   replace well-defined (and less frequent) resync points.
   
   Comments?

I agree, make the daily's available but don't kill the -pre.

Re: BK, deltas, snapshots and fate of -pre...

[Rob Landley]

On Sunday 21 April 2002 12:05 am, Alexander Viro wrote:

> FWIW, I doubt that dropping -pre completely in favour of dayly snapshots is
> a good idea - "2.5.N-preM oopses when ..." is preferable to "snapshot
> YY/MM/DD oopses when..." simply because it's easier to match bug reports
> that way. Having all deltas downloadable as diff+comment is wonderful, but
> it doesn't replace well-defined (and less frequent) resync points.

The well-defined resync points are the 2.5.N releases.  If -pre goes away, 
then the dot-releases might need to come a little closer together, that's all.

Rob