Hi, On Sun, 6 Feb 2005, Larry McVoy wrote:
> [Larry continues to pull numbers out of his arse.] Out of sympathy to Al I cut the crap short. If you (or anyone else) really want to know, contact me privately. The 85% number is of secondary interest only anyway, my (undisputed) argumentation still stands, why the 44% is more important. > > Well, I'm not the one who claimed "We don't do lockins. Period." > > I'm just trying to figure out what that means... > > Hey, Roman, the statement above stands. You made the choice that you want > to go write a competing system. If you hadn't you could just use BK and > stop whining. Since you have made that choice, which is your right, > how about you produce your competing system? And stop whining that > we aren't giving you enough help. What is that you say? It's hard? > It's way harder if we don't give you a roadmap? Well gosh darn, that > must really suck for you. I'm really sorry that you can't figure it out > without our help but that's sort of the whole point, isn't it? 1. Is the kernel history locked into bk? Fact is that exporting the history from bk into a different system requires extensive scm knowledge, which makes it rather unlikely that a bk user can do this by himself. He also has various resaons to not ask for such help, from that he just doesn't care to that he is afraid bk support might be pulled. This leaves the other users, which either can't or want to use bk, with a reduced kernel history (as I have shown in the previous mails). The practical consequence of this is that a majority of the kernel history is locked into bk right now, with no way in sight to get it out of there. 2. Larry, do you really thought that kernel hackers have no other interests than kernel hacking? Do you really thought that all kernel hackers want to keep the kernel history forever in bk? I never really wanted to use bk in first place and at that time the license was annoying but I would have at least used it to push changes to other bk users. The main reason I don't use bk was and is technical, it simply doesn't do what I need. The license change just made it completely unacceptable to even bother. So while I don't care much about bk, I care of course about the kernel data and only this really sparked my interest into scm systems. Isn't it ironic that without that license change I likely wouldn't know as much about scm systems as I do now? Anyway, if I wanted to write a simple bk clone, I could have done so already easily without your help, but why should I do so if it's not what I need in first place? Sorry to disappoint your ego, but the world doesn't center around bk. Did you know, there are other scm systems out there? Once one studied a few of them, one basically also knows how bk works and it certainly helps to put your "facts" into perspective. Assuming I wrote such a "competing system". What would it change? Could I or anyone else then import the kernel data into it? How would a user proceed in order to convert his data, so he can give such a system a real test run? Well, from your perspective I'm propably already working on a "competing system", from mine I'm just playing around with some ideas from time to time, but you certainly keep encouraging me to keep on it and to develop them into something usable. It's not really a problem to continue using the bkcvs kernel tree or any other large cvs tree for testing, the bk data doesn't contain any information I don't know already. Finally the main question remains (and it will come up over and over again), how can I or anybody else get my data back out of bk? How can you claim the kernel history is not property of BM and OTOH the publically available data is provably not complete? You can continue to use my interest in scm systems to discredit me as much as you want, but I doubt we will ever find a suitable candidate, AFAICT anyone only remotely suggesting using the data in an out of bk context got pretty much the same treatment from you. Larry, could you please explain, how you exactly intend to keep the evil scm developers out and at the same time leave users a choice in their tools once they put their data into bk? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
