Alternate process
�� �� - we do a fix we publish it in Pharo and yes this touches Rubric and
�� �� - we�� integrate it in Pharo head
�� �� - then the guy from rubric merge in their trunk when they want.
�� �� �� �� it should be part of the their process to merge always with pharo trunk
�� �� - At that point they can report a problem
�� �� - then they produce at their speed a new configuration
�� �� - then we integrate when ready their change


This kind of process will be a pain for those that have to merge the changes back to their repos.
I did this for a while when I was synching the debugger repo with Pharo and even if I only had to merge maybe one slice a day it was kind of annoying.

Andrei

If we do a change that touch your project you will have to produce a configuration
and merge the change anyway.
Do not expect me to know what is the head of your project and what I should know.
You know your project so you merge the changes we propose. Then you control the speed
at which you want to release.
Else I will create stupid configuration (in the sense that may be I will break something
without even knowing it) and you will have to merge anyway the configurations and the package.
Do not dream there is no such alternative.

We should go fast to change some structural aspects and avoid to have changes that touch
external packages but there is no magic

Stef