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
>�� >>>
>�� >>>
>�� >>
>�� >
>
>
>