Smalltalk › Pharo › Pharo Smalltalk Developers

Story of one small fix

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

Pavel Krivanek-3

Story of one small fix

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

Andrei Chis

Re: Story of one small fix

Hi Pavel,

On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek <[hidden email]> wrote:

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.
Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...
ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

Just a quick comment.

Did you edited the configurations and their dependencies by hand? Since some time I never update them by hand, only use versioner to generate a new version for ConfigurationOfGToolkitCore and automatically also update all dependencies to all other configurations that I need. Then I make just one issue to integrate ConfigurationOfGToolkitCore that also loads/updates all other configurations. I know this is still not ideal but it's significant less work than what you described.

Chees,

Andrei

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,
-- Pavel

Pavel Krivanek-3

Re: Story of one small fix

2016-06-08 11:13 GMT+02:00 Andrei Chis <[hidden email]>:

Hi Pavel,

On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek <[hidden email]> wrote:
Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.
Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...
ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

Just a quick comment.
Did you edited the configurations and their dependencies by hand? Since some time I never update them by hand, only use versioner to generate a new version for ConfigurationOfGToolkitCore and automatically also update all dependencies to all other configurations that I need. Then I make just one issue to integrate ConfigurationOfGToolkitCore that also loads/updates all other configurations. I know this is still not ideal but it's significant less work than what you described.

Yes, by hand. I do not use Versionner for packages of others because I'm not 100% sure that it will not break something.

-- Pavel

Chees,
Andrei

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,
-- Pavel

EstebanLM

Re: Story of one small fix

In reply to this post by Andrei Chis

On 08 Jun 2016, at 11:13, Andrei Chis <[hidden email]> wrote:

Just a quick comment.
Did you edited the configurations and their dependencies by hand? Since some time I never update them by hand, only use versioner to generate a new version for ConfigurationOfGToolkitCore and automatically also update all dependencies to all other configurations that I need. Then I make just one issue to integrate ConfigurationOfGToolkitCore that also loads/updates all other configurations. I know this is still not ideal but it's significant less work than what you described.

which is why I made that tool that -almost- no one uses :)

Esteban

Sean P. DeNigris

Re: Story of one small fix

Administrator

In reply to this post by Andrei Chis

Andrei Chis wrote

Did you edited the configurations and their dependencies by hand? Since
some time I never update them by hand, only use versioner

[Reminder]: Anyone using Git (like me for all my personal projects) can not use Versionner because it does not handle Baselines. This will become more and more of a problem.

Cheers,
Sean

stepharo

Re: Story of one small fix

In reply to this post by Pavel Krivanek-3

***THANKS*** Pavel.

Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process.

When the core Pharo developers are in need to change a package they should do it without updating the external package configurations.

And the external developers should check and merge the changes from the Pharo repo and when they want

release a new configuration that we will integrate.

For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane.

In fact fixing this process is part of the job description for your position.

It was

- republishing automatically changes and the configuration

- working on package validation (making sure that the catalog does not get full of not working project)

- bootstrap :)

Stef

Le 8/6/16 à 11:05, Pavel Krivanek a écrit :

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

Dale Henrichs-3

Re: Story of one small fix

In reply to this post by Sean P. DeNigris

One of the reasons that Versionner may not have been supporting
baselines is that the MetacelloToolBox support for BaselineOf was not up
to snuff.

A couple of weeks ago I added additional support for updating a
BaselineOf[1]. If additional features/support is needed from the
MetacelloToolBox level I would be glad to add whatever is needed ...

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/395

On 06/08/2016 04:57 AM, Sean P. DeNigris wrote:

> Andrei Chis wrote
>> Did you edited the configurations and their dependencies by hand? Since
>> some time I never update them by hand, only use versioner
> [Reminder]: Anyone using Git (like me for all my personal projects) can not
> use Versionner because it does not handle Baselines. This will become more
> and more of a problem.
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Story-of-one-small-fix-tp4899815p4899885.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Stephan Eggermont-3

Re: Story of one small fix

In reply to this post by Pavel Krivanek-3

