Le 22/04/2015 10:26, Andrei Chis a écrit :
On Wed, Apr 22, 2015 at 7:47 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Esteban I was thinking about the following this night.
While I understand that we want configuration only it will slow us down like hell.
Example with guille we wanted to fix a problem (I do not remember which one) we need a change to be done in rubric so we will have to publish the change in rubric repo - (find it and add it) so the rubric repo should be there before - then one guy of rubric should have a look - then merge - then publish an issue with a configuration - then only then we can work => result why do we need sync for me and guille to continue to work??? => what if Alain in on vacation? we stop working? => Remember: We did Pharo especially because people in squeak did not want that we change packages.
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.
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. 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... 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