[PATCH] Remove Bitkeeper documentation from Linux tree
Jeff Garzik
> I have up to this point been open to the use of Bitkeeper as a development
> aid for Linux, and, again up to this point, have intended to make use of
> Bitkeeper myself, taking a pragmatic attitude towards the concept of using
> the best tool for the job. However, now I see that Bitkeeper documentation
> has quietly been inserted ino the Linux Documentation directory, and that
> without any apparent discussion on lkml. I fear that this demonstrates that
> those who have called the use of Bitkeeper a slippery slope do have a point
> after all.
Guess what? You have the freedom to ignore these docs.
Guess what else? You are taking away freedoms by restricting speech,
making documents less available than they previously were.
Take your closed mind elsewhere. I'm pretty sure Linus has more sense
than to apply this patch.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
> a personal acquaintance. I strongly support his efforts to build a business
> for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> documentation, the subject of this patch. I do not support the infusion of
It's also really, really, low class to not even CC me in your attempt
to remove the documentation I wrote from the kernel tree, and placed
into the kernel tree at Linus's request.
Rot in hell, closed mind.
Anton Altaparmakov
This is not documentation for bitkeeper but how to use bitkeeper
effectively for kernel development. It happens to be DAMN USEFULL
documentation at that for anyone wanting to use bitkeeper for kernel
development so IMO it fully belongs in the kernel. Just like the
SubmittingPatches document does, too. Or are you going to remove that as well?
If you don't want to use bitkeeper you don't need to read this
documentation. Just ignore it and stick with what is SubmittingPatches
document.
What's your problem?
Best regards,
Anton
At 16:12 19/04/02, Daniel Phillips wrote:
>Hi Linus,
>
>I have up to this point been open to the use of Bitkeeper as a development
>aid for Linux, and, again up to this point, have intended to make use of
>Bitkeeper myself, taking a pragmatic attitude towards the concept of using
>the best tool for the job. However, now I see that Bitkeeper documentation
>has quietly been inserted ino the Linux Documentation directory, and that
>without any apparent discussion on lkml. I fear that this demonstrates that
>those who have called the use of Bitkeeper a slippery slope do have a point
>after all.
>
>I respectfully request that you consider applying the attached patch, which
>reverses these proprietary additions to the Documentation directory. Perhaps
>a better place for this documentation would be on kernel.org if Peter Anvin
>agrees, or the submitter's own site if he does not. Or perhaps bitkeeper.com
>would be willing to host these files.
>
>Please do not misinterpret my position: I count Larry as something more than
>a personal acquaintance. I strongly support his efforts to build a business
>for himself out of his Bitkeeper creation. I even like Jeff Garzik's
>documentation, the subject of this patch. I do not support the infusion of
>documentation for proprietary software products into the Linux tree. The
>message is that we have gone beyond optional usage of Bitkeeper here, and it
>is now an absolute requirement, or it is on the way there.
>
>I hope that this proposed patch will receive more discussion than the
>original additions to Documentation did.
>
>Thankyou,
>
>Daniel
--
"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/
Roman Zippel
Jeff Garzik wrote:
> Guess what else? You are taking away freedoms by restricting speech,
> making documents less available than they previously were.
So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
information as well?
You certainly don't want to restrict the freedoms of other users?
bye, Roman
Jeff Garzik
> Hi,
>
> Jeff Garzik wrote:
>
> > Guess what else? You are taking away freedoms by restricting speech,
> > making documents less available than they previously were.
>
> So we soon include cvs/rcs/sccs/arch/subversion/aegis/prcs usage
> information as well?
> You certainly don't want to restrict the freedoms of other users?
Two issues here:
1) Daniel was attempting a 'remove' operation, you are describing an
'add'. The operations do the exact opposite in terms of information
dissemination.
2) If someone writes a good guide to using Arch with the Linux kernel,
or subversion, I don't have an objection to putting it into
Documentation.
Daniel disagrees with the content of the speech in
Documentation/BK-usage, based on his ideology. And he attempted to
restrict the dissemination of that speech. What is the definition
of censorship again?
People may think I'm just pissed because it's my doc he wanted to
remove, but that's only partially true. I see this as a clear cut
case of Daniel's ideology pushing him to attempt to restrict speech.
That is anti-freedom, no matter how you look at it, regardless of
whether we are talking about BitKeeper or anything else.
Maybe we should have warning labels on software, indicating that
a product does not conform completely to some idealist notion of
free software.
Jeff
David Lang
then yes they should be included.
remember that the reason for the bitkeeper documentation is to help people
setup a tree that linux (and others) can pull from, not to help people
setup their own tree just for them to hack on. Currently none of the tree
maintainers use cvs/rcs/sccs/arch/subversion/aegis/prcs in such a way that
there is anything that someone hacking the kernel needs to do to be
compatable (other then following the existing documentation for sending
patches) but for bitkeeper there is so this documentation is needed.
David Lang
Nils Philippsen
> On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> > Please do not misinterpret my position: I count Larry as something more than
> > a personal acquaintance. I strongly support his efforts to build a business
> > for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> > documentation, the subject of this patch. I do not support the infusion of
>
> It's also really, really, low class to not even CC me in your attempt
> to remove the documentation I wrote from the kernel tree, and placed
> into the kernel tree at Linus's request.
>
> Rot in hell, closed mind.
You seriously have to improve your manners. Dubbing someone low class
while using such phrases is pretty double standards. Is it really so
difficult to calm down before replying? But I guess I'm just restricting
your freedom of speech.
Nils
--
Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg //
+49.7152.209647
ni...@wombat.dialup.fht-esslingen.de / ni...@redhat.de /
ni...@fht-esslingen.de
Ever noticed that common sense isn't really all that common?
Linus Torvalds
On Sat, 20 Apr 2002, Jeff Garzik wrote:
>
> Take your closed mind elsewhere. I'm pretty sure Linus has more sense
> than to apply this patch.
Absolutely.
Like it or not, I personally use BK. I don't use CVS, and I don't use
subversion.
If anybody wants to maintain his own kernel, feel free to remove the
documentation on how to interact with _me_. In such a kernel, those docs
would obviously be meaningless.
In fact, Daniel, if you had bothered to just even grep for CVS, you would
have noticed that we've had CVS information for some other subprojects
too, because _they_ happen to use CVS. Would you argue for removal of the
CVS information in Documentation/filesystems/jfs.txt file?
And if not, then you're a hypocritical bastard with a religious agenda.
Linus
Anton Altaparmakov
>On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > Daniel,
> >
> > This is not documentation for bitkeeper but how to use bitkeeper
> > effectively for kernel development. It happens to be DAMN USEFULL
> > documentation at that for anyone wanting to use bitkeeper for kernel
> > development so IMO it fully belongs in the kernel. Just like the
> > SubmittingPatches document does, too. Or are you going to remove that
> as well?
>
>we?
The lkml FAQ is aimed at users, not developers. The bitkeeper and the
SubmittingPatches document are aimed at developers. I see a fundamental
difference here...
> > If you don't want to use bitkeeper you don't need to read this
> > documentation. Just ignore it and stick with what is SubmittingPatches
> > document.
> >
> > What's your problem?
>
>I am worried that a creeping takeover of the Linux hitherto-successful
>development process is in progress, that concensus on this topic has not been
>achieved, and that there is a split coming. That would not be good.
>
>As always, what I do is in the interest of Linux and freedom. That interest
>is not served by driving a wedge firmly between two groups of Linux
>developers.
>I hope you understand that I am a *moderate* with respect to this issue.
The fact that some developers use bitkeeper has no effect on other
developers. Well ok, it means that the bk using developers can work faster
but that is not at issue here...
I don't see why there should be any kind of split or anything like that.
Everything continues as before. It's just that some developers now have a
much easier life...
Anton
Alexander Viro
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > And if not, then you're a hypocritical bastard with a religious agenda.
>
> Err, and if I to argue for it then I'm not? That's easy I argue for it.
In that case you are a wanker with religious agenda. Tomahto, tomato...
Jeff Garzik
> On Sat, 2002-04-20 at 17:54, Jeff Garzik wrote:
> > On Fri, Apr 19, 2002 at 05:12:33PM +0200, Daniel Phillips wrote:
> > > Please do not misinterpret my position: I count Larry as something more than
> > > a personal acquaintance. I strongly support his efforts to build a business
> > > for himself out of his Bitkeeper creation. I even like Jeff Garzik's
> > > documentation, the subject of this patch. I do not support the infusion of
> >
> > It's also really, really, low class to not even CC me in your attempt
> > to remove the documentation I wrote from the kernel tree, and placed
> > into the kernel tree at Linus's request.
> >
> > Rot in hell, closed mind.
>
> You seriously have to improve your manners. Dubbing someone low class
> while using such phrases is pretty double standards. Is it really so
> difficult to calm down before replying? But I guess I'm just restricting
> your freedom of speech.
I never claimed I was not low class[1] ;-) And no, you're not
restricting free speech at all... Posts like yours are a celebration of
free speech.
Jeff
[1] I often joke with my friends, "I've got plenty of class... all of it
low." Usually after telling a tasteless joke :)
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> kernel.org, on your site, or on bitmover.com where it belongs.
That was not what your patch did.
> (And there you may have an argument that would satisfy me. However, it
> is not me I'm worried about. It is the other kernel developers who are
> silently seething at this situation. Yes they are, use your ears.)
I would suggest that if you are silently seething about the fact that a
commercial product can do something better than a free one, how about
_doing_ something about it?
Quite frankly, I don't _want_ people using Linux for ideological reasons.
I think ideology sucks. This world would be a much better place if people
had less ideology, and a whole lot more "I do this because it's FUN and
because others might find it useful, not because I got religion".
Would I prefer to use a tool that didn't have any restrictions on it for
kernel maintenance? Yes. But since no such tool exists, and since I'm
personally not very interested in writing one, _and_ since I don't have
any hangups about using the right tool for the job, I use BitKeeper.
As to why the docs are in the kernel sources rather than on any web-sites:
it's simply because I don't even _have_ a web page of my own (I've long
since forgotten the password to my old helsinki.fi account ;), and I have
absolutely no interest in web page design. So when I got tired of
explaining how to use BK, I asked Jeff to just send me a patch so that I
could point people to the only thing I _do_ care about, ie the kernel
sources.
Linus
Roman Zippel
David Lang wrote:
> If they start to be tools that are used to submit changes to the kernel
> then yes they should be included.
"start"? People used other source management system already before bk.
> remember that the reason for the bitkeeper documentation is to help people
> setup a tree that linux (and others) can pull from, not to help people
> setup their own tree just for them to hack on.
The problem is that this suggest, bk would be the choice for kernel
development or even usage. They are lots of kernel projects, which use
cvs, but noone before considered submitting extensive cvs documentation
into the kernel.
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
How?
Linus
Jeff Garzik
> On Saturday 20 April 2002 18:51, you wrote:
> > The fact that some developers use bitkeeper has no effect on other
> > developers.
>
> two classes: the "ins" and the "outs".
I disagree -- Andrew Morton and Al Viro don't sent patches to Linus via
BK, AFAIK, and their patches are getting in.
Another example, Jean Tourrhes (sp?), the wireless and IrDA guy. I have
agreed to become his "patch penguin", which IMHO has already translated
into less resends for Jean through my and Linus's use of BK. He sends
GNU patches, so his process is unchanged, he only sees patches _not_
getting dropped[1].
And a further counter-example (to my shame), Anton A. sent me a BK patch
during Linus's vacation, and I have not yet sent it forward, showing
that BK doesn't necessarily imply auto-approval.
Jeff
[1] of course there is often a Garzik-delay :) but I don't drop patches
Linus Torvalds
On Sat, 20 Apr 2002, Roman Zippel wrote:
>
> They are lots of kernel projects, which use cvs, but noone before
> considered submitting extensive cvs documentation into the kernel.
More importantly, there was no way in hell I would synchronize with a CVS
tree, so CVS was a non-entity as far as patch submittal was concerned.
The BK documentation is _nothing_ more than a alternative to
"SubmittingPatches".
Anyway, I'm not going to discuss this any more. If somebody has actual
construcive ideas about trying to improve other tools or putting the BK
docs in some place that is equally obvious and easily available for all
parties but somehow "less disturbing" to people with a weak stomach, go
for it. But I'm not interested in yet another religious whine-war.
Linus
Roman Zippel
Jeff Garzik wrote:
> Daniel disagrees with the content of the speech in
> Documentation/BK-usage, based on his ideology. And he attempted to
> restrict the dissemination of that speech. What is the definition
> of censorship again?
Maybe I was to subtle, but your censorship argument is simply bullshit.
A link to the information is completely sufficient. The only question
is, whether the information is relevant for kernel development and most
of it is only bk documentation.
bye, Roman
Dave Jones
> > The fact that some developers use bitkeeper has no effect on other
> > developers.
> On the contrary, I think it has divided the kernel developers firmly into
> two classes: the "ins" and the "outs".
Care to back that up with numbers ? Take another look at the statistics
Larry posted after the 2.5.8 merge. ISTR pretty much a 50/50 split of
bk merges and regular GNU patches. Whilst a large proportion of the gnu
patches were from the largish sync I did, this ratio seems to be holding
up over every release.
> Oh I don't disagree at all. Bitkeeper is a big improvement over what
> existed before. But it is proprietary. Which other tool in the tool chain
> is proprietary?
Film at 11: proprietory tool used in Linux.
Maybe we should back out all those fixes the Stanford people found with
their checker ? Maybe we should back out the x86-64 port seeing as it
was (partly) done with a commercial simulator?
> > I don't see why there should be any kind of split or anything like that.
> > Everything continues as before. It's just that some developers now have a
> > much easier life...
> And some have a more difficult one. So it goes.
You've not pointed out where this difficulty is yet. Apart from
developers having to wade through this same discussion every third week.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
>
> But did you think it might be controversial?
Ehh, the documentaion? Nope, I didn't really think _that_ part would be
controversial.
The change to BK? I sure as hell knew that was going to be "interesting",
yes absolutely. After all, it had been discussed at places like the kernel
summit etc.
But hey - I've never really cared about what other people think about what
I do. If I had, I'd have given up on Linux when Tanenbaum ridiculed it. Or
I wouldn't have done the big dentry change (which was a total disaster in
some peoples minds) in 2.1.x. Or the VM changeover in the middle of 2.4.x.
Or a million other things.
I do what _I_ think is right for the kernel, and while I tend to poll
people and listen to them, when the sh*t hits the fan it is _my_ decision.
You can't please everybody. And usually if you _try_ to please everybody,
the end result is one big mess.
Linus
Thunder from the hill
> Quite frankly, I don't _want_ people using Linux for ideological reasons.
> I think ideology sucks. This world would be a much better place if people
> had less ideology, and a whole lot more "I do this because it's FUN and
> because others might find it useful, not because I got religion".
Several guys (mis-)use Linux as war against Windows, which is really
childish. But it seems they're an important amount, on both sides (There
are even users who use Windows as a protest against Linux). That does,
however, not help you to get an non-propietary tool.
As long as there is nothing I could use instead, it's a good idea to use
BitKeeper instead, and as long as there is a way to use it, users will
actually look it up in the Documentation dir. If users don't find an
answer there, they'll certainly massively bother the LKML.
Documentation also contains information on how to use existing tools
with Linux Kernel. If we exclude BitKeeper just because it's propietary
tool, we'll get into trouble.
BTW, why then do we include processor support into the kernel tree? I
can't find any way to download them from the Internet!
Regards,
Thunder
--
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.
Larry McVoy
a) if it would ease the incredible silent (?) seething anguish of Daniel and
others, I'd be happy to post a copy of Jeff's docs on the bitkeeper.com
website someplace and you could replace the patch with a pointer to that.
Seems silly but if it makes the uproar go away...
b) To all of the "silently seething" folks, build a better answer for
free and the kernel team will switch in a heartbeat. How about you
think of BitKeeper as a stepping stone, a temporary thing until a
better answer appears? It doesn't even have to be better, just good
enough.
We built BK to make the key people more efficient. To some extent, it
is doing that. We'll keep trying to make it help make those people more
efficient. That's *good* for the kernel. Which was always the goal.
I'm terribly sorry that this product space doesn't generate enough
consulting business that it can support itself in a politically correct
way, but it doesn't. Get over it. You either get crap tools or you get
tools that have a business model. In this space, the GPL doesn't work,
you need some other way to pay for the work.
If you don't agree, by all means, feel free to *prove* me wrong by
designing, implementing, and supporting a better (or as good)
answer. That is what Linus has said, and I agree, and the "silently
seething" folks need to either put up or go back to being silent.
A thing to keep in mind is that there are a large number of talkers,
people who spend their time flaming but very little of their time writing
useful code. Those people seem to have the most time to argue about
licenses. There are other people who spend their time writing code,
useful code. The goal is to help the second, smaller, group.
BitKeeper seems to make that second group more productive. And it happily
allows for the license haters to keep on working the way they used to,
at the same speed as they used to. Daniel raised the point that BK has
created the "ins" and the "outs". That's not quite right, it's a question
of "efficient" versus "not quite so efficient". Yeah, it has the effect
of creating an "in" group, but that is because it is easier to work that
way, not because of any evil plan to take over the world with BK.
To repeat: if http://www.bitkeeper.com/kernel-howto.html or something
like that makes you happier, I'll do that immediately.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Linus Torvalds
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > > And some have a more difficult one. So it goes.
> >
> > How?
>
> Those who now chose to carry out their development using the patch+email
> method, and prefer to submit everything for discussion on lkml before it
> gets included are now largely out of the loop. Things just seem to *appear*
> in the tree now, without much fanfare. That's my impression.
I don't buy that - I'm not getting changes from any new magical BK "men in
black". The patches are the same kind they always were, the last few
entries in my changelog are now the x86-64 merge (which was half a meg,
and yes it wasn't posted on linux-kernel, but no, it never was before BK
either), and before that the extensively discussed SSE register content
leak patch.
HOWEVER, the fact that you _feel_ like that is clearly a fact.
Any suggestions on how to make the process _appear_ less intimidating?
Note that one thing that I had hoped BK would do for me, but that hasn't
happened because I'm a lazy bastard and I'm bad at doing automated scripts
is to do dialy snapshots as patches (getting rid of the "-pre" kernels,
since they don't actually add any information except act as update
points), and also send out a changelog daily to the kernel mailing list.
That is something that is one of the big _points_ to using source control,
yet because I don't need it personally I've never gotten around to writing
those scripts.
That would actually make the development process MORE open than it was
before BK, and might make even non-BK people appreciate BK more simply
because there is a real point to it.
Comments? Anybody want to hack up a script to do this?
Linus
Larry McVoy
> On Saturday 20 April 2002 19:09, Linus Torvalds wrote:
> > On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > >
> > > And some have a more difficult one. So it goes.
> >
> > How?
>
> Those who now chose to carry out their development using the patch+email
> method, and prefer to submit everything for discussion on lkml before it
> gets included are now largely out of the loop. Things just seem to *appear*
> in the tree now, without much fanfare. That's my impression.
>
> advent of Bitkeeper, it seems to be turning more in the direction of
> becoming a closed club. This may be fun if you're a member of the club.
You are sort of right and sort of wrong. The changes are mostly ending
up in some BK tree and Linus pulls from that tree. Most of the trees
are on bkbits.net (there are about 130 different ones at last count).
The problem is that there is not an easy way to get a handle on what is
in Linus' tree and what is not, and it's just insane to ask people to
sit around and diff the trees even if BK does make that process somewhat
easier.
An obvious improvement would be to have an "overview" web page which showed
you the list of changes not present in Linus' tree but present in any of
the other trees. Probably sorted by tree so you could see
linuxusb.bkbits.net/linux-2.5
37 changesets (click here for details)
gkernel.bkbits.net/vm
12 changesets (click here for details)
Etc.
If you dump the licensing discussion and think about how BK could help
you, you can see we are half to an improvement over the "mail to the
list" model. The problem I had with the "mail to the list" model was
that it was easy to miss something and then not realized that you
had missed it. Now a lot of that stuff is ending up on bkbits.net
and if there was a way to say "tell me everything that is there but
not here", that would be a distinct improvement, it means that the
"mail" is archived and you can find it when you want it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Eric W. Biederman
> Hi Linus,
>
> I have up to this point been open to the use of Bitkeeper as a development
> aid for Linux, and, again up to this point, have intended to make use of
> Bitkeeper myself, taking a pragmatic attitude towards the concept of using
> the best tool for the job. However, now I see that Bitkeeper documentation
> has quietly been inserted ino the Linux Documentation directory, and that
> without any apparent discussion on lkml. I fear that this demonstrates that
> those who have called the use of Bitkeeper a slippery slope do have a point
> after all.
Daniel I agree that there are some real dangers to using a proprietary
tool, and have seen it severely affect a project.
The primary problem is that some developers are not able to
participate because they do not have the tool.
Given that bitkeeper is currently freely available, and that people
can still send raw patches I do not see that people are currently
being excluded on basis of the tool they use.
I can see the potential for this to break down. However we should
not be crying wolf until this actually does break down.
There is exactly one point where religious attitudes are important.
Because of them some people will not use a non-free tool. So for a
wide spread project there must be some way for them to participate.
diffs are still being accepted, so these people do have a to
participate.
Eric
Eric W. Biederman
> The fact that some developers use bitkeeper has no effect on other
> developers. Well ok, it means that the bk using developers can work faster but
> that is not at issue here...
Faster? BK has no impact on the fundamentals of code development. Only
on the problem of merging code. Only when the bottle neck is merge speed
does it really come into play.
For Linus this is obviously a very important issue. For some of the
rest of us it is less so.
For myself I find great benefit in reviewing my own patches, and in
having other people look at them and review them. I may be wrong
but I do not see bitkeeper helping in that regard (except reduce
the noise of renames).
Eric
Rik van Riel
> As always, what I do is in the interest of Linux and freedom.
Then why do you want to deny us the freedom to have a very
useful piece of documentation in the kernel tree ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Anton Altaparmakov
>Anton Altaparmakov <ai...@cantab.net> writes:
> > The fact that some developers use bitkeeper has no effect on other
> > developers. Well ok, it means that the bk using developers can work
> faster but
> > that is not at issue here...
>
>on the problem of merging code. Only when the bottle neck is merge speed
>does it really come into play.
I would disagree personally. The more I play with the GUI tools provided by
bitkeeper the more interesting things i discover. For example actually
SEEING how patches fit together, being able to see what each patch did,
looking at a file and having each line annotated as to who added it and in
which patch makes it easier for me to understand how the code I am trying
to understand has evolved and why certain things are the way they are. But
that is something very personal to me, others may not find it useful...
>For Linus this is obviously a very important issue. For some of the
>rest of us it is less so.
>
>For myself I find great benefit in reviewing my own patches, and in
>having other people look at them and review them. I may be wrong
>but I do not see bitkeeper helping in that regard (except reduce
>the noise of renames).
I really like the way bk citool works because it makes my changelogs a lot
more useful as I actually see what I have changed when writing them. But
again, that is just me...
Best regards,
Jeff Garzik
> The missing part is watching the mail go by. It's the discourse, where
> has it gone? What happened to the times when patches were actually
> discussed before going into the tree? Can we somehow have that and
> bitkeeper too... and a fairy castle...
The level of discussion of my own patches is exactly the same, pre- and
post-BitKeeper.
What patches do you think are being sneaked into the tree?
Jeff
Russell King
> All of what you said, 100% agreed, and insightful, in particular:
>
> On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > I can see the potential for this to break down. However we should
> > not be crying wolf until this actually does break down.
>
Actually, you yourself have probably sewn the first seeds of the community
breaking down. Lets take a moment to put some thought in at this point
and review what's happened today.
1. The Current Situation
- Linus uses BK
- Linus makes his BK tree available.
- Linus makes GNU patches available.
- Linus accepts requests to pull from BK trees.
- Linus accepts GNU patches to apply to his BK tree.
2. The effect of today
- You've highlighted a problem
- David Woodhouse and Rik van Riel have written a tool to grab Linus'
BK tree and turn it into a patch on a per-hourly basis
Now look back at Linus' actions above. There is now redundancy. Linus
doesn't have to put out GNU patches anymore because someone else is
doing that for him... which means Linus works more efficiently.
So it's highly likely that in the future, we'll have:
- Linus uses BK
- Linus makes his BK tree available
- Linus accepts requests to pull from BK trees.
- Linus accepts GNU patches to apply to his BK tree.
- "Select few" pull his BK tree and create GNU patches for others
to use.
Oops. We've just split the community further, which is *completely* the
opposite of what you wanted to achieve. I wonder what the next stage
will be...
Like I said to you on IRC before you posted the message - you want
to fix the problem at the root (ie, Linus) rather than your apparant
problem with the "two communities." And how do you do that? You
discuss it with the person concerned. (And you can see the results
of that discussion earlier in this thread.)
This way, those that want to use "a distributed source control system
of some type" can do so, and those that want to use the GNU patch/diff
method can also continue to, but with The Latest Tree available.
Which has got to be an advantage for *everyone*.
I'm sorry, I have no cares for people who have been constantly whinging
at the users of BK who don't go out of their way to find out where the
real problem is and attempt to fix that, rather than harp on about how
other people shouldn't be using a non-free tool.
Oh, and before anyone says that I'm another one who uses BK, yes I do
use BK, but only as a method of getting ARM specific changes into Linus.
Any generic kernel changes I have still go to linux-kernel, Linus and
any relevant other people as a GNU patch. The first time these patches
see BK is when they hit Linus' BK tree. They don't come from BK either.
I, therefore, can claim to work in both domains in parallel.
But no, in your eyes, I'm just another stupid BK person who's contributing
to the downfall of Linux, and is in the "in" club.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Eric W. Biederman
> All of what you said, 100% agreed, and insightful, in particular:
>
> On Saturday 20 April 2002 19:53, Eric W. Biederman wrote:
> > I can see the potential for this to break down. However we should
> > not be crying wolf until this actually does break down.
>
> Do we want it to break down first? I don't want that.
The price of freedom is continual vigilance.
So when confronted by changes in practice that we aren't sure about
the appropriate procedure is to ask (publicly?). If this is keeping
developers from participating. Or if it is placing a significant
barrier in the way of developers. If we start the conversation
without condemnation of change, we won't be crying wolf. Only asking
is that a wolf?
Addressing the filter is doing X fun. For me working with near-free
tools is not fun, because I must always be aware of the difference. I
am never quite certain where I stand with the tool vendor. The tool
is not free obviously because money making opportunities are more
important than my ability to use and modify the tool.
At the same time constant vigilance even of free software is required.
A non-free tool that does a sufficiently good job that I don't feel
like fixing it, is usable. It simply becomes a minor background
irritant that I can ignore.
Linus working more efficiently so he can accept more patches is
obviously more fun :)
Eric
Jeff Garzik
> On Saturday 20 April 2002 20:13, you wrote:
> > On Fri, 19 Apr 2002, Daniel Phillips wrote:
> >
> > > As always, what I do is in the interest of Linux and freedom.
> >
> > Then why do you want to deny us the freedom to have a very
> > useful piece of documentation in the kernel tree ?
>
> 'shared source' license, whould you also say I was denying your freedom?
You tried to -remove-, not include something. And, what you tried to
remove was under the GPL license, not any other license. So your
analogy doesn't hold.
You attempted to remove a GPL'd work from a GPL'd work, on the basis of
its content conflicting with your ideology.
Jeff
Jeff Garzik
> Hi,
>
> Jeff Garzik wrote:
>
> > Daniel disagrees with the content of the speech in
> > Documentation/BK-usage, based on his ideology. And he attempted to
> > restrict the dissemination of that speech. What is the definition
> > of censorship again?
>
> Maybe I was to subtle, but your censorship argument is simply bullshit.
> A link to the information is completely sufficient.
What was Daniel's action? Remove the text. Nothing else. Sure, he
suggested other options, but he did attempt to implement them? No.
He just implied that people need to step up and do this work for him.
Daniel attempted to remove speech he disgreed with from wide
distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
it is plainly obvious that removing a doc from one of the mostly
widely distributed open source projects reduces the doc's distribution
dramatically. _That_ is a form of censorship, just like buying out
printing presses, to silence them, in the old days. It's still
around... just progressively harder to obtain.
> The only question
> is, whether the information is relevant for kernel development and most
> of it is only bk documentation.
And the answer is, it is BK documentation written for kernel developers
by kernel developers, with the intention of being a SubmittingPatches
document for BK users. Very relevant to kernel devel. This relevance
was proved by its origin -- emails bouncing back and forth, generally
originating by Linus, CC'ing me, asking me for the emails I had
already sent to other hackers, describing kernel development under BK.
After the info had been separately requested multiple times, it
got turned into a document -- the BK version of SubmittingPatches.
After that doc was requested multiple times, it went to the same
place where SubmittingPatches is stored.
Jeff
Jeff Garzik
> Martin Dalecki's IDE patch, gosh, look at all the fun. It's a non-BK
> patch, let's see if there's a pattern. Hmm, the next bushy one is "[PATCH]
> zerocopy NFS updated", descending from a traditional patch set. The next
> one, "[PATCH] IDE TCQ #4" is also a traditional patch. Hmm, no bitkeeper
> patches showing up yet, I don't think I need to go on.
>
> There is a clear inverse relationship between the bk-ness of a patch and
> the extent to which it's discussed on lkml. I don't know what to read into
> that, but it does seem to lend credence to the idea that the bitkeeper
> style of working is not compatible with the idea of community discussion.
Concrete examples, please?
Which patches are the stealth patches?
Skip Ford
>
> And the answer is, it is BK documentation written for kernel developers
> by kernel developers, with the intention of being a SubmittingPatches
> document for BK users. Very relevant to kernel devel. This relevance
> was proved by its origin -- emails bouncing back and forth, generally
> originating by Linus, CC'ing me, asking me for the emails I had
> already sent to other hackers, describing kernel development under BK.
That's not true. Section 1 of 'SubmittingPatches' is entitled
"Creating and Sending Your Change" while section 1 of your
bk bullshit is called "Bitkeeper Concepts."
All of section 1 is an advertisement for using bk...including
directions on how to setup your own clone. Those are _clearly_
bitkeeper directions and have nothing to do with how to submit
patches.
Delete sections 1 & 2 and make section 3 the gist of the document
and _then_ you'll have the bk equivalent of 'SubmittingPatches.'
--
Skip
Rik van Riel
> All of section 1 is an advertisement for using bk...including
> directions on how to setup your own clone. Those are _clearly_
> bitkeeper directions and have nothing to do with how to submit
> patches.
I'm sure Jeff would be more than happy to include an
advertisement for a free bitkeeper alternative, once
one exists. ;)
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
-
Jeff Garzik
> Jeff Garzik wrote:
> >
> > And the answer is, it is BK documentation written for kernel developers
> > by kernel developers, with the intention of being a SubmittingPatches
> > document for BK users. Very relevant to kernel devel. This relevance
> > was proved by its origin -- emails bouncing back and forth, generally
> > originating by Linus, CC'ing me, asking me for the emails I had
> > already sent to other hackers, describing kernel development under BK.
>
> That's not true. Section 1 of 'SubmittingPatches' is entitled
> "Creating and Sending Your Change" while section 1 of your
> bk bullshit is called "Bitkeeper Concepts."
>
> All of section 1 is an advertisement for using bk...including
> directions on how to setup your own clone. Those are _clearly_
> bitkeeper directions and have nothing to do with how to submit
> patches.
What you call an ad is the result of evolution of several resendings
of similar emails, and answering FAQs. This is the stuff that has
proven useful over time.
To call that an advertisement is to insult the kernel developers
that asked these questions, which are answered in the doc. They were
not requesting endorsements, they were asking honest questions about
ways to optimize their kernel development, and merging with Linus.
Responding with an intro on how BK clones work has proven to be a
good first step to that.
Jeff
Stevie O
Daniel is now bothered by the presence of BK documentation in the Linux kernel tree. Therefore, he submitted a patch to remove this documentation.
Just about everybody else involved in this thread accuses him of censorship, for attempting to restrict the dissemination of ideas. I do not know whether all of these people use BK; all I know is the "censorship" claim, on the basis that he is restricting the dissemination of information.
I ask this: What if, instead of Daniel removing this documentation change, Linus himself did the patch?
2600 asserted that source code is speech, with the DeCSS case. I doubt EVERYONE here agrees with that, but I do agree that source code is a very precise form of communcating ideas...
(1) If I were to write a driver, and submit it for inclusion with the mainline kernel, would Linus be "censoring" me if he did not include my patch?
And here is a better reason:
(2) If I had such a driver included in mainline, and that driver broke in the 2.5 series -- due to, say, BIO changes, VFS changes, procfs changes, DMA changes, PCI subsystem changes, you get the idea -- and as a result, Linus chose to remove it from mainline, he's restricting the dissemination of my ideas (driver). Does that mean he is censoring me?
--
Stevie-O
*This sig was deleted for violating the DMCA.*
Anton Altaparmakov
> From what I can see, this is the situation:
>
>Daniel is now bothered by the presence of BK documentation in the Linux
>kernel tree. Therefore, he submitted a patch to remove this documentation.
>
>Just about everybody else involved in this thread accuses him of
>censorship, for attempting to restrict the dissemination of ideas. I do
>not know whether all of these people use BK; all I know is the
>"censorship" claim, on the basis that he is restricting the dissemination
>of information.
>
>I ask this: What if, instead of Daniel removing this documentation change,
>Linus himself did the patch?
That is completely different. Linus owns the Linux kernel. He is the
dictator on what happens with it. As such he can do with it as he pleases.
If anyone doesn't like his actions, they are free to fork the kernel and do
whatever they want. That is what the GPL is all about!
This thread is getting sillier and sillier...
Best regards,
Anton
>2600 asserted that source code is speech, with the DeCSS case. I doubt
>EVERYONE here agrees with that, but I do agree that source code is a very
>precise form of communcating ideas...
>
>
>(1) If I were to write a driver, and submit it for inclusion with the
>mainline kernel, would Linus be "censoring" me if he did not include my patch?
>
>And here is a better reason:
>
>(2) If I had such a driver included in mainline, and that driver broke in
>the 2.5 series -- due to, say, BIO changes, VFS changes, procfs changes,
>DMA changes, PCI subsystem changes, you get the idea -- and as a result,
>Linus chose to remove it from mainline, he's restricting the dissemination
>of my ideas (driver). Does that mean he is censoring me?
>
>--
>
>Stevie-O
>
>*This sig was deleted for violating the DMCA.*
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"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/
-
Jeff Garzik
> Let me turn that around. Which bitkeeper patches have been posted to lkml and
> generated significant amounts of discussion on lkml in the last week? Versus
> how many lines of bitkeeper patches applied to Linus's tree?
Prior to BK, many people still emailed patches privately to Linus:
me, DaveM, Alan, Al, GregKH, ... You might consider private email
stealth, but usually the changes are either (a) obvious or (b)
previously discussed. With BK, the situation is the same.
So your argument is red herring -- which changes are _newly stealthed_
under BK? Do you have even ONE objectionable example?
BK only changes the medium of transmission of patches to Linus,
and gives us _more_ information about submittors than pre-BK.
> The next question you might ask is: are there more BK patches or
> more Non-BK, in total, on and off lkml? I don't have statistics at
> hand but I'm willing to bet that there are more BK patches, because
> that is how the bulk of the grunt tree maintainance is getting
> done these days.
> My conclusion: though there are more BK patches being applied to Linus's
> tree than non-BK,
So... your conclusion is based on a guess which is based on a guess.
Even if your conclusion is correct (it might be), how do you use
that to support the argument that, less discussion occurs due to BK?
As I mentioned, most merging with Linus occured in private anyway.
If you want to argue against that, go ahead. But don't try to blame
BitKeeper for it.
If there are _specific solutions_ that can be implemented to equalize
things with BK versus non-BK developers, please, chime in. I think the
daily snapshot idea is a good one. Deleting a document, and nothing
else, accomplishes no forward progress (except maybe spawning this
discussion on the evils of BK).
Jeff
Stelian Pop
> My conclusion: though there are more BK patches being applied to Linus's
> tree than non-BK, they are generating less discussion on lkml than non-BK
> patches do. Or to put it bluntly: BK patches are not being discussed.
Or maybe using a SCM puts more pressure on the developper which
writes better code, which will get accepted with less discussion.
In general, when you seek discussion with a quick and dirty piece
of code, you post a patch, not the BK equivalent, since you know
this will not get accepted anyway...
Stelian.
--
Stelian Pop <steli...@fr.alcove.com>
Alcove - http://www.alcove.com
Jeff Garzik
> (1) If I were to write a driver, and submit it for inclusion with
> the mainline kernel, would Linus be "censoring" me if he did not
> include my patch?
(IMO my answer fits for both these examples)
> (2) If I had such a driver included in mainline, and that driver
> broke in the 2.5 series -- due to, say, BIO changes, VFS changes,
> procfs changes, DMA changes, PCI subsystem changes, you get the
> idea -- and as a result, Linus chose to remove it from mainline,
> he's restricting the dissemination of my ideas (driver). Does that
> mean he is censoring me?
In the strictest sense, yes. But the key difference would be his
reasoning in your example would be technical, whereas Daniel's stated
reason was ideology.
One of the reasons why I like the Linux kernel is the freedom to make
the best technical decision, regardless of conflicting ideologies or
politics.
Jeff
Russell King
> patches that generated discussion. Here's what I found:
Nice work. However, you forgot the other half of the job - finding out
how many BK "patches" got merged into Linus' tree, and how many GNU
patches. Only then can we make a real comparison.
And yes, I've done Linus a favour - I've deleted him from the CC: list
because he's said he's not interested in this discussion.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Jeff Garzik
> On Sunday 21 April 2002 00:20, Jeff Garzik wrote:
> > On Sat, Apr 20, 2002 at 12:01:35AM +0200, Daniel Phillips wrote:
> > > generated significant amounts of discussion on lkml in the last week? Versus
> > > how many lines of bitkeeper patches applied to Linus's tree?
> >
> > Prior to BK, many people still emailed patches privately to Linus:
> > me, DaveM, Alan, Al, GregKH, ... You might consider private email
> > stealth, but usually the changes are either (a) obvious or (b)
> > previously discussed. With BK, the situation is the same.
> >
> > So your argument is red herring -- which changes are _newly stealthed_
> > under BK? Do you have even ONE objectionable example?
>
> call that objectionable - I object to it, but that is not the same thing. I
> will call it 'not discussed' when it should have been.
It was requested by Linus to be in the tree as a convenience, because he
and I and others were constantly bouncing it to new people.
I don't see the point of discussing such an obvious patch, outside of
ideological grounds. And when we start making decisions based on
ideology and politics rather than technical merit, we can all go home.
> > BK only changes the medium of transmission of patches to Linus,
> > and gives us _more_ information about submittors than pre-BK.
>
> I'm not arguing that BK is not a good way to do the grunt maintainance work.
> I think it is, and that's great. Heck, I'm not arguing against Bitkeeper *at
> all*. I'm arguing against building the bitkeeper documentation into the
> kernel tree, giving the impression that Bitkeeper is *required* for
> submitting patches.
I think the conclusion that BitKeeper is required, because of the
presence of this documentation, is ludicrous. And I have already stated
many times that I think objecting to the presence of the doc solely on
ideological grounds is also ludicrous.
Linus repeatedly says GNU patches are still acceptable, did you miss that?
> > Even if your conclusion is correct (it might be), how do you use
> > that to support the argument that, less discussion occurs due to BK?
>
> We haven't established that, we do see a strong correlation. But think.
> It's obvious anyway, why discuss anything in public when you don't have
> to? Just push it straight to Linus's tree, why bother with formalities?
> It's so easy.
This "it's easy" argument can easily be applied to the pre-BK days.
Straight-to-Linus-without-discussion is obviously faster, regardless of
whether BK is used or not.
> > As I mentioned, most merging with Linus occured in private anyway.
> > If you want to argue against that, go ahead. But don't try to blame
> > BitKeeper for it.
>
> I sense that the discussion of patches on lkml is in decline and I do
> blame Bitkeeper. Think I'm being paranoid? Prove me wrong.
huh?? "I <think this>. Am I wrong? Prove it."
Typically, one is expected to prove their arguments :)
Can you offer any evidence of patches that would have been discussed, in
the pre-BK days, that are no longer discussed? Support your argument,
please.
> > Deleting a document, and nothing
> > else, accomplishes no forward progress (except maybe spawning this
> > discussion on the evils of BK).
>
> Larry already agreed to it, and to provide a new home for it. Linus
> said 'don't be silly', but that was a long way back. So that's where
> it stands.
IOW, it stands at 'don't be silly'.
IMO the acceptance of your patch would indicate that Linus has started
accepting patches based on something other than technical merit.
_There_ is your slippery slope we should avoid at all costs.
Jeff
Larry McVoy
> > All of section 1 is an advertisement for using bk...including
> > directions on how to setup your own clone. Those are _clearly_
> > bitkeeper directions and have nothing to do with how to submit
> > patches.
>
> I'm sure Jeff would be more than happy to include an
> advertisement for a free bitkeeper alternative, once
> one exists. ;)
And the sooner the better. I just read this entire thread and I'm disgusted.
I've seen some lame threads in my day, but this takes the cake.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Kenneth Johansson
> My conclusion: though there are more BK patches being applied to Linus's
> tree than non-BK, they are generating less discussion on lkml than non-BK
> patches do. Or to put it bluntly: BK patches are not being discussed.
I think your conclusion is wrong and there has always gone patches directly to
Linus even before BK. With BK we can actually see who did what and often why so if
something gets in that should not we know who to blame. If anything this should
make people think one extra time before hitting the send button.
Roman Zippel
Jeff Garzik wrote:
> What was Daniel's action? Remove the text. Nothing else. Sure, he
> suggested other options, but he did attempt to implement them? No.
> He just implied that people need to step up and do this work for him.
He made his intention very clear, you are interpreting something in his
action, that simply isn't there.
> Daniel attempted to remove speech he disgreed with from wide
> distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
> it is plainly obvious that removing a doc from one of the mostly
> widely distributed open source projects reduces the doc's distribution
> dramatically. _That_ is a form of censorship, just like buying out
> printing presses, to silence them, in the old days. It's still
> around... just progressively harder to obtain.
Censorship requires the means to enforce it and has Daniel this ability?
Could we please stop these "censorship" and "ideology" arguments? In
this context they are simply nonsense.
> And the answer is, it is BK documentation written for kernel developers
> by kernel developers, with the intention of being a SubmittingPatches
> document for BK users. Very relevant to kernel devel. This relevance
> was proved by its origin -- emails bouncing back and forth, generally
> originating by Linus, CC'ing me, asking me for the emails I had
> already sent to other hackers, describing kernel development under BK.
kernel development with bk requires net access and so it's sufficient,
when it's available over the net. On the other hand SubmittingPatches
describes the lowest common denominator, which works with any SCM and
doesn't favour any of them.
Personally I don't care what tools people use, but I'm getting
concerned, when a nonfree tool is advertised as tool of choice for
kernel for development as if there would be no choice. bk has advantages
for distributed development, but beside of this they are alternatives
and we should rather encourage users to try them and to help with the
development of them. But there isn't anything like that, so Joe Hacker
has to think he should use bk as SCM to get his patch into the kernel,
because Linus is using it.
bye, Roman
Larry McVoy
> kernel development with bk requires net access and so it's sufficient,
> when it's available over the net. On the other hand SubmittingPatches
> describes the lowest common denominator, which works with any SCM and
> doesn't favour any of them.
Huh? BK requires no more net access than you require when submitting
a regular patch. You need to be connected to move the bits. Working
disconnected is one of the things BK does best, compare it to any other
tool and you can do far more with BK unconnected, simply because BK
takes the history with you.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Oliver Xymoron
> Which patches are the stealth patches?
The ones that say 'pull from here' are pretty opaque and seem to go past
without much discussion. Off the top of my head, I'd say about
I've seen about as many bk pushes as pulls but that could be perceptual
bias.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Ian Molton
> "I do this because it's FUN and
> because others might find it useful, not because I got religion".
Dude, I agree, but that is your /IDEOLOGY/, is it not?
Ian Molton
> > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > A link to the information is completely sufficient.
>
> What was Daniel's action? Remove the text. Nothing else. Sure, he
> suggested other options, but he did attempt to implement them? No.
Be realistic - how is he supposed to do that?
Ian Molton
> A steady slide toward proprietary tools and behind-the-scenes development
> in cathedral-style is an issue.
Whilst Im not sure I agree that bitkeeper is going to push things 'behind
the scenes' (its a source management tool, not the source itself), I do
think the basic point being made here has some merit. Think about it...
Ian Molton
> It's also really, really, low class to not even CC me in your attempt
> to remove the documentation I wrote from the kernel tree
> Rot in hell, closed mind.
You know, I blasted Andre H for using words that were nicer than that. And
to think you are working where he left off. worrying.
And its /well known/ that you read here. I think not CCing is not a heinous
offense in this case.
Ian Molton
> Or maybe using a SCM puts more pressure on the developper which
> writes better code, which will get accepted with less discussion.
I dont buy that. Its well known that teams of programmers tend to write
WORSE code when they dont talk to each other.
Ian Molton
> That is completely different. Linus owns the Linux kernel.
Out of interest, since when?
Ian Molton
>
> You tried to -remove-, not include something.
Well, what else can he do? he can hardly go back in time and start the
discussion that really should have happened...
Ian Molton
> But no, in your eyes, I'm just another stupid BK person who's
> contributing to the downfall of Linux, and is in the "in" club.
I dont think Daniel claimed BK was contributing to linux downfall.
He said that having proprietary stuff in the kernel was a bad idea.
We dont allow proprietary modules in the kernel, why should docs be any
different?
Arnaldo Carvalho de Melo
> Russell King Awoke this dragon, who will now respond:
> > But no, in your eyes, I'm just another stupid BK person who's
> > contributing to the downfall of Linux, and is in the "in" club.
>
> I dont think Daniel claimed BK was contributing to linux downfall.
>
> He said that having proprietary stuff in the kernel was a bad idea.
>
> We dont allow proprietary modules in the kernel, why should docs be any
> different?
The documentation being discussed is not proprietary, it only talks about a non
essential proprietary tool used now by lots of kernel hackers.
- Arnaldo
Ian Molton
> The documentation being discussed is not proprietary, it only talks about
> a non essential proprietary tool used now by lots of kernel hackers.
well, this raises an interesting point...
should documentation be regarded as part of the package it documents or
not?
is this 'bitkeeper documentation', 'documentation about bitkeeper', or
'linux kernel documentation', or what?
Arnaldo Carvalho de Melo
> Arnaldo Carvalho de Melo Awoke this dragon, who will now respond:
>
> > The documentation being discussed is not proprietary, it only talks about
> > a non essential proprietary tool used now by lots of kernel hackers.
>
> well, this raises an interesting point...
>
> should documentation be regarded as part of the package it documents or
> not?
yes, and this is the case :)
> is this 'bitkeeper documentation', 'documentation about bitkeeper', or
> 'linux kernel documentation', or what?
This is "how to use bitkeeper with the Linux kernel sources and to submit
patches to Linus", AFAIK...
As pointed out by Linus, in the jfs subtree there is similar docs, but using
CVS instead.
Ah, removing Linus from the CC list as he is not interested in this thread
at all :)
- Arnaldo
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?
David S. Miller
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.
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
Ian Molton
>
> 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'...
David S. Miller
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.
Andrew Morton
>
> From: Alexander Viro <vi...@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)
-
Ian Molton
> From: Ian Molton <sp...@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...
David S. Miller
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.
Skip Ford
>
> 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
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 <gre...@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
Andreas Dilger
> 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/
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.
Russell King
> 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 (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Jochen Friedrich
> Huh? BK requires no more net access than you require when submitting
> a regular patch. You need to be connected to move the bits.
Wrong. Many corporate firewalls allow email and http (both via proxy) and
reject any other traffic. CVS and BK are both unusable in this
environment.
--jochen
Jochen Friedrich
> > We dont allow proprietary modules in the kernel, why should docs be any
> > different?
>
> The documentation being discussed is not proprietary, it only talks about a non
> essential proprietary tool used now by lots of kernel hackers.
So would Linus accept a document on how to run Linux/390 on hercules (yet
another proprietary emulator)? This also was a FAQ on the linux-390
mailing list until the documentation is available on the hercules home
page...
Developing kernel stuff on 390 without emulator can be much fun as host
operators tend to get very pissed if the IPL ratio comes near to 1/min ;-)
--jochen
Thunder from the hill
Could you please stop carbon copying to Linux? I'd be very pissed to
receive huge amounts of carbon copies about subjects that don't even
matter to me!
About the Corporate Firewalls issue, even though Linus didn't like it,
Hans Reiser submitted a few patches as Bitkeeper patches. It doesn't
exactly seem impossible to me. Also, if you don't have the ability to use
Bk for whatever reason, no one will ever forbid you to submit patches.
Regards,
Thunder
--
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.
Thunder from the hill
On Sun, 21 Apr 2002, Thunder from the hill wrote:
> Could you please stop carbon copying to Linux?
Oops, that's a typo. I meant Linus, of course.
Anton Altaparmakov
At 10:22 21/04/02, Jochen Friedrich wrote:
>Hi Larry,
>
> > Huh? BK requires no more net access than you require when submitting
> > a regular patch. You need to be connected to move the bits.
>
>Wrong. Many corporate firewalls allow email and http (both via proxy) and
>reject any other traffic. CVS and BK are both unusable in this
>environment.
Not wrong. BK works fine over http protocol. CVS is another matter which I
cannot comment on...
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/
Ian Molton
>
> 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?!!
Rik van Riel
> > Huh? BK requires no more net access than you require when submitting
> > a regular patch. You need to be connected to move the bits.
>
> Wrong. Many corporate firewalls allow email and http (both via proxy) and
> reject any other traffic. CVS and BK are both unusable in this
> environment.
So you're telling me that what I've been doing over the
last months really shouldn't have been possible ?
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
yoda...@fsmlabs.com
> On Sun, 21 Apr 2002, Jochen Friedrich wrote:
>
> > > Huh? BK requires no more net access than you require when submitting
> > > a regular patch. You need to be connected to move the bits.
> >
> > Wrong. Many corporate firewalls allow email and http (both via proxy) and
> > reject any other traffic. CVS and BK are both unusable in this
> > environment.
>
> So you're telling me that what I've been doing over the
> last months really shouldn't have been possible ?
What he is telling you is that people whose business is hidden
behind corporate firewalls so that they can make money with proprietary
work, find it morally outrageous that other people don't give away all
their work.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
Andries...@cwi.nl
> 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
Jeff Garzik
> Hi Larry,
>
> > Huh? BK requires no more net access than you require when submitting
> > a regular patch. You need to be connected to move the bits.
>
> Wrong. Many corporate firewalls allow email and http (both via proxy) and
> reject any other traffic. CVS and BK are both unusable in this
> environment.
Wrong -- both BK and CVS can be proxied.
CVS takes a bit more effort. 'bk helptool url' gives you proxy info for BK.
Jeff
Jeff Garzik
> On Sat, 20 Apr 2002, Jeff Garzik wrote:
>
> > Which patches are the stealth patches?
>
> The ones that say 'pull from here' are pretty opaque and seem to go past
> without much discussion. Off the top of my head, I'd say about
> I've seen about as many bk pushes as pulls but that could be perceptual
> bias.
The point has been made that those patches were sent to Linus without
CC'ing lkml, in the past. Do you see any newly stealthed patches, which
were not opaque pre-BK?
Jeff Garzik
> Jeff Garzik Awoke this dragon, who will now respond:
>
> > > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > > A link to the information is completely sufficient.
> >
> > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > suggested other options, but he did attempt to implement them? No.
>
> Be realistic - how is he supposed to do that?
It's really trivial to put a document up on a Web site, before
submitting a patch to remove said document. Or to contact someone, and
get them to post the doc.
Did he even attempt to do that? No.
Jeff Garzik
> Russell King Awoke this dragon, who will now respond:
>
> > But no, in your eyes, I'm just another stupid BK person who's
> > contributing to the downfall of Linux, and is in the "in" club.
>
> I dont think Daniel claimed BK was contributing to linux downfall.
Sure he did.
> He said that having proprietary stuff in the kernel was a bad idea.
>
> We dont allow proprietary modules in the kernel, why should docs be any
> different?
The docs are not proprietary.
Jeff Garzik
> Arnaldo Carvalho de Melo Awoke this dragon, who will now respond:
>
> > The documentation being discussed is not proprietary, it only talks about
> > a non essential proprietary tool used now by lots of kernel hackers.
>
>
> should documentation be regarded as part of the package it documents or
> not?
No, it doesn't raise this point. Documentation is licensed either
separately, or with the package containing it. As it is here.
There is no "should it be regarded" questions.
Jeff Garzik
> is there a license on the distribution of the documentation in question that
> presents a legal problem for it to be distributed together with GPL kernel
> code?
No. The docs in question are covered by the GPL.
This is part of where I get the censorship jag. The doc _license_ is
GPL, so they are clearly complaining about my GPL'd speech describing
proprietary software. Fsck them, I will talk about proprietary software
as much as I like. And GPL that speech, as much as I like.
Implying (or flat out saying) that _talking_ about something proprietary
makes that speech proprietary is silly.
Daniel was trying to dictate what we can and cannot talk about, in the
kernel sources. That's offensive.
Arnaldo Carvalho de Melo
> > > We dont allow proprietary modules in the kernel, why should docs be any
> > > different?
> >
> > The documentation being discussed is not proprietary, it only talks about a non
> > essential proprietary tool used now by lots of kernel hackers.
>
> So would Linus accept a document on how to run Linux/390 on hercules (yet
> another proprietary emulator)? This also was a FAQ on the linux-390
Don't know, tried to submit?
Just checked, Hercules is not a proprietary emulator, in fact it is licensed
under the QPL. http://www.conmicro.cx/hercules/herclic.html
> mailing list until the documentation is available on the hercules home
> page...
> Developing kernel stuff on 390 without emulator can be much fun as host
> operators tend to get very pissed if the IPL ratio comes near to 1/min ;-)
<joke>
Another good question: does Linus cares about Linux S/390? ;)
</joke>
- Arnaldo
Jeff Garzik
> On Sunday 21 April 2002 17:33, Jeff Garzik wrote:
> > On Sun, Apr 21, 2002 at 03:30:38AM +0100, Ian Molton wrote:
> > > Jeff Garzik Awoke this dragon, who will now respond:
> > >
> > > > > Maybe I was to subtle, but your censorship argument is simply bullshit.
> > > > > A link to the information is completely sufficient.
> > > >
> > > > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > > > suggested other options, but he did attempt to implement them? No.
> > >
> > > Be realistic - how is he supposed to do that?
> >
> > It's really trivial to put a document up on a Web site, before
> > submitting a patch to remove said document. Or to contact someone, and
> > get them to post the doc.
> >
> > Did he even attempt to do that? No.
>
> other things and Larry agreed to do that. What do you think I should have done,
> demanded that Larry do that?
Suggestion != doing
If Linus had applied your patch, there would be a lag time during which
the doc would have no home at all.
Anything _other_ than removal before re-posting, what you attempted to
do, would have been far more palatable. One doesn't create their
fallback _after_ they nuke the primary.
Jeff
Russell King
> Here's my wrapup...
What a shame...
> This may in fact be nothing more than a fear. However if there is any
> chance I'm talking about a real phenomenon then I would indeed be remiss in
> failing to draw attention to it.
I've been trying to get you to quantify this further. So far, all we've
seen are half-sides of the story. Please give the full story:
1. Quantify how much discussion about GNU patches there is on LKML in
total.
2. Quantify how much discussion about BK merges there is on LKML.
And now this is the important bit that hasn't been done:
Including how many of each class:
a) have been included into Linus' tree.
b) have not been included into Linus' tree.
Then you can come up with sensible figures that actually mean something,
rather than some vague fear about a phenomenon that may in fact be a
fantasy.
Facts. Facts. Facts.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
ar...@fenrus.demon.nl
> It used to be that every major change would start with an [RFC]. Now the
> typical way is to build private concensus between a few well-placed
> individuals and go straight from there to feeding patches. At least,
> that's my impression of the trend.
I disagree with you here. A short 2.5 list:
BIO - Jens posted patches for MONTHS to lkml (or changelogs with the patch
on kernel.org); plenty of room for discussion
O(1) scheduler - discussed quite a bit on lkml before Linus merged it
Preempt - discussed to the extreme before being merged
Ratcache - posted for months and discussed a lot on lkml
Andrew Morten's death-to-buffer - posted to lkml quite a bit, but of course
it needs to work before it can be judged
VFS - you already said that you can see what's going on here
Now that leaves drivers and stuff. Well, for drivers, the maintainer
submitting updates, especially minor ones, directly to Linus
or the subsystem maintainer is fine by me.
Russell King
> On Sunday 21 April 2002 17:59, Russell King wrote:
> > I've been trying to get you to quantify this further. So far, all we've
> > seen are half-sides of the story. Please give the full story:
> >
> > 1. Quantify how much discussion about GNU patches there is on LKML in
> > total.
> > 2. Quantify how much discussion about BK merges there is on LKML.
>
Yes you did. The results were meaningless without reference to which
gets into Linus' tree and which don't.
> If you want to dispute my
> (unscientific) results then please repeat my survey or carry out one in
> accordance with your own, presumably higher standards.
Shrug - I'm not going to waste my time trying to prove _your_ point to
myself.
> Right. I made the conjecture,
Correct, and it isn't up to me to prove it.
> if you wish to verify/disprove it then feel
> free. I did my share of the work already.
I therefore consider this matter inadequately proven and closed.
--
Russell King (r...@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
Jeff Garzik
> free. I did my share of the work already.
This is too funny.
If you are unwilling to verify your own conjecture, go ahead and admit
it was nothing but pointless, un-backed-up wanking. :)
Jeff
Tigran Aivazian
> Daniel was trying to dictate what we can and cannot talk about, in the
> kernel sources. That's offensive.
>
> Jeff
Sorry, I resisted for two days but can't anymore...
Should I start by saying "You are all wrong" to match the style of your
signature? Just kidding, no offence, please.
The reason of my email is completely different. It's just after you said
the word "offensive" I remembered some tale whereby a sheep was trying to
argue with the wolves and the wolves were trying to pretend the sheep has
the same rights but after a while they got so annoyed that they told the
sheep "you are really rude and offensive" and ate it justifying it as
a "self-defence".
How can a sheep argue with the wolves (even if they themselves used to be
sheep not so long ago but now having become wolves are quite happy with
their position). There are two solutions: 1. for a sheep to be promoted
into the status of a wolf or 2. for a sheep to be eaten. Daniel, which one
seems more desirable?
Regards,
Tigran
Richard Gooch
> On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > Daniel,
> >
> > This is not documentation for bitkeeper but how to use bitkeeper
> > effectively for kernel development. It happens to be DAMN USEFULL
> > documentation at that for anyone wanting to use bitkeeper for kernel
> > development so IMO it fully belongs in the kernel. Just like the
> > SubmittingPatches document does, too. Or are you going to remove that as well?
>
> By that logic, we should also include the lkml FAQ in the kernel
> tree. Should we?
No. A pointer to the lkml FAQ is sufficient.
Regards,
Richard....
Permanent: rgo...@atnf.csiro.au
Current: rgo...@ras.ucalgary.ca
dean gaudet
> 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
Jeff Garzik
> Hi,
>
> Jeff Garzik wrote:
>
> > What was Daniel's action? Remove the text. Nothing else. Sure, he
> > suggested other options, but he did attempt to implement them? No.
>
> He made his intention very clear, you are interpreting something in his
> action, that simply isn't there.
How can one misinterpret the action of "<this> is my ideology.
this document offends me. I remove it."?
> > Daniel attempted to remove speech he disgreed with from wide
> > distribution -- on distro CDs, kernel.org mirrors, etc. I am hoping
> > it is plainly obvious that removing a doc from one of the mostly
> > widely distributed open source projects reduces the doc's distribution
> > dramatically. _That_ is a form of censorship, just like buying out
> > printing presses, to silence them, in the old days. It's still
> > around... just progressively harder to obtain.
>
> Censorship requires the means to enforce it and has Daniel this ability?
> Could we please stop these "censorship" and "ideology" arguments? In
> this context they are simply nonsense.
Ideology was the __sole__ reason for removing the document.
Since Linus uses BK, and the document is there in the first place
to make life easier, Daniel is therefore making life more difficult
because of ideology, and no other reason.
If you want to be really semantic, Daniel's patch was an attempt to
censor, not censorship itself. But when it's a GPL'd document that
I wrote, I'll treat them equally.
> kernel development with bk requires net access
No it doesn't
> when it's available over the net. On the other hand SubmittingPatches
> describes the lowest common denominator, which works with any SCM and
> doesn't favour any of them.
> Personally I don't care what tools people use, but I'm getting
> concerned, when a nonfree tool is advertised as tool of choice for
> kernel for development as if there would be no choice.
Linus, myself, and others _repeatedly_ say that BitKeeper is _not_
the sole means of submitting patches. Thus actively and repeatedly
disputing "as if there would be no choice."
This policy of supporting GNU patches has been in existence since
time began, and absolutely nothing has changed in that regard.
To imply otherwise is to spread Fear, Uncertainty, and Doubt.
> bk has advantages
> for distributed development, but beside of this they are alternatives
> and we should rather encourage users to try them and to help with the
> development of them.
How many users here, besides me, have actually done serious patching of
the CVS source? The argument that kernel developers will help develop
an SCM is admirable, but unrealistic IMO. Otherwise, kernel hackers
would have written a BK alternative by now, instead of simply whining.
> But there isn't anything like that, so Joe Hacker
> has to think he should use bk as SCM to get his patch into the kernel,
> because Linus is using it.
If Linus and others repeatedly claim this is untrue, and repeatedly
prove this by taking GNU patches, your statement is utter fantasy.
Jeff
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
Richard Gooch
> On Sunday 21 April 2002 18:27, Richard Gooch wrote:
> > Daniel Phillips writes:
> > > On Saturday 20 April 2002 18:13, Anton Altaparmakov wrote:
> > > > Daniel,
> > > >
> > > > This is not documentation for bitkeeper but how to use bitkeeper
> > > > effectively for kernel development. It happens to be DAMN USEFULL
> > > > documentation at that for anyone wanting to use bitkeeper for kernel
> > > > development so IMO it fully belongs in the kernel. Just like the
> > > > SubmittingPatches document does, too. Or are you going to remove that as well?
> > >
> > > By that logic, we should also include the lkml FAQ in the kernel
> > > tree. Should we?
> >
> > No. A pointer to the lkml FAQ is sufficient.
>
Not really. I'm just answering your question about whether the lkml
FAQ should be distributed with the kernel sources. As far as I know,
there is a pointer, but I haven't looked. If there isn't feel free to
send Linus and Marcelo a patch.
> Then certainly, a pointer to the BK documentation would be
> sufficient, and save download bandwidth as well.
I wasn't talking about that. And I won't O:-) But I wonder if I added
something to the lkml FAQ whether we might avoid some rounds of this
repeat flamewar?
Nah.
Regards,
Richard....
Permanent: rgo...@atnf.csiro.au
Current: rgo...@ras.ucalgary.ca
Jochen Friedrich
> >Wrong. Many corporate firewalls allow email and http (both via proxy) and
> >reject any other traffic. CVS and BK are both unusable in this
> >environment.
>
> Not wrong. BK works fine over http protocol. CVS is another matter which I
> cannot comment on...
Ok, but there are other scenarios where only email is available (often via
mail gateways like softswitch on os/390)...
--jochen