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