On 08/06/16 11:05, Pavel Krivanek wrote:
> In ideal state you should create
> new versions of the configurations

Hi Pavel, please take a look at my earlier
contributions on this subject. This is a solved
problem.

Stephan

Pavel Krivanek-3

Re: Story of one small fix

In reply to this post by stepharo

2016-06-08 19:40 GMT+02:00 stepharo <[hidden email]>:

***THANKS*** Pavel.

Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process.

When the core Pharo developers are in need to change a package they should do it without updating the external package configurations.

And the external developers should check and merge the changes from the Pharo repo and when they want

release a new configuration that we will integrate.

But the problem is that for bootstrap we need updated configurations (or somenting like it) because we want to load all system correctly from them. So even for such small changes we need to update them somehow. Moreover, we want to test incomming slices with bootstrap. That means that for every new slice we need to create temporary configurations and run bootstrap-load process on them.

So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need:

- own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step.

- own configuration that will be aware only of Pharo and will be fully automatically managed

Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible.

For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane.

In fact fixing this process is part of the job description for your position.

It was

    - republishing automatically changes and the configuration

    - working on package validation (making sure that the catalog does not get full of not working project)

    - bootstrap :)

Of course I am aware of it :-)

-- Pavel

Stef

Le 8/6/16 à 11:05, Pavel Krivanek a écrit :

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

Denis Kudriashov

Re: Story of one small fix

So does we all agree to commit fixes for external packages by slices without new configs?

2016-06-09 9:42 GMT+02:00 Pavel Krivanek <[hidden email]>:

2016-06-08 19:40 GMT+02:00 stepharo <[hidden email]>:

***THANKS*** Pavel.

Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process.

When the core Pharo developers are in need to change a package they should do it without updating the external package configurations.

And the external developers should check and merge the changes from the Pharo repo and when they want

release a new configuration that we will integrate.
But the problem is that for bootstrap we need updated configurations (or somenting like it) because we want to load all system correctly from them. So even for such small changes we need to update them somehow. Moreover, we want to test incomming slices with bootstrap. That means that for every new slice we need to create temporary configurations and run bootstrap-load process on them.

So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need:

- own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step.

- own configuration that will be aware only of Pharo and will be fully automatically managed

Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible.

For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane.

In fact fixing this process is part of the job description for your position.

It was

    - republishing automatically changes and the configuration

    - working on package validation (making sure that the catalog does not get full of not working project)

    - bootstrap :)

Of course I am aware of it :-)

-- Pavel

Stef

Le 8/6/16 à 11:05, Pavel Krivanek a écrit :

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

Pavel Krivanek-3

Re: Story of one small fix

We cannot do that right now. I hope that we will replace configurations with Cargo.

-- Pavel

2016-06-09 10:03 GMT+02:00 Denis Kudriashov <[hidden email]>:

So does we all agree to commit fixes for external packages by slices without new configs?

2016-06-09 9:42 GMT+02:00 Pavel Krivanek <[hidden email]>:

2016-06-08 19:40 GMT+02:00 stepharo <[hidden email]>:

***THANKS*** Pavel.

Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process.

When the core Pharo developers are in need to change a package they should do it without updating the external package configurations.

And the external developers should check and merge the changes from the Pharo repo and when they want

release a new configuration that we will integrate.
But the problem is that for bootstrap we need updated configurations (or somenting like it) because we want to load all system correctly from them. So even for such small changes we need to update them somehow. Moreover, we want to test incomming slices with bootstrap. That means that for every new slice we need to create temporary configurations and run bootstrap-load process on them.

So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need:

- own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step.

- own configuration that will be aware only of Pharo and will be fully automatically managed

Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible.

For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane.

In fact fixing this process is part of the job description for your position.

It was

    - republishing automatically changes and the configuration

    - working on package validation (making sure that the catalog does not get full of not working project)

    - bootstrap :)

Of course I am aware of it :-)

-- Pavel

Stef

Le 8/6/16 à 11:05, Pavel Krivanek a écrit :

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

SergeStinckwich

