Well, I agree with Esteban and Thierry in the fact that making our lives easier to manage now by pushing changes into the Pharo/main branch will make things harder in the long run.

I think we can see this as a case of two dependent configurations

ConfigurationOfPharo (which does not exist but as the ad-hoc list of packages in Pharo/main)

ConfigurationOfRubric ��=> depends on ConfigurationOfPharo

Stef, I'd manage it like this:

��- push the change we have into rubric

��- open an issue number X asking for the integration of rubric with that feature

��- open an issue Y that depends on X with the other slice of changes

And here the main problem that we will have is that if we do not integrate quickly these fixes, then slices can age and become not valid.

Alternatively, we can do it in several steps, avoiding the dependency:

��- push the change into rubric

��- push the part of the change into pharo that does not break the current version of rubric (avoid the renames/removals of methods)

��- when both are integrated we do the last step that integrates the last set of changes

El mi��., 22 de abr. de 2015 a la(s) 11:15 a.��m., Thierry Goubier <thierry.goubier@gmail.com> escribi��:

Le 22/04/2015 10:21, Andrei Chis a ��crit :
>
>
> On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano <estebanlm@gmail.com
> <mailto:estebanlm@gmail.com>> wrote:
>
>�� in fact I just checked and Versioner already does that: right button
>�� on monticello over a configuration gives you a: ��create
>�� development/release version��.
>�� So only thing we need is to use the tools we already created :)
>
>
> But this only works for releasing simple configurations that do not
> depend on other configurations.
> This would work for rubric, for example, but not for other
> configurations we have in gtools.

I believe GTTools is certainly a poster case for trying to make that
process simpler.

I would really be interested to see how a combination of simpler
configurations, baselines, tags and branches would look. A kind of
hierarchical modeling where you only have configurations at the moment.

Thierry

>
> Cheers,
> Andrei
>
>
>�� > On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm@gmail.com
>�� <mailto:estebanlm@gmail.com>> wrote:
>�� >
>�� > and btw�� of course I agree repositories need to be added, and
>�� configurations kept in image.
>�� >
>�� > cheers,
>�� > Esteban
>�� >
>�� >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm@gmail.com
>�� <mailto:estebanlm@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 <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
>�� >>>
>�� >>>
>�� >>> Stef
>�� >>>
>�� >>>
>�� >>
>�� >
>
>
>