On Fri, 14 Mar 2003, Larry McVoy wrote:
> But it can't read BK repositories in many cases. We support compressed
> repositories, it can't read those. We support many corner cases which
> SCCS didn't handle, it can't read those. It can't reproduce all of the
> extensions that we have added. In other words, saying what Pavel has
> is like BitKeeper is like saying cat is like Word because they both read
> data off of disk.
>
> That's the whole point. If we sit back and let people think that he has
> something remotely similar to BK, it devalues BitKeeper in the mind of
> those people. Since this is a very complex system with lots of subtle
> features, people easily get confused. What Pavel has doesn't approach
> the functionality of CVS, let alone BitKeeper, yet he is describing it
> as a BitKeeper clone. If we allow that, we're just shooting our brand
> name dead.
Ok, let's try again. Because honestly I'm pretty sick of this BK saga on
lkml. It's maybe time to understand if people here is against Larry or
against the BK license itself. It seems to me that there's the request of
a read-only tool that is able to read BK repositories to fetch the latest
kernel trees. I proposed before to Larry and to lkml to have Larry to
release a read-only ( read-only here means, able only to fetch sources and
related information ) BK binary under different licensing. Why this
couldn't solve the problem if Larry and the anti-BK movement will find an
agreement on the license ? Larry, is it possible to release such tool
under a less strict license ?
- Davide
-
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/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:40 EST