Re: Story of one small fix

On Thu, Jun 9, 2016 at 9:58 AM, Pavel Krivanek <[hidden email]> wrote:
> We cannot do that right now. I hope that we will replace configurations with
> Cargo.

When Cargo will be deployed ?

--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

EstebanLM

Re: Story of one small fix

In reply to this post by Denis Kudriashov

On 09 Jun 2016, at 10:03, Denis Kudriashov <[hidden email]> wrote:

So does we all agree to commit fixes for external packages by slices without new configs?

that would break the bootstrap process, so no.

Esteban

2016-06-09 9:42 GMT+02:00 Pavel Krivanek <[hidden email]>:

2016-06-08 19:40 GMT+02:00 stepharo <[hidden email]>:

***THANKS*** Pavel.
Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process.
When the core Pharo developers are in need to change a package they should do it without updating the external package configurations.

And the external developers should check and merge the changes from the Pharo repo and when they want

release a new configuration that we will integrate.
But the problem is that for bootstrap we need updated configurations (or somenting like it) because we want to load all system correctly from them. So even for such small changes we need to update them somehow. Moreover, we want to test incomming slices with bootstrap. That means that for every new slice we need to create temporary configurations and run bootstrap-load process on them.

So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need:

- own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step.

- own configuration that will be aware only of Pharo and will be fully automatically managed

Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible.

For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane.

In fact fixing this process is part of the job description for your position.
It was

    - republishing automatically changes and the configuration
    - working on package validation (making sure that the catalog does not get full of not working project)

    - bootstrap :)

Of course I am aware of it :-)

-- Pavel

Stef

Le 8/6/16 à 11:05, Pavel Krivanek a écrit :

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

EstebanLM

Re: Story of one small fix

In reply to this post by Pavel Krivanek-3

Cargo will not fix the dependency mess.

maybe it will be easy the process, but it will not fix the real problem: we have a system that’s not made in a modular way. We are working hard to make it possible, but until we finish that there will be fixes that will touch more than one “module” and then it will be a problem also with Cargo (a dependency manager does not fixes couples dependencies, just describes them).

Esteban

On 09 Jun 2016, at 10:58, Pavel Krivanek <[hidden email]> wrote:

We cannot do that right now. I hope that we will replace configurations with Cargo.

-- Pavel

2016-06-09 10:03 GMT+02:00 Denis Kudriashov <[hidden email]>:
So does we all agree to commit fixes for external packages by slices without new configs?

2016-06-09 9:42 GMT+02:00 Pavel Krivanek <[hidden email]>:

2016-06-08 19:40 GMT+02:00 stepharo <[hidden email]>:

***THANKS*** Pavel.
Yes it is the best way to make sure that nobody wants to work at this level. We discussed this problem during the last board meeting. This is why I proposed the following process.
When the core Pharo developers are in need to change a package they should do it without updating the external package configurations.

And the external developers should check and merge the changes from the Pharo repo and when they want

release a new configuration that we will integrate.
But the problem is that for bootstrap we need updated configurations (or somenting like it) because we want to load all system correctly from them. So even for such small changes we need to update them somehow. Moreover, we want to test incomming slices with bootstrap. That means that for every new slice we need to create temporary configurations and run bootstrap-load process on them.

So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need:

- own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step.

- own configuration that will be aware only of Pharo and will be fully automatically managed

Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible.

For me this is clear (for example for the icon: fix) I do not do anything if this is with the process you describe because it is insane.

In fact fixing this process is part of the job description for your position.
It was

    - republishing automatically changes and the configuration
    - working on package validation (making sure that the catalog does not get full of not working project)

    - bootstrap :)

Of course I am aware of it :-)

-- Pavel

Stef

Le 8/6/16 à 11:05, Pavel Krivanek a écrit :

Hi,

we had in the system circular package dependency between Catalog and GTools and we decided to solve it by simple moving of one method from one package to other one. However, these two packages are external packages managed by configurations. That means that we needed move the method, save dirty packages and fix both configurations.

