Re: [RFC] Linux Kernel Subversion Howto

From: Larry McVoy (lm_at_bitmover.com)
Date: 02/09/05

  • Next message: Jon Smirl: "Re: [RFC] Linux Kernel Subversion Howto"
    Date:	Wed, 9 Feb 2005 10:46:29 -0800
    To: Nicolas Pitre <nico@cam.org>
    
    

    On Wed, Feb 09, 2005 at 12:17:48PM -0500, Nicolas Pitre wrote:
    > On Tue, 8 Feb 2005, Larry McVoy wrote:
    > > You know, you could change all this. Instead of complaining that we
    > > are somehow hurting you, which virtually 100% of the readers know is
    > > nonsense, you could be producing an alternative answer which is better.
    >
    > IMHO something is flawed in this whole argument. Why would someone be
    > interested into any alternative answer for working on the Linux kernel
    > tree if the whole thing can't be imported into it with the same
    > granularity as can be found in BK? IOW what's the point to alternatives
    > if you can't retrieve the entire workset?

    Please explain to me where the data is being lost. 100% of the patches
    are available on bkbits.net with no license agreement required. They
    always have been.

    The problem is that you want us to tell you how BK manages those patches.
    That was never part of the agreement, in fact we made it clear in the
    license that that information was considered to be IP and could not be
    distributed. How BK does that is our business, not yours. If you want
    to know how BK does it you must go figure it out without the benefit
    of BK itself or metadata managed by BK.

    While I understand that you don't like it, is there no sense of fairness
    left? We did the hard work to create BK. Some of us worked for *years*
    without pay to create this product. Some of us put our life savings
    into the product. It's our IP, we paid heavily to create this, is it
    so unreasonable of us to want to protect our work? I believe we are
    within our legal rights, or so our legal team tells us, but that should
    be beside the point. It's our work. We paid for it. We certainly
    don't have any obligation to tell you how we did it and to us it seems
    pretty unreasonable that you don't just go off and do the work yourself.
    And pretty unadmirable as well, don't you have any faith in your own
    abilities?

    -- 
    ---
    Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
    -
    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/
    

  • Next message: Jon Smirl: "Re: [RFC] Linux Kernel Subversion Howto"

    Relevant Pages

    • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
      ... > Sorry this wasn't meant to be a dig at your patches - I guess it turned ... where I went wrong because regression performance is wrong. ... it'll work just fine" fashion. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: kernel.bkbits.net off the air
      ... they could be used to recreate the whole repository in whatever format ... I guess it's just a matter of importing them like patches into arch. ... I did use the CVS gateway before to have a base tree to verify that the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] do_wait fix for 2.6.10-rc1
      ... almost certainly requires that a threaded app waits for its children in ... But maybe it's because I just missed some reason why this all is ok. ... three patches for the same piece of code withing minutes. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: clone() <-> getpid() bug in 2.6?
      ... the license doesn't allow for anything but patches, ... since I actually _agree_ with you that qmail has some ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] (18/22) task_thread_info - part 2/4
      ... > Nothing subtle with it, especially since this is the only place with any ... we could have multiple versions setup_thread_infoand every one ... small (50KB in 7 patches). ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)