> > Look- if Linux adopts Bitkeeper, you really should pay attention to that.
> > I doubt you'd find a more difficult set of software engineers to keep code
> > in sync for than the Linux folks- if Bitkeeper works for them and
> > essentially makes a rational release train for Linux, then a major
> > glaring flaw in Linux' strategy that keeps serious businesses from really
> > being able to trust it will be removed. Think about it.
>
> I think this all fails to address the distribution problem, however.
> Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb,
> all interfaces in extremely common use today? It's not just enough to
> say "something will be worked out" as an answer either, not when
> contemplating a move which will remove services currently in heavy
> operational use. Think about it. :)
I'll try, but it hurts my head ("Why, Ale, man! Ale's the stuff to drink,
for them whom it hurts to think!"...)
I wasn't suggesting that we jump..I would like to see a plan. I believe
BitKeeper and other tools are a good set of tools for the next 5-10 years
for *development*.
*Distribution* is a separate issue. Again, CVS is a fine tool for
distribution and asymmetric (biased toward a higher level of outbound
source changes) development. It all depends on what we want. And I'll have
to admit that distribution of binaries && source is not something that
always is on the top of my list (well, *I'm* not working for a software
distribution company...:-))..
My comment about 'think about it' is that if Linux gets it's chaotic
source non-management corrected and is able to successfully coordinate all
the relatively anarchic and free running clock different groups then the
'predictability and reproducibility' concerns of commercial buyers are
closer to being met (which is silly because of how really chaotic internal
company release spasms are, SGI being a notorious example- but there it
is).
If FreeBSD (and NetBSD and OpenBSD) are to continue the way it is now, CVS
is probably a good enough tool. However, if you incorporate something
like BitKeeper into the picture, then it actually becomes technically more
feasible to even begin *considering* a *BSD coordination- you start to
have to toolset that can manage large amounts of code that is mostly alike
but differs in enough ways to be too hard to just merge this week.
But then again you might say, "Pshaw- Matt's been smokin' some serious
rope again".....
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