For the catalog we have very simple configuration because it manages only one package (and dependency on STON). ConfigurationOfGTInspectorCore was more complicated because the repository already included newer development version of the modified package so we needed to merge. But because we are not the maintainers, we cannot know if the change in this package is not requiring changes in other packages provided by the configuration.

Well, the new configurations were prepared and copied into inbox. We needed to create next two issues for updating of the configuration in the system. We did it and integrated all together in one update. But that is not all...

ConfigurationOfGTInspectorCore is used by three other configurations (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and ConfgurationOfGTDebugger) that specify number of ConfigurationOfGTInspectorCore version. In ideal state you should create new versions of the configurations but that means that you need to modify configurations of all other configurations that use them. It is simpler just modify current configuration and upgrade required version number of GTInspectorCore. That means to create three next issues, each for one configuration, create new configuration versions (and check and merge the newer versions in the home repository if needed), copy them to the inbox, wait for the review and hope that during integration the Integrator will not create new versions of some packages. If yes, you need to update configurations again.

So at the end you have at least six issues because you wanted to change package for one method that has still the same content and is placed in the same class... And it can be worse. Both of these external projects have public access to the repository and are managed the same way (not mixing MC with GIT).

As you see, it is crazy and unmaintainable.

It is clear that we need to change the process. We need to discuss it deeply and some of the results may touch maintainers of the external projects integrated in Pharo but please keep in mind that the current system is clearly bad.

Cheers,

-- Pavel

Ben Coman

Re: Story of one small fix

In reply to this post by Pavel Krivanek-3

On Thu, Jun 9, 2016 at 3:42 PM, Pavel Krivanek <[hidden email]> wrote:

>
>
> 2016-06-08 19:40 GMT+02:00 stepharo <[hidden email]>:
>>
>> ***THANKS*** Pavel.
>>
>> Yes it is the best way to make sure that nobody wants to work at this
>> level. We discussed this problem during the last board meeting. This is why
>> I proposed the following process.
>>
>> When the core Pharo developers are in need to change a package they should
>> do it without updating the external package configurations.
>>
>> And the external developers should check and merge the changes from the
>> Pharo repo and when they want
>>
>> release a new configuration that we will integrate.
>
> But the problem is that for bootstrap we need updated configurations (or
> somenting like it) because we want to load all system correctly from them.
> So even for such small changes we need to update them somehow. Moreover, we
> want to test incomming slices with bootstrap. That means that for every new
> slice we need to create temporary configurations and run bootstrap-load
> process on them.
>
> So it is clear that we need configurations that will be created and managed
> automatically and will enable swapping of repositories. We had already
> several discussions on this theme and from my point of view we need:
>
> - own separate repository for every semi-external project. So something like
> fork for Pharo. With GIT it will be natural, for the management by MC it
> will be only a temporary step.
>
> - own configuration that will be aware only of Pharo and will be fully
> automatically managed
>
> Pharo developers will provide only slices and will not care about
> configuraitons at all. It will mean that maintainers of semi-external
> projects will loose part of the controll and will need to care of sync with
> own development repository but it is nothing new. Even now Pharo makes own
> forks of some projects but it is not so visible.

