[lkml]   [2005]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BK] upgrade will be needed
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).

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.

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 14:10    [W:0.245 / U:11.784 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site