lkml.org 
[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Proposal: Linux Kernel Patch Management System

> Isn't this "new" patch maintenance system much like bitkeeper?
>
> Heh. I'm surprised Larry hasn't jumped into this discussion by now.

Hi, here I am. I hadn't resubscribed to the list after it switched from
rutgers. Sheesh, I leave you guys alone for five minutes and you go off
and rewrite BitKeeper. I should give you all jobs :-)

[...]
> why it's so nice.

I like that part, can I just quote you on that part?

> The problem, though, is that bitkeeper is only useful
> if a large number of other developers use it, and given its non-OSS
> license, it's not clear it will get that critical mass. Personally, I
> have no problem with the license. But if there are enough other people
> who are license fanatics who do have a problem with it, then bitkeeper
> loses a lot of value for me. If Linus were willing to dictate from high
> that we were going to use bitkeeper, and that all patches had to come in
> as bitkeeper changelogs, then that might get us critical mass.

I'm going to have to respectfully disagree. First of all, having a flag
day where everyone switches to BK just isn't a realistic expectation,
even if the license wasn't an issue. Things just don't work that way and
you are saying, I think, that BK is only useful if everyone switches. I
don't think that people who are using BK would agree with that statement.
You can use BK to track what Linus releases easily and nicely. In fact,
the trees at BitMover, made by the FSMlab crew (Cort and PPC friends),
are just that. Cort worked up some scripts to deal with the fact that
pre-patches are different from release patches, but other than that,
tracking the Linus releases has been trivial.

Putting stuff back from BK into Linus' tree is another matter. It would
be a lot easier if Linus maintained a BK tree and generated the traditional
patches and/or release tarballs from that tree. There are some issues
with file creates that BK doesn't handle well which would go away if there
was a definitive BK tree that Linus used. We hope that that will happen,
but even if it does, you don't have to use BK if you don't like it, or
the license, or you just think I'm a big boogerhead. If Linus had a
BK tree, he can just export the patches from it, each changeset is in
essence a patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.030 / U:25.632 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site