Le 22/04/2015 20:05, stepharo a écrit :
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)
I agree. What I said is that if Pharo core hackers do not take a bit of time to package and push upstream (i.e. to the external project) their fixes, then it will be hard for the external project maintainer to reconcile Pharo and his stream. Note that as the Rubric maintainer, if I go on holiday for three weeks, I may have to cope with a jump of around 30 to 50 versions of Pharo main to adjust too... If this happens to be the period you go on a fixing bug chase over Rubric, then the merge may be a tad challenging ;)
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.
I consider that some external projects sufficiently staffed may want to react this way. Up to them...
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.
In fact, we do. Apart of the github/bitbucket kind of stuff, it is also possible to use smalltalkhub in that way. It's just a matter of organizing your projects and branches (with one smalltalkhub repository per branch). If you organize yourself that way, you'll end up being very close to a git / branch type of approach. Thierry