On Wed, Apr 22, 2015 at 7:55 PM, stepharo <stepharo@free.fr> wrote:
andrei

You talk about releasing.
I talk about changes that should be done on a system while people are not active.

If we are all on vacation, or you really really need a bug fixed, or you make a change that touches a lot of��
packages then I see no problem if you make a slice and notify us so we can back port it.

What I would like to avoid is this becoming the default behaviour any time you want to make change that is
just related to a project that is maintain by configurations.

Right now for rubric you can just commit you package to the rubric repo under the pharo team, create a new version��
using versioner, copy it to PharoInbox50, make an issue to integrate it and integrate it. A few more steps then��
working with slices but you do not have to wait for us to integrate :). You might get some merge conflicts
when we are actively working on rubric but then we are around to help with the merge.

Cheers,
Andrei

��

Stef


Le 22/4/15 15:29, Andrei Chis a ��crit��:
In all new tools that we did we tried to have only 2-3 packages and use tags to organize classes in a packaged (GT-* has 9 packages for 3 projects).
This allows for very simple configurations with clear dependencies.
Glamour has more packages (17) but those should also be reduced, as we do not need such a low level of granularity. ��

Given that support for working with multiple nested configuration is not great we can merge all GT-* projects into one configuration.
I would still like to have different configurations for Glamour and Rubric as they are separate projects.
So we can have just three configurations (each one for a separate project that can be released independent of the others):

ConfigurationOfGToolkitCore
----> ConfigurationOfGlamourCore
---------> ConfigurationOfRubric

This would make releasing a new version easier with the current support from versioner.
Releasing a version for all three configurations at once would still require some manual updating of versions, but that's a less frequent use-case.

Cheers,
Andrei


On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
exactly.
what we need in the long term is a complete better integration process.
I dream to have a git pharo project with submodules and pull requests.

Slowly the tools are coming, but this will take time to implement.
In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal.
Even if they look not easy because we are still building it, or too used to previous ways of doing it.

Esteban

> On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
>
> And do not forget that with better Pharo modularization it will start
> to be a problem on more lower level. When eg. Morphic will be an
> "exteranal" Pharo package.
>
> -- Pavel
>
> 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
>>
>> On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com> wrote:
>>
>> 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.
>>
>>
>> then you have two options:
>>
>> 1) you rewrite your configurations to not need nested configurations. This
>> is not recommendable in huge projects like Seaside, but things like GTools
>> are easily (I did a quick check and your 3 configurations have in total 7
>> packages��� would not be a problem to have them without nesting projects and
>> just using the packages).�� In fact, this is how Dale recommends using
>> configurations (if I understood him right).
>> 2) we enhance the tools to also allow the commit of nested packages.
>>
>> I think both approaches needs to be done: you don���t need unnecessary
>> complexity in your configurations and we need to add some nesting support to
>> commit new version.
>>
>> What is not admisible, IMO, is to do something that is wrong just because it
>> looks easier in the short term (and I say ���in short term��� because what looks
>> easier now will generate a lot of problems in the future).
>>
>> cheers,
>> Esteban
>