lkml.org 
[lkml]   [2005]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [BK] upgrade will be needed
    Date
    On Monday 14 February 2005 03:08, Larry McVoy wrote:
    > This is a heads up that the BK tree for the kernel is currently at 59,000
    > changesets give or take a few. The BK that you are using uses unsigned
    > shorts for the internal names of each delta which means you folks are
    > about 100 days away from things no longer working.
    >
    > The good news is that the openlogging tree for the kernel has 135,000
    > changesets so we've obviously long since fixed this problem.
    >
    > The bad news is that you will need to upgrade your BK binary in order
    > to pass over the 64K changeset boundary. The data is stored on disk in
    > ascii so it doesn't matter if you upgrade until you hit the problem but
    > sooner or later you will need to upgrade.
    >
    > We'll get the fix into bk-3.2.4 which should be out by the end of the
    > month. When we release that we'll send out notice and it would be good
    > if people gave it a try and let us know if they hit issues because in a
    > couple of months everyone is going to have to upgrade.
    >
    > It's possible that we'll be changing the BK license to conform more with
    > our commercial license but we won't do that without running it by Linus &
    > Co to make sure that it's acceptable. One change we'd like to make there
    > is to clarify the non-compete stuff. We've had some people who have
    > indicated that they believed that if they used BK they were agreeing
    > that they would never work on another SCM system. We can see how it
    > is possible that people would interpret the license that way but that
    > wasn't our intent. What we would like to do is change the language to
    > say that if you use BK you are agreeing that you won't work on another
    > SCM for 1 year after you stop using BK. But after that you would be
    > able to hack on anything that you wanted. That was more of what we
    > had in mind in the first place but we didn't make it clear. If you all
    > thought that using BK meant you had no right to hack on SCM ever again,
    > that's just not fair. We need to protect our IP but you should have
    > the right to choose to go hack SCM if that's what you (our first choice
    > is that you came and worked here, we really like kernel hackers, but if
    > you don't want to that's cool too).
    Hi,

    do you mean "if you use BK you are agreeing that you won't work on another
    SCM for 1 year after you stop using BK." for the kernel tree and developers or in general?

    i think this statement is just a kind of trying the MicrosoftBeingTheOneAndOnly way.
    it's a kind of extortion - use bk or die :/
    if it is really being that way - say goodbye to bk as soon as possible.

    regards
    mws
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:0.023 / U:1.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site