This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: Linux-2.1.98..
View: Complete Thread (56 articles)
Original Format
Newsgroups: muc.lists.linux-kernel
Date: 1998/04/24
On Fri, 24 Apr 1998, Jakub Jelinek wrote:
> > > > Using the CVS tree is not going to help that.
> > I think the CVS could help: with every commit, there is a log message
> telling the purpose of the commit.
I use CVS for work, and I know there is a commit message.
However:
- not everybody uses it. At work, we force people to use it by mailing
out the commit messages to an internal newsgroup, so everybody sees
when a commit doesn't have a good message. Without that kind of
pressure to write the message, the messages tend to be fairly bad, at
least as far as I have seen.
- the commit messages go into a big black hole, and never come back. You
_can_ get at them, but you certainly don't get them easily, and you
_definitely_ don't get them when you try to make a combination patch.
> If you were in the CVS, you could decide on a daily basis which commits
> should go out, which should be rewritten and which are just fine...
I _do_ use CVS - just not for the kernel - and I know its limitations.
CVS does _not_ support having separate branches very well. There is
support for branching, but it is by no means very good or very easy to
use.
It is non-trivial to get _only_ the changes that correspond to a certain
series of commits, and to leave out the changes that everybody else have
been doing. At least I haven't found anything to do anything like that.
In short, CVS is not _nearly_ good enough. Sorry,
Linus
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: real BK usage (was: A modest proposal -- We need a patch penguin)
View: Complete Thread (7 articles)
Original Format
Newsgroups: mlist.linux.kernel
Date: 2002-01-30 11:00:56 PST
On Wed, 30 Jan 2002, Andreas Dilger wrote:
>
> Well, the one benefit of using SCCS directories (which are only 1/3
> louder than CVS directories)
Note that I dislike CVS too. So it's not 1/3 loader than CSV, it's
infinitely louder than nothing at all, and it's quite noticeably louder
than a ".bitkeeper" subdirectory.
> is that tools like patch, make, ctags,
> emacs (I believe), etc. already understand what they are and how to
> extract the latest version of a file from there.
So past stupidities would keep you from doing it _right_?
> If these tools were
> changed to also recognize .SCCS dirs, then BK could eventually follow
> suit, but it would be impractical until they are widely available.*
Don't be silly. It obviously works the other way. Nobody patches lots of
different tools for a situation that doesn't even exist. But patching
_one_ tool (bk) to be sane makes sense, and then if/when people start
using them, the other tools will certainly follow.
> I would have to agree. Ted uses BK for e2fsprogs, and there have been
> several times when I try to send him a CSET, but he is unable to apply
> it because it is missing dependencies, even though I know those prior
> CSETs are actually independent changes that just happen to touch the
> same files.
I won't use changesets for this reason, and Larry knows it. I'd still
apply patches, even if I was using bk. It's not as if everybody else would
use bk anyway.
The advantage of bk is that unlike CVS I can use bk in many different
places, and just clone the bk trees. Let's face it, CVS branches suck,
always have, and always will. CVS doesn't allow you to have different CVS
trees, and if one of them starts to look successful, you merge that tree
into your main one.
So I'd personally use changesets just for my _own_ use.
Now, Larry has promised me usable changesets for a long time, but it
obviously hasn't happened yet.
Linus
===
From: Andreas Dilger (adilger@turbolabs.com)
Subject: Re: real BK usage (was: A modest proposal -- We need a patch penguin)
View: Complete Thread (7 articles)
Original Format
Newsgroups: mlist.linux.kernel
Date: 2002-01-30 13:20:32 PST
On Jan 30, 2002 09:34 -0800, Larry McVoy wrote:
> On Wed, Jan 30, 2002 at 10:24:59AM -0700, Andreas Dilger wrote:
> > Well, the one benefit of using SCCS directories (which are only 1/3
> > louder than CVS directories) is that tools like patch, make, ctags, emacs
> > (I believe), etc. already understand what they are and how to extract
> > the latest version of a file from there.
> > Yup, I like 'em for that reason as well. And you can do a
> > bk clean # removes all non-modified working files
> ls # should see nothing but SCCS/
> > to clean up all that extra cruft that invariably winds up in your tree.
OK, so how about adding (optional) .SCCS and .BitKeeper support to BK
for those that care about the "cleanliness" of the tree?
> > I would have to agree. Ted uses BK for e2fsprogs, and there have been
> > several times when I try to send him a CSET, but he is unable to apply
> > it because it is missing dependencies, even though I know those prior
> > CSETs are actually independent changes that just happen to touch the
> > same files.
> > Please see the response to Ingo and see if you could do what I suggested
> there. I believe that would work fine, if not, let me know.
Yes, technically it works fine, but practically not. For example, I want
to test _all_ of the changes I make, and to test them each individually
is a lot of work. Putting them all in the same tree, and testing them
as a group is a lot less work. More importantly, this is how people do
their work in real life, so we don't want to change how people work to
fit the tool, but vice versa.
> > Also, (BK feature request time) there are times when I've done a 'bk citool'
> > and committed a bunch of changes into a CSET, and later on done some more
> > testing which revealed a bug or found that I'd forgotten to change the
> > man page to track the changes I made. I'd much rather be able to merge
> > some more changes into the same CSET instead of creating a second CSET and
> > now have two CSETs to ship around for what is logically a single change.**
> > In the next release, there is a "bk fix -c" that does what you want. It
> reedits the entire changeset, and preserves all your checkin comments.
> You don't want to use this if the changeset has propogated out of your
> tree, but I use it all the time for exactly the situation you describe
> above. It will be in bk-2.1.4.
Yes, I had thought about the CSET propogation issue also, but in my cases
it is generally not an issue. If the CSET got a different version/ID than
the original, it would help avoid such issues also.
I suppose the parallel (if 'bk fix -c' doesn't allow it) would be to allow
splitting a CSET into smaller parts, so in case you committed two unrelated
changes to a single CSET (i.e. overzealousness in the 'bk citool' window),
you could unmerge them for separate inclusion if needed.
> > I think it would quickly become a nightmare if you had to submit (and
> > have accepted!) all of your changes to Linus IN ORDER. As it stands now,
> > there are lots of discrete changes I have in my ext2 tree, and whenever
> > I get around to it or when people hit the same bug as me I generate a
> > patch, edit out the irrelevant parts, and send it out.***
> > Yeah, we know. Read the other mails and tell me if you think that the
> false dependency remove largely fixes this, somewhat fixes it, or doesn't
> help.
Yes, it is mostly the false dependency issue at work. While avoiding this
on a per-file basis is a start, you really need to avoid it on a per-line
basis.
> > 2) Allow "proxy" CSETs to be included which say "the changes from adilger
> > adilger@lynx.adilger.int|ChangeSet|20011226061040|56205 changed lines
> > X-Y, Z of file fs/ext2/super.c" but doesn't actually contain those
> > changes, so that the CSET dependency graph is still kept intact.
> > In other words, "proxy" == "place holder".
Yes.
> This is doable but it makes synchronizing repositories quite a bit more
> complex. I.e., if I pull from you and I have place holders and you have
> the real thing, should I get 'em or not?
I would say yes, always. In my (limited) BK experience, when I pull I
generally want to get everything, and I push/send only specific things.
The proxies would only be needed if you didn't want everything.
> If the answer is always "or not", then this is a doable thing. We'd
> need to modify the "bk takepatch" code path to do the right thing when
> given the real patch but that's doable as well. Interesting idea, we
> could do this and it would be relatively fast to do, like a week or two.
Yes, the good thing about the proxy CSET idea is that it allows the
reciever to avoid the actual out-of-order patch application problems,
and still keeps the knowledge about per-line changes to a file.
As for what would happen when someone changes the lines that a proxy CSET
refers to, I would imagine that it would be like a merge where all of the
potential changes from the proxy are discarded.
> > It would also lose the BK CSET identification, which would tell the
> > original submitter (and his local repository) that the patch was applied,
> > We wouldn't lose it, we'd have to add some extra state to say it is in there
> but only as a placeholder, so keep bugging Linus.
This is out of context. This was referring to applying CSETs as regular
patches, and is unrelated to the proxy CSET idea.
The mere fact that a proxy CSET might be visible (with submitter
identification) would be useful. Some people might use the real CSETs
instead of the proxies (ala developing against -dj or -ac kernels instead
of -linus kernels) and it wouldn't introduce extra conflicts/merges later.
If they actually needed what Linus had as a proxy CSET, then it would be
grounds for merging that proxy for real.
===
Message 5 in thread
From: Jeff Garzik (garzik@havoc.gtf.org)
Subject: Re: real BK usage (was: A modest proposal -- We need a patch penguin)
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-01-31 14:20:41 PST
On Thu, Jan 31, 2002 at 09:11:10AM -0800, Larry McVoy wrote:
> This thread has been about the idea of being able to send any one of those
> changes out in isolation, right? That's the problem we are solving. But
> your statement is that you want to test them all at once, testing them one
> at a time is too much work.
Maybe, maybe not. When hacking on filesystems I try to produce
"viro-style" patches, which are a series of patches, each containing
a single transformation. Each one is tested in isolation in addition to
the final product. Extremely useful for nipping problems in the bud
sooner rather than later.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Message 6 in thread
From: Larry McVoy (lm@bitmover.com)
Subject: Re: real BK usage (was: A modest proposal -- We need a patch penguin)
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-01-31 15:00:18 PST
On Wed, Jan 30, 2002 at 01:03:19PM -0700, Andreas Dilger wrote:
> > Please see the response to Ingo and see if you could do what I suggested
> > there. I believe that would work fine, if not, let me know.
> > Yes, technically it works fine, but practically not. For example, I want
> to test _all_ of the changes I make, and to test them each individually
> is a lot of work. Putting them all in the same tree, and testing them
> as a group is a lot less work. More importantly, this is how people do
> their work in real life, so we don't want to change how people work to
> fit the tool, but vice versa.
There is a subtle point that this comment misses, it's worth thinking about.
This thread has been about the idea of being able to send any one of those
changes out in isolation, right? That's the problem we are solving. But
your statement is that you want to test them all at once, testing them one
at a time is too much work.
Doesn't that mean that you don't even know if these changes compile, let
alone run, when you send them out individually? You haven't tested them,
you've only tested the set of them as one unit.
In many environments, BK is doing exactly the right thing. It lets you send
the stuff you've tested together.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Message 7 in thread
From: Andreas Dilger (adilger@turbolabs.com)
Subject: Re: real BK usage (was: A modest proposal -- We need a patch penguin)
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-01-31 15:20:57 PST
On Jan 31, 2002 09:11 -0800, Larry McVoy wrote:
> On Wed, Jan 30, 2002 at 01:03:19PM -0700, Andreas Dilger wrote:
> > Yes, technically it works fine, but practically not. For example, I want
> > to test _all_ of the changes I make, and to test them each individually
> > is a lot of work. Putting them all in the same tree, and testing them
> > as a group is a lot less work. More importantly, this is how people do
> > their work in real life, so we don't want to change how people work to
> > fit the tool, but vice versa.
> > This thread has been about the idea of being able to send any one of those
> changes out in isolation, right? That's the problem we are solving.
But what you are proposing is that I keep N trees for each of my N changes
against the baseline, keep all of those N trees up-to-date, compile
and reboot each of the N kernels for each local or upstream change, and
possibly have N! different kernels to test each combination of changes.
> But your statement is that you want to test them all at once, testing
> them one at a time is too much work.
I guess I wasn't very clear then. I will probably test changes I make
in _order_, but not necessarily in _isolation_. I may also not test
_every_ change I make individually if it is fairly minor and "obvious".
If the changes are orthogonal, testing kernel+A and testing kernel+A+B
should be enough to tell me that B works without A. That means I should
be able to send out B without everyone needing A in order to test it.
> Doesn't that mean that you don't even know if these changes compile, let
> alone run, when you send them out individually? You haven't tested them,
> you've only tested the set of them as one unit.
It boils down to "how much testing is enough" for each of the separate
changes. Is eyeballing them enough? Is compiling enough? Is a single
reboot enough? I don't have N machines, let alone N!, to test each of
the N changes I have in my tree individually.
There is also value in saying "I've had this patch in my kernel for X
{days,weeks,months} and it works fine", and by your statement above I
could only do this with a single change.
What I'm saying is that I will code a specific change A, test it, and then
usually go on to code the next change B in the tree that has A in it.
Yes, in some cases testing B in isolation is needed (big changes, or
changes which need to be benchmarked in isolation). In general you
wouldn't make change A if it wasn't worthwhile, and after it's done why
would you not want to continue using it?
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
===
Search Result 3
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View: Complete Thread (138 articles)
Original Format
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 10:20:46 PST
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
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 10:20:47 PST
On Fri, 19 Apr 2002, Daniel Phillips wrote:
> > No I do not. Read the post. I suggested placing the documentation on
> 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.
===
From: Dave Jones (davej@suse.de)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 10:40:32 PST
On Fri, Apr 19, 2002 at 07:05:52PM +0200, Daniel Phillips wrote:
> > 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.
===
From: Jeff Garzik (garzik@havoc.gtf.org)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 10:41:03 PST
On Fri, Apr 19, 2002 at 07:05:52PM +0200, Daniel Phillips wrote:
> On Saturday 20 April 2002 18:51, you wrote:
> > 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".
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
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 10:41:03 PST
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
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 11:23:50 PST
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
===
From: Larry McVoy (lm@bitmover.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 11:23:56 PST
On Fri, Apr 19, 2002 at 07:32:36PM +0200, Daniel Phillips wrote:
> 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.
> > Rather than Linux development becoming more open, as I'd hoped with the
> 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.
===
From: Larry McVoy (lm@bitmover.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 11:23:58 PST
Oh, my. A couple of thoughts:
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.
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 11:23:59 PST
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.
===
From: Eric W. Biederman (ebiederm@xmission.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 11:45:53 PST
Anton Altaparmakov <aia21@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...
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).
===
From: Eric W. Biederman (ebiederm@xmission.com)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 11:45:56 PST
Daniel Phillips <phillips@bonn-fries.net> writes:
> 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.
===
From: Anton Altaparmakov (aia21@cantab.net)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 12:20:25 PST
At 18:58 20/04/02, Eric W. Biederman wrote:
>Anton Altaparmakov <aia21@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...
>
>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.
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...
===
From: Ian Molton (spyro@armlinux.org)
Subject: Re: [PATCH] Remove Bitkeeper documentation from Linux tree
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-04-20 19:40:22 PST
Linus Torvalds Awoke this dragon, who will now respond:
> "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?
===
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: 2.1.131: some quality thoughts
View: Complete Thread (29 articles)
Original Format
Newsgroups: fa.linux.kernel
Date: 1998/12/17
In article <199812171347.FAA18668@dm.cobaltmicro.com>,
David S. Miller <davem@dm.cobaltmicro.com> wrote:
> From: alan@lxorguk.ukuu.org.uk (Alan Cox)
> Date: Thu, 17 Dec 1998 14:03:43 +0000 (GMT)
>
> CVS can handle "core" just fine. In fact a cvs that ignores
> directories not files called core by default is just plain broken.
>
> DaveM has been keeping the tree in CVS for a long time without
> problems, with remote cvs access and all the works
>
>Yes but with a ".cvsignore" at the top level which says:
>
>!core
>
>to workaround this problem.
Has somebody considered (radical, I know) to just fix CVS once and for
all, and tell people who have problems to upgrade to a newer version?
As far as I can tell, everybody agrees that CVS is being stupid in not
checking at least that "core" is a regular file before ignoring it.
My opinion is that you shouldn't work around bugs in your tool-chain,
you should fix them. Either by fixing CVS, or by using something else.
===
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: Linux v2.5.52
View: Complete Thread (12 articles)
Original Format
Newsgroups: linux.kernel
Date: 2002-12-16 09:40:21 PST
On Mon, 16 Dec 2002, Ben Collins wrote:
>
> How about pointing out some specifics? Maybe make my job easier by
> getting me some patches directly. Trying to track two seperate source
> tree's isn't as easy as you might think.
It's a lot easier if you track them _often_ instead of just occasionally.
That's the main problem I have with other peoples CVS trees - CVS has very
little support for tracking any outside sources, and that coupled with the
fact that people don't track it in a timely manner always generates
problems.
With CVS, a simple script like
(a) get current version
(b) diff against the last version you did the merge against
(c) apply the diff to your new tree
(d) _then_ do the diff against the current version
(e) delete "last version merged", make current version that.
will work pretty easily most of the time for subsystems that don't get a
lot of input from outside the "maintainer". Especially if you do it
reasonably often (you can do the back-merge even when you're _not_ ready
to actually send me your stuff), the diff from my tree is often quite
small and thus easily mergible.
If you think that "maintainer" means that nobody else can touch the tree
and that you thus don't need to care, you're WRONG.
Alternatively, never EVER make a patch against the "current kernel
version". Only make a patch against the _last_ kernel that you merged
with, and if I cannot apply it I will tell you so. Making a patch just
between your tree and mine will _always_ end up losing fixes.
===
From: Larry McVoy (lm@bitmover.com)
Subject: Re: Linux v2.5.52
View this article only
Newsgroups: linux.kernel
Date: 2002-12-16 12:50:09 PST
> Alternatively, never EVER make a patch against the "current kernel
> version". Only make a patch against the _last_ kernel that you merged
> with, and if I cannot apply it I will tell you so. Making a patch just
> between your tree and mine will _always_ end up losing fixes.
I think this is a good approach. If people sent Linus patches with some
indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
header of the patch, I'd be willing to go make bk import -temail do
the right thing, which would probably be to try and patch it in in the
working tree, but if that didn't work, it would do
bk clone -l -r$BASELINE tree tree.$BASELINE
cd tree.$BASLINE
bk import -temail ....
cd ../tree
bk pull ../tree.$BASELINE && rm -rf ../tree.$BASELINE
and you'd get BK to merge most of the work.
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: Linux v2.5.52
View this article only
Newsgroups: linux.kernel
Date: 2002-12-16 13:00:37 PST
On Mon, 16 Dec 2002, Larry McVoy wrote:
>
> > Alternatively, never EVER make a patch against the "current kernel
> > version". Only make a patch against the _last_ kernel that you merged
> > with, and if I cannot apply it I will tell you so. Making a patch just
> > between your tree and mine will _always_ end up losing fixes.
> > I think this is a good approach. If people sent Linus patches with some
> indication of the baseline of the patch, such as BASELINE=v2.5.49 in the
> header of the patch,
The problem here is that I often cannot do a sane merge.
I have no problem at all merging stuff that is a week old or so (major
clashes happen sometimes, and I ask for help, but it's rare). However, if
somebody really uses a major external CVS tree and does big patches,
eventually the likelihood of a problem grows big enough that the patch
sender might as well merge _first_ anyway, since otherwise I'll just ask
for his help.
HOWEVER, even if I end up having to ask for help, this is probably
preferable to the "just install my tree" approach, since at least we don't
lose bugfixes and other updates silently.
===
From: The Open Source Club at The Ohio State University (opensource-admin@cis.ohio-state.edu)
Subject: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-03-05 15:00:56 PST
Petition Against Official Endorsement of BitKeeper by Linux Maintainers
We, the undersigned members and officers of the Open Source Club at
the Ohio State University, are unhappy with the advocacy of the
proprietary[1] BitKeeper software for use in maintaining the Linux
kernel. The Linux kernel is an important symbol of Open Source and
Free Software for many people, and a project in which many thousands
have participated in active development. It is fine if some kernel
developers choose to use BitKeeper on their own machines, but
officially endorsing proprietary software as the means of working on
the kernel is a large step backwards for Linux, and for the Open
Source and Free Software communities.
If the core Linux maintainers begin to advocate using BitKeeper, then
there will be strong pressure on these peripheral developers to use
BitKeeper too, since it would likely be easier than browsing the
web-exported changelogs or fetching the latest diff from kernel.org.
Using a closed-source, proprietary source control system for the
kernel is even worse than using other forms of proprietary software
such as source code analysis systems, because the revision control
metadata (version numbers, branches, changelog comments, etc.), would
be stored in a format defined by the proprietary software. This
metadata is really a part of Linux, because people will want to use it
when talking about the kernel. Those who can't[2] or don't want to
use BitKeeper are left out in the cold. One of the most important
parts of Open Source and Free Software is that we, the community, are
in control. But by using and advocating BitKeeper, we would lose part
of that control.
In summary, please do not advocate BitKeeper for use by the general
community. The Linux development process seems to have worked up till
now, and we can wait a little longer until Arch[3] or Subversion[4]
are completed. Moreover, full-featured, completely functional free
versioning sytems are currently available, such as PRCS[5] and CVS[6].
We respect the kernel maintainer's freedom to use proprietary software
for their own purposes. And we ask the kernel maintainers to respect
the community's freedom from entrapment by proprietary software.
-- The Open Source Club at The Ohio State University
Signed by:
Michael Benedict <zosima@zosima.org>
Colin Walters <walters@debian.org>
Matt Curtin <cmcurtin@interhack.net>
Martin Jansche <jansche@ling.ohio-state.edu>
Balbir Thomas <thomas.1037@osu.edu>
Nicholas Hurley <hurley@cis.ohio-state.edu>
Ryan McCormack <mccormac@cis.ohio-state.edu>
Shaun Rowland <rowland@cis.ohio-state.edu>
[1] http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html
[2] Perhaps they aren't connected to the internet regularly enough,
for instance.
[3] http://www.regexps.com/#arch
[4] http://subversion.tigris.org
[5] http://prcs.sourceforge.net
[6] http://www.cvshome.org
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
View: Complete Thread (61 articles)
Original Format
Newsgroups: mlist.linux.kernel
Date: 2002-03-07 12:21:35 PST
In article <20020306221305.GA370@elf.ucw.cz>,
Pavel Machek <pavel@ucw.cz> wrote:
>
>So you basically give bk for free because it is good for you. What if
>it will stop being good for you ten years from now?
Guys, calm down.
A few points:
- I certainly don't require BK use of anybody. It makes my life
simpler with some people (mainly the ones that tend to be maintainers
of subsystems and send me lots of patches), but there are many
developers who do NOT use BK, and it doesn't slow them down at all.
For example, see the FS patches from Al Viro: the only thing that BK
has resulted in as far as Al is concerned is that the changelogs are
a lot better and include his email comments.
And I also export my tree as regular patches, the way I always have
(well, the actual format changed subtly, but that's purely syntactic)
- If Larry turns to the dark side (or, as some would say, the "even
darker side" ;) we're _still_ ok. The data isn't going anywhere, he
can't close that down. We'd just have to export it into a new format.
If worst comes to worst, and nobody has fixed CVS/subversion/whatever
by then, I can even just go back to how I used to work. Nothing lost.
- If people in the open-source SCM community wake up and notice that
the current open-source SCM systems aren't cutting it, that's _good_.
But it's absolutely NOT an excuse to use them today. Sorry. I use
CVS at work, and I could never use it for Linux. I took a look at
subversion, and it doesn't even come close to what I wanted.
And I personally refuse to use inferior tools because of ideology. In
fact, I will go as far as saying that making excuses for bad tools
due to ideology is _stupid_, and people who do that think with their
gonads, not their brains.
In short: nobody requires BK of anybody else. A lot of people really
like using it, though, and it does make some things easier. Some people
aren't convinced - David Miller is trying it out, and I haven't heard
all happy sounds from him about it. Others have taken to BK like fish to
water, and you'll pry it out of their dead cold hands.
The most productive thing people could do might be to just do a BK->CVS
gateway, if you really feel like it. Or just go on and ignore the fact
that some people are using BK - you don't actually have to ever even
know.
===
Message 10 in thread
From: Larry McVoy (lm@bitmover.com)
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-03-05 17:40:30 PST
On Tue, Mar 05, 2002 at 04:38:09PM -0600, Troy Benjegerdes wrote:
> First, CVS is COMPLETELY inadequate for the kind of distributed,
> non-centralized development that goes on for the kernel.
> > Bitkeeper solves some rather difficult problems that *NOTHING ELSE SOLVES*
> right now. This is why I've continued to use it for the last 2 years, even
> though I occasionally get annoyed that it's not free software.
> > Your efforts on this petition would be FAR better spent (and appreciated)
> by attempting to mirror several BK kernel trees with Arch or Subversion.
> You will soon find out the limitations of both, and maybe even improve
> both projects to the point that they will be useable instead of bitkeeper.
> > Instead of whining about developers using BK, go out and give us an
> alternative. Maybe then we will listen.
This is great, I was about to type in what Troy said. I had the same
reaction, if CVS/Subversion/Arch were good enough, BitKeeper wouldn't
exist. The BitKeeper team is about 75% kernel hackers, not SCM people.
If CVS had been good enough, we would all be doing Linux clusters of
some sort, something we hope to get back some day in the distant future.
Troy is right, instead of writing petitions, spend your time by providing
people with options. Do what he said, mirror the tree into CVS/etc
and you will very quickly learn why CVS/etc have serious problems.
By learning about those problems, you'll either develop some insight
which will aid you in making CVS/etc better, and you'll develop a healthy
respect for what BitKeeper can do.
As for the replacements mentioned, Subversion in particular, the SVN team
admitted before they started that SVN would certainly not be able to do
what BK can do anytime soon, in fact, they admitted it was unlikely to
ever do so. The reason for that is that they started with a centralized
design and when you try and distribute that, you learn about the zillions
of places where you needed to make a different choice. It's virtually
impossible to take a centralized SCM system and make it truly distributed
(a TCP connection back to the one CVS server is *not* distributed).
While you are thinking about replacements, it might help to know the
magnitude of what you are discussing. BitKeeper is a non-trivial project,
it has:
* close to 200 commands, with about 800 different options.
* 25,000 lines of regressions, running the full suite wraps
16 bit process ids almost twice.
* more source code written by the BitMover team than all of
Version 7 Unix, kernel and userland combined.
* a dedicated team of full time professional programmers.
More than a year ago, we had some research done to see what it would cost
to reproduce BitKeeper from scratch. At that point, it was estimated
to be about $12,000,000 and at least 3.5 years from the time a good
team started.
Anyone and everyone is welcome to try and build a better SCM system, just
don't be naive about what it is you are trying to do. It's a constant
source of frustration and amusement that people think this space is easy.
===
From: Kent Borg (kentborg@borg.org)
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-03-06 08:32:16 PST
On Tue, Mar 05, 2002 at 04:51:23PM -0800, Larry McVoy wrote:
> BitKeeper is a non-trivial project, it has:
> * close to 200 commands, with about 800 different options.
When I was recently doing some PPC work I used Bitkeeper (because PPC
folks do) and I didn't like it. It was so complicated to use, hell,
seemed like there were 200 commands with 800 options. And when I
couldn't get it to correctly export a tree I couldn't tell if I was
doing it wrong or it was a bug.
I can appreciate that the problem BK tries to solve is a big one with
subtleties that have to get done right, and, as I type this on my
notebook sitting in front of my work computer, I wish CVS were
distributed. But I am not convinced BK is as elegant in its design as
it could be, I *know* it is not as elegant in its user interface as it
could be.
I also dislike the irony of BK being proprietary. Sure, they might
have an enlightened and generous attitude not, but PGP used to be
free, then it became kinda free and then it became orphaned. Luckily
GPG came along, luckily PGP didn't have a monoploy on our history.
===
From: Larry McVoy (lm@bitmover.com)
Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers
View this article only
Newsgroups: mlist.linux.kernel
Date: 2002-03-06 11:41:23 PST
On Wed, Mar 06, 2002 at 09:54:34AM -0500, Kent Borg wrote:
> On Tue, Mar 05, 2002 at 04:51:23PM -0800, Larry McVoy wrote:
> > BitKeeper is a non-trivial project, it has:
> > * close to 200 commands, with about 800 different options.
> > When I was recently doing some PPC work I used Bitkeeper (because PPC
> folks do) and I didn't like it. It was so complicated to use, hell,
> seemed like there were 200 commands with 800 options. And when I
> couldn't get it to correctly export a tree I couldn't tell if I was
> doing it wrong or it was a bug.
And apparently you didn't file a bug because I just looked in the bug
database. Was typing "bk sendbug" too difficult?
> I can appreciate that the problem BK tries to solve is a big one with
> subtleties that have to get done right, and, as I type this on my
> notebook sitting in front of my work computer, I wish CVS were
> distributed. But I am not convinced BK is as elegant in its design as
> it could be, I *know* it is not as elegant in its user interface as it
> could be.
There are *lots* of things in BK that aren't as good as they could be.
If you want them better, you need to complain about them.
> I also dislike the irony of BK being proprietary. Sure, they might
> have an enlightened and generous attitude not, but PGP used to be
> free, then it became kinda free and then it became orphaned. Luckily
> GPG came along, luckily PGP didn't have a monoploy on our history.
PGP didn't have a business model, we do, and part of our business model
is to give it away to some of the world. It's a good business model,
BK is dramatically better because the PPC team used it and Cort went
through all sorts of stuff as BK improved. BK would easily be a year
back in terms of usefulness if it weren't for Cort and there is no way
he would have been using it if we charged for it. We get something by
letting people use it for free. It's part of our business model and
it works.
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: The direction linux is taking
Newsgroups: mlist.linux.kernel
Date: 2001-12-27 12:00:52 PST
On Thu, 27 Dec 2001, Dave Jones wrote:
> On Thu, 27 Dec 2001, Linus Torvalds wrote:
>
> > This is absolutely true - it's a _very_ powerful thing. Old patches
> > simply grow stale: keeping track of them is not necessarily at all
> > useful, and can add more work than anything else.
>
> *nod*, until they get scooped up into another tree -ac, -dj, -whatever
> and fed to you whenever you're in the mood for resyncing.
But that's nothing more than "somebody else maintains them".
I realize that quite often the author of the patch is not going to be its
maintainer, which is exactly why all the other trees are so useful.
Everybody should realize that "outside trees" are not a rogue thing. They
are _very_ important, for several reasons:
- competition keeps people honest. If I was the only holder of the keys,
nobody would even _know_ if I was corrupt. And nobody could choose with
his feet.
Look at politics: if you don't have choices, the one choice _will_ be
corrupt even if it started out with all the best intentions. The old
adage there is "Power corrupts. Absolute power corrupts absolutely".
- Different taste. Let's face it, a lot of programming is about having
taste. Sometimes I don't like the way things are done, and people prove
me wrong by other means. See the whole thing about the VM stuff with
Andrea's patches - one of the reasons I hadn't applied the much earlier
patches by Andrea was that I didn't like the zone-balancing approach.
Having external trees is _crucial_ for allowing different approaches to
co-exist, in order to show their strengths and weaknesses. And I tend
to be fairly open to admitting when I did something wrong, and somebody
else had a better tree. At least I _try_.
- Different goals. Many of the commercial vendors have vendor needs, and
they (correctly) think that those needs are the most important thing,
while I don't care about vendors and thus have different priorities.
Again, multiple trees are absolutely required to make this work.
- And imperfect patch retention. There's no question that I drop patches,
some bad, but many good. And that's going to be true of _anybody_ who
maintains anything, except somebody who just accepts anything without
question (eg CVS).
I don't think I've ever spoken out against things like -ac, -dj and -aa: I
sometimes have to explain why I do not merge things whole-sale (which
would certainly be _technically_ the easiest solution much of the time),
and I often disagree with some part of the patch, but I'm actually
surprised how often I have to _defend_ having many trees.
Just a historical note: one of the things I hated most about Minix was
that while Andrew Tanenbaum allowed external patches to the system, nobody
else could make a whole distribution. Which meant that while there existed
many trees and maintainers that were "better" (notably Bruce Evans, who
was considered to be a God of Minix), they were really painful to use, in
that you had to always do it from patches.
I fully _expect_ that somebody better comes along. At some point, more
people will simply be using the -dj tree (or whatever), and that's fine.
> And when you're ready to resync what I've got so far (currently ~3mb),
> it's going to be another full time job splitting it into bits to feed
> you linus-bite-sized chunks. (ObSidenote: When this time comes btw,
> if maintainers of relevant parts want to feed Linus their relevant
> parts from my tree, that would be appreciated, and would keep _my_ load
> down :-)
This sounds absolutely wonderful..
Note that you will notice that it's a _huge_ undertaking, and one of the
things that Alan complained about was how the fact that _I_ avoid scaling
meant that he had to scale more. I think it's a very valid complaint, and
it may make a whole lot more sense (if it is possible) to have different
people caring about different parts.
Note that this may not be possible, due to lack of modularity. We've had
to actively change the tree layout of the kernel before just to make it
easier to maintain over several people. Which is painful, but not
certainly not impossible still..
> "Used to" ? cvs @ vger.samba.org was still being maintained before
> I went on xmas vacation. Did I miss something ?
Does he allow the wide and uncoordinated write access that he used to
allow? I thought he basically shut that down, and only allows a few people
now, exactly to avoid getting too horrible merge issues..
Linus
===
From: Linus Torvalds (torvalds@cc.Helsinki.FI)
Subject: Re: Linux vs FreeBSD
View: Complete Thread (346 articles)
Original Format
Newsgroups: comp.os.linux.advocacy, comp.unix.bsd.freebsd.misc, comp.unix.advocacy, comp.unix.misc
Date: 1995/12/11
In article <DJ2IBL.71t@nntpa.cb.att.com>,
John S. Dyson <dyson@inuxs.inh.att.com> wrote:
>
>So then finally, someone who uses Linux is admitting that the Linux
>kernel development at least is not open and free. Sounds like a monarchy
>to me. (FreeBSD is somewhere between monarchy and anarchy :-)), and
>the FreeBSD kernel is unencumbered with GPL.
I might as well say the Linux kernel is unencumbered by the BSD
copyright. It cuts either way, and I happen to think that the GPL is
better suited to linux (especially judging by BSD development history).
John, you've seemed a reasonable person before, why this endless tirade
now?
I'll be the first to admit that I'm a dictator when it comes to linux: I
_don't_ like the core-team approach, and no, nobody else ever gets to
change _my_ kernel without my approval first. I go through every little
patch before it taints my personal kernel sources.
So if you want to bandy political terms, this makes linux an
"enlightened dictatorship" when it comes to the kernel, as opposed to
the FreeBSD monarchy and/or anarchy. I happen to think that this is the
best system for linux.
(Political science people will know that this has been considered the
optimal political system by some people too, the "only" problem being
the actual choice of dictator ;-)
But being a "dictatorship" doesn't make it less open, or less free. I
don't take any rights _away_ from you: I only give you the _choice_ of
using my kernel development. And I do make kernels availables at
reasonably regular intervals and the fact that I don't use "sup" is just
a technical thing, not an issue of "openness" or "freeness".
The fact that I don't give other people permission to modify my kernel
sources is just due to the fact that I'm a paranoid bastard, and I
wouldn't trust anybody with my kernel that I use on my personal
machines. I _want_ to know what goes into the kernel, and I don't trust
people to do the right thing all the time.
The "official" linux kernel is just something that I personally am
working on, and no, I don't use cvs or anything like that because I
happen to think that I can do it better myself. But you're free to
disagree, and do a Linux distribution of your own, if you want to. I
won't fight you (but I might as well unmodestly warn you that you'll
have to more-or-less devote your whole life to it if you intend to do a
better job than I do).
Where linux is really open is not perhaps the kernel as much as the
whole _system_: Linux (not the kernel, the whole thing) development is
really a matter of a lot of different people working more-or-less
independently of each other - and they may all use completely different
development stategies depending on what they feel is appropriate.
THAT is what I call open and free (*).
Linus
(*) Other people will call it confusing, but that's _their_ problem, not
mine. Freedom doesn't imply that things are neat and clean, often quite
the reverse.
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] ALSA fixes #1
View: Complete Thread (4 articles)
Original Format
Newsgroups: lucky.linux.kernel
Date: 2002-10-03 13:59:01 PST
On Thu, 3 Oct 2002, Jaroslav Kysela wrote:
> > You can import this changeset into BK by piping this whole message to:
> '| bk receive [path to repository]' or apply the patch as usual.
Don't even bother with the BK patches, I've never had them apply
successfulyl for me, because your BK tree contains ChangeSets that simply
do not exist in mine. As a result, your BK patches refuse to apply. Please
read the BK usage documentation.
Note that BK really only helps if you are careful, and I can synchronize
with your BK tree. The fact that your BK tree contains non-alsa stuff
already means that I cannot sync with it, which makes it pretty much
unusable. But even if that was fixed, what is all the OLD_USB crap, and
stuff like this:
> ChangeSet@1.676, 2002-10-03 12:03:21+02:00, perex@suse.cz
> ALSA compilation update
> - save_flags/cli/restore_flags removal
Don't even bother fixing compilation, if the end result is patches like
> @@ -140,20 +139,18 @@
> snd_printdd("sgalaxy - setting up IRQ/DMA for WSS\n");
> #endif
> > - save_flags(flags);
> - cli();
> + /* FIXME: this is really bogus --jk */
> + /* the irq line is not allocated (thus locked) for this device at the moment */
> + disable_irq(irq);
> > /* initialize IRQ for WSS codec */
> tmp = interrupt_bits[irq % 16];
> - if (tmp < 0) {
> - restore_flags(flags);
> + if (tmp < 0)
> return -EINVAL;
> - }
> outb(tmp | 0x40, port);
> tmp1 = dma_bits[dma % 4];
> outb(tmp | tmp1, port);
> > - restore_flags(flags);
> return 0;
> }
>
It's BETTER to not compile, than have obviously totally bogus code that
will break _other_ devices in the tree.
You're disabling (and never re-enabling) an interrupt that isn't even
YOURS, for chrissake! Which just means that if that irq happens to be
shared with the harddisk, for example, you just killed the whole machine!
Please, don't do crap like this. Sure, it may be an ISA driver, and if it
has the right irq you may hope that it isn't shared (technically illegal
in ISA, but certainly done nonetheless), but the old code didn't do
anything even _nearly_ that broken, and the trival spinlock replacement
should have worked quite as well as the old code ever did.
This, btw, is one reason why I don't like hidden CVS trees that are worked
on by people that don't know or care about the rest of the kernel -
because the end result ends up often being total crap, that is hidden by
large merges. I noticed this one only because the patch was of a
reasonable size, and I _shudder_ to think of what horrible things the big
broken merges have caused.
Yes, I'm frustrated. What can we do about things like this? I'll apply the
patch without the obviously horribly broken part, please don't
re-introduce it later.
===
From: Linus Torvalds (torvalds@transmeta.com)
Subject: Re: [PATCH] ALSA fixes #1
View: Complete Thread (4 articles)
Original Format
Newsgroups: lucky.linux.kernel
Date: 2002-10-03 14:58:07 PST
On Thu, 3 Oct 2002, Jaroslav Kysela wrote:
> > > > Note that BK really only helps if you are careful, and I can synchronize
> > with your BK tree. The fact that your BK tree contains non-alsa stuff
> > Please, remove the bksend script from Documentation/BK-usage/bksend .
> You don't like it and it's completely crappy. BK does renumbering of
> ChangeSets itselves. So everybody has different numbers for changesets.
The numbering is not important, and yes, it will change between merges
etc. BK doesn't actually use the numbers for anything internally, the ID's
for changesets are the cset "keys".
What is important (and what BK checks) is that the _parent_ has to exist
(and that's checked through the key, not through any numbering).
> The fix changeset was made using clean clone of BK repository of linux 2.5
> kernel tree and one "temporary" clone of first BK repository.
This particular BK changeset may have applied - a number of your earlier
ones did not. I stopped testing (for example, your _first_ bk patch in the
first ALSA merge _did_ apply, but the second patch did not - because it
depended on other changes you had done outside of ALSA, in particular
apparently you had merged code from the trivial patch tree)
> > already means that I cannot sync with it, which makes it pretty much
> > unusable.
> > Are you willing to do 'bk pull' from my BK tree to avoid such problems?
> I have already a repository on bkbits.net.
I'm more than willing to do that - that's how I do most of my BK merges by
far (I used to have to accept the JFS merges as emailed BK patches,
because IBM had these strange export rules, but that's been fixed for the
last month or two already).
But I can only do that if the tree is clean - ie there aren't "random"
changes there. Ie no BK merges with other people, no non-ALSA patches etc.
I know you've had some of those, since I've seen the effects of it through
non/applying patches, and through the fact that you obviously had the
DECLARE_BITMAP() change in your tree, even though it wasn't in mine (ie
the result of applying your patches as patches didn't actually compile
without modifications).
But if there is a clean tree to pull from, that is absolutely the
preferred method for me to sync up, _especially_ with things like drivers.
Then an email that just says
Linus,
please do
bk pull .....
to receive changes to the following files
.. diffstat list ..
through the following changes
.. changset list ..
and then I don't even need to see the diffs themselves if I can just see
that it only touches the ALSA files (that's another reason why I really
want clean trees - immediately that there is a changeset to a non-ALSA
file I want to see diffs, so that I have a clue about potential conflicts)
Linus
===