KernelFreeze, 2.6.14, UBZ agenda, and other bits
dilinger at debian.org
Wed Oct 19 03:55:49 UTC 2005
On Tue, 2005-10-18 at 19:28 -0700, Ben Collins wrote:
> On Tue, Oct 18, 2005 at 04:40:56PM -0400, Andres Salomon wrote:
> > On Wed, Oct 12, 2005 at 05:14:23PM -0700, Ben Collins wrote:
> > [...]
> > > >
> > > > i don't want to turn this into a yet another RCS flame, but we need to be
> > > > realistic with the goal we want to achieve and personally i prefer
> > > > kernel.org target as way more important for the entire community.
> > >
> > > After some side discussion, it seems we are going to be git only, and I am
> > > going to setup a bzr tree just for the purpose of tracking upstream
> > > mainline (Linus's tree). It will only be to get people familiar with bzr,
> > > and not for our use. Sort of a side project.
> > >
> > >
> > Where is this tree? I'm rather curious how bzr 0.1 handles kernel trees
> > compared to current git in terms of both speed and disk usage.
> Once you clone it, do "git checkout ubuntu-2.6.14"
No, I meant the bzr tree; you mentioned explicitly setting up a bzr tree
for tracking Linus' tree.
> I've never used bzr, but I can say that compared to any other RCS, git so
> far has handled the kernel faster than anything I have ever used before
> (this means, CVS, SVN, Baz and BK). Full checkout on my meazly 500Mhz PPC
> from local clone takes about 4 seconds. All the commands seem pretty fast.
Yep, I've been using both git (well, cogito) and bzr for a few months
now. I've been impressed w/ the speed of both. With bzr 0.0.7, commits
and diffs on a 2.4 kernel tree took a few seconds on my (rather slow)
> However, this isn't about comparing one RCS to another. Using git isn't
> about choosing the best RCS, it's about choosing the best RCS for us to
> use for our kernel while meeting a few criteria. The biggest of which are:
I realize that; I was interested in a bzr tree that tracks upstream,
regardless, for measuring both bzr and git for my own purposes.
> I am going to be making a bzr repo that will mirror a couple of the main
> upstream git repo's, in order to give it exposure.
Yea, that's what I'd like to know about. I guess this means you haven't
done it yet?
Andres Salomon <dilinger at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the kernel-team