The thing is, if you are not doing it, you're asking someone else to do it for you.
So, some of the possibilities are:
- Decouple a bit upstream from Pharo/main, not merging everything from there immediately. Wait to see the fixes and changes to stabilize, then extract and merge.
- Wait for Pharo/main to pushes fixes to you upstream. So that Pharo/main has a duty of collecting the changes, making them all in a nice pack, and send them your way.
A good thing is to adjust the process so that pushing things back and forth is easing the task of everybody involved (motivation!).
For example, if an hypothetical Stef (not the true one :)) is changing and fixing things in Rubric inside Pharo/main, it will make merging Rubric newest version harder. Why? As a maintainer of Rubric, you know the system, its current development status. So you can decide when you reconcile with the Pharo version. I would say that Pharo core hackers should not integrate changes in external packages (only in urgence)
So, a good thing would be to make that hypothetical Stef in charge of merging the new Rubric version as well. If he finds it a pain, then he will ease his tasks by sending his fixes nicely packaged to the Rubric maintainer, so that the Rubric manager can merge that with the newest version and send it back to Pharo/main for integration by our hypothetical Stef :)
However, it would be allways possible for an external project to make it easier to fix in their project directly than in Pharo/main, but for that they need to be very reactive (make sure that fixes are propagated back very fast in Pharo/main) and make the process as easy as possible for an external contributor... I do not think that putting the stress on external projects to merge fast is good. Because you can be in the middle of something. Of course with a correct branch it can be simpler but we do not have such tool right now.
Note that, in such a process, having good tools count. This is one of the reasons for using places like bitbucket or github: they do really support that kind of process (pull requests, branches, issues, server-based merge and CI check, etc...). We could recreate that with http repositories, but with a significant amount of work.
Regards,
Thierry
Cheers, Andrei
Stef