I have a mental block to contributing to part of Pharo maintained in
external repositories. Maybe its unreasonable, but it just *feels*
like too much friction. If I've worked on an issue, I. just. want.
to. submit. it! With Slices its dead simple - so I stick to those
(although I've been a bit unproductive of late).

Maybe some middle ground is to still use Configurations, but you add
the Configurations to a Slice and the individual packages are auto
added. Then the Slice, Configurations and individual packages are all
committed to inbox. Similar to the way integration now copies
packages from the Inbox to "internal" Main repositories, those
packages & configurations homed in other repositories are pushed there
as part of integration. So the workflow would be the same for
internal and external repositories - the only change being the target
repository.

Any other development going on in external repository would be
considered a feature branch, an would be incumbent on them to merge in
changes added to the external repository by TheIntegrator before they
submit their branch to Inbox for integration.

The other thing that would help is the Configuration being marked
dirty when child Package becomes dirty (or does it already do this?)

cheers -ben

>
>>
>> For me this is clear (for example for the icon: fix) I do not do anything
>> if this is with the process you describe because it is insane.
>>
>> In fact fixing this process is part of the job description for your
>> position.
>>
>> It was
>>
>> - republishing automatically changes and the configuration
>>
>> - working on package validation (making sure that the catalog does not
>> get full of not working project)
>>
>> - bootstrap :)
>
>
> Of course I am aware of it :-)
>
> -- Pavel
>>
>>
>> Stef
>>
>>
>> Le 8/6/16 à 11:05, Pavel Krivanek a écrit :
>>
>> Hi,
>>
>> we had in the system circular package dependency between Catalog and
>> GTools and we decided to solve it by simple moving of one method from one
>> package to other one. However, these two packages are external packages
>> managed by configurations. That means that we needed move the method, save
>> dirty packages and fix both configurations.
>>
>> For the catalog we have very simple configuration because it manages only
>> one package (and dependency on STON). ConfigurationOfGTInspectorCore was
>> more complicated because the repository already included newer development
>> version of the modified package so we needed to merge. But because we are
>> not the maintainers, we cannot know if the change in this package is not
>> requiring changes in other packages provided by the configuration.
>> Well, the new configurations were prepared and copied into inbox. We
>> needed to create next two issues for updating of the configuration in the
>> system. We did it and integrated all together in one update. But that is not
>> all...
>> ConfigurationOfGTInspectorCore is used by three other configurations
>> (ConfigurationOfGTPlaygroundCore, ConfigurationOfGToolkitCore and
>> ConfgurationOfGTDebugger) that specify number of
>> ConfigurationOfGTInspectorCore version. In ideal state you should create new
>> versions of the configurations but that means that you need to modify
>> configurations of all other configurations that use them. It is simpler just
>> modify current configuration and upgrade required version number of
>> GTInspectorCore. That means to create three next issues, each for one
>> configuration, create new configuration versions (and check and merge the
>> newer versions in the home repository if needed), copy them to the inbox,
>> wait for the review and hope that during integration the Integrator will not
>> create new versions of some packages. If yes, you need to update
>> configurations again.
>>
>> So at the end you have at least six issues because you wanted to change
>> package for one method that has still the same content and is placed in the
>> same class... And it can be worse. Both of these external projects have
>> public access to the repository and are managed the same way (not mixing MC
>> with GIT).
>>
>> As you see, it is crazy and unmaintainable.
>>
>> It is clear that we need to change the process. We need to discuss it
>> deeply and some of the results may touch maintainers of the external
>> projects integrated in Pharo but please keep in mind that the current system
>> is clearly bad.
>>
>> Cheers,
>> -- Pavel
>>
>>
>>
>

stepharo

Re: Story of one small fix

> I have a mental block to contributing to part of Pharo maintained in
> external repositories. Maybe its unreasonable, but it just *feels*
> like too much friction. If I've worked on an issue, I. just. want.
> to. submit. it!

:)

Nicolai Hess-3-2

Re: Story of one small fix

2016-06-09 16:32 GMT+02:00 stepharo <[hidden email]>:

I have a mental block to contributing to part of Pharo maintained in
external repositories. Maybe its unreasonable, but it just *feels*
like too much friction. If I've worked on an issue, I. just. want.
to. submit. it!

:)

stepharo

Re: Story of one small fix

In reply to this post by Pavel Krivanek-3

So it is clear that we need configurations that will be created and managed automatically and will enable swapping of repositories. We had already several discussions on this theme and from my point of view we need:

- own separate repository for every semi-external project. So something like fork for Pharo. With GIT it will be natural, for the management by MC it will be only a temporary step.

- own configuration that will be aware only of Pharo and will be fully automatically managed

Pharo developers will provide only slices and will not care about configuraitons at all. It will mean that maintainers of semi-external projects will loose part of the controll and will need to care of sync with own development repository but it is nothing new. Even now Pharo makes own forks of some projects but it is not so visible.

Ok I see.
Stef