Ok perfect then I will not work on changes that touch other projects. I suggest also guille not to try and we should focus on something else than in the image.
I disagree with your proposal. It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. What I propose is not an invention, is how big projects work⦠what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit.
Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. Ok I will let you enhance the modularity because my time is more expensive. Then when pharo will be modular I will come back.
Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning.
You mixed everything. Did I talk about abandon our pursuit of modularity. Now what you are suggesting is that a change that can take 10 min will take several days to be done. From my concentration and energy point of view I will not work under such conditions. May I ask you when is the last time you work on remodularizing Pharo? Because I can say that I got my share with Guille but if Pharo does not respect my time then no problem I will do something else.
We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will:
- save the packages associated to the configuration - create a new version - save the new configuration
And? I will have to - enter the repo of the external project - fight with a configuration of a project that I do not know, - no thanks - or all the external project should work for real with versioner. - But people will have to look anyway at my changes but in addition they will have a potentially incompatible version (that may be they cannot load in there image).
this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated..
TL;DR: Better enhance the tools than drop the process.
Which process? Right now what you are proposing is just slowly the remodularisation from my point of view. Because if we have to wait (and we already faced it) that a change goes in rubric and in the rubric configuration so that we can ***continue*** to work. Then we are dead. Because other projects not under our control depend on rubric and I will not fix any of them. I'm sorry I will not work on tools. So I will work on my home projects. Stef
Esteban
On 22 Apr 2015, at 07:47, stepharo <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
Stef