Community and Artifact Define One Another

Stephen Pair spair at
Fri Jun 1 13:05:08 UTC 2001

> I would personally call that a branch. But that may be me being
> influenced by CVS terminology.
> [SNIP]
> > So, regardless of what the StSq people may say about forks,
> according to my
> > definition, they forked long ago.  And, I hope they sync up
> soon and often.
> :-) In my world I consider a fork to be more of a statement that
> "we are going our own way here
> and do not intend to go back" - or something like that. And as
> far as I know/can tell such a
> statement hasn't really been made by StSq - on the opposite
> actually. But hey, I haven't been
> involved for so long. :-)

In that case, then it's likely that my position on this issue has been
misunderstood.  The statement "we are going our own way here and do not
intend to go back" is not what I had in mind and is *not* a good thing in my
opinion.  There have to be some really severe issues to justify that
approach (IMHO).  And I don't any such issues exist.

> On the other hand there are priority differences between SqC and
> StSq and probably other parties
> involved too in Squeak (of course) so I can envision scenarios in
> the future where some forking
> may occur.

Hmmm...I should think that if StSq produces useful stuff, and SqC also
produces useful stuff, that there should be no reason for the two to
diverge.  It may be that separate downloads are available for both, but
there should be no reason that one should not load into the other's image
and run just fine...and, it should be easy for a third party to create a
unified system that includes the work of the SqC and StSq efforts. Good code
is good code...and, if significant divergence were to occur, I would be
suspicious that it might be due to a case of the "not invented here"

> On the other hand, one thing to realize here is that the stuff
> currently being feverishly worked
> on in StSq (at least three brilliant guys working very hard and
> producing working results) will
> hopefully make it much easier to deal with dependencies and
> packaging which will work as an
> "antidote" against any ideas of forking! So... anybody accusing
> StSq for forking blabla should
> keep that in mind I think - StSq is actually working hard to
> PREVENT forking in the future.

Yes...hopefully it will all be a moot point soon.

- Stephen

More information about the Squeak-dev mailing list