I was not attempting to rewrite history (indeed, attempts at rewriting history really boil my blood...so please be careful when making such accusations).
I guess it comes down to your interpretation of what exactly constitutes a fork. My definition of a fork is any line of development that occurs in parallel to any other line of development. When you download Squeak and begin writing code, you have just forked. (this very technical view of forking is perhaps influenced by my experience in developing source code management systems)
The real question is: "how often are the forks synchronized?" If Je77 and Bolot's answer to this question for ComSwiki was never, I would consider that unfortunate. However, ComSwiki does get syncronized periodically...and the more often it is synchronized, the less work involved.
A nice service that someone could provide is to maintain a web page that listed the major forks (lines of development) and for each fork, maintain a "synchronization index" that was calculated based on the frequency that the fork was updated to load and run correctly in the current Squeak release (forks could also have SIs relative to other forks as well). This information would give people an idea of how current a particular line of development stays and perhaps influence their decision whether or not to follow it (of course, past results are not necessarily an indication of future performance).
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.
- Stephen
-----Original Message----- From: Andreas Kuckartz [mailto:a.kuckartz@dokom.net] Sent: Thursday, May 31, 2001 3:12 PM To: squeak@cs.uiuc.edu Subject: Re: Community and Artifact Define One Another
Stephen Pair wrote:
I think people seem to forget that for a long time now, we've had a fork that has quite successfully co-existed with the rest of the Squeak community. I think it has also been mutually beneficial. It's called ComSwiki and can be downloaded at:
Sorry, but this is wrong - please do not try to rewrite history to justify forks. For a long time now the up-to-date ComSwiki-sources have been made available by the authors and they could be filed in to an unforked image. Maybe the source is not (yet) available for the most recent version for whatever reason but that was not the case before.
Andreas
BTW: The StSq-people have made a decision that they do *not* want to be forkers and therefore all debates about forks have become much less relevant as far as I am concerned.
Hi all!
--- Stephen Pair spair@advantive.com wrote:
I was not attempting to rewrite history (indeed, attempts at rewriting history really boil my blood...so please be careful when making such accusations).
I guess it comes down to your interpretation of what exactly constitutes a fork. My definition of a fork is any line of development that occurs in parallel to any other line of development. When you download Squeak and begin writing code, you have just forked. (this very technical view of forking is perhaps influenced by my experience in developing source code management systems)
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. :-)
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.
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.
regards, G�ran
===== G�ran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
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" syndrome.
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
squeak-dev@lists.squeakfoundation.org