and btw… of course I agree repositories need to be added, and configurations
kept in image.
So what will happen when I publish a configuration with new package in
the repo of XXX
where XXX is under dev or under a more recent version.
They will have to merge. Because I will only publish to be able to load
the code I changed into
just the next version of Pharo so that I can continue to work on the
other parts of the changes.
Stef
cheers,
Esteban
On 22 Apr 2015, at 08:34, Esteban Lorenzano <esteba...@gmail.com> wrote:
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.
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.
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
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.
Esteban
On 22 Apr 2015, at 07:47, stepharo <steph...@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
