[squeak-dev] [ExperimentalCoreRelease] PharoCore-1.0-10508rc2 vs SL3dot11-9499-alpha

Igor Stasenko siguctua at gmail.com
Fri Mar 12 20:33:29 UTC 2010


On 12 March 2010 20:44, keith <keith_hodges at yahoo.co.uk> wrote:
>>> ong comes a new process which shuts him out from contributing to squeak,
>>> as it has me, and we are told...
>>
>> Bullshit.
>>
>
> Ok, question 1, how do I load MC1.5 into trunk? without breaking it?  I need
> features of MC1.5.
>
> Question 2, My sources/changes innovation, is going to be produced and
> managed in an external repository, this is where the the code is going to
> develop and evolve.
>
> Trunk doesn't have an integration step, trunk doesn't have a package
> management solution that manages anything external to trunk. Say I have 3
> experiments going, for different sources/changes history mechanisms, how
> does trunk allow me to publish them and provide them as options to users to
> pick for their image?
>
> I can upload a solution to trunk, but only one solution, and then only when
> it is finished and perfect, but for people like me, my code is never
> finished and perfect so it will be a while. By the time I have done it,
> trunk will have moved on and left me behind.
>
> When my solution is loaded into trunk where is the primary repo for managing
> my code, is it trunk, where anyone could change something? I would rather
> gather a team of interested people around the repo externally and have it
> integrated into a release periodically.
>
> "trunk" is conceptually a repository for one monolithic image, and it is not
> the image I want. If I contribute something it will probably not be the
> image you want, and the trunk process is very fragile, and only moves
> forwards.
>
> When i develop I don't move forwards all the time, it is just not natural.
>

Keith, you are right, what can i say.
But the problem is much broader than trunk per se. And it is not only
the Squeak/smalltalk who meets such problem.
If you change the way how system works, change the protocols and
interactions, inevitably any code which depending on using old way is
doomed to fail.
So, what is the point in stating obvious?
Do you have a concept which completely avoids all of the problems
related to system evolution, made by a different (groups) of people at
different points in time, in different directions, often solving the
same problem using different approach?

> Keith
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list