[Request]: Feed MetaRepoForXyz Configs Back to Projects
For example, Soup's config was updated to declare a stable version for 4.0. It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was confusing that loading from the config browser worked, but loading via another config as a dependent project did not (since we use the canonical repo in that use case). Specifically, I am asking that if we update a config, and it's not Pharo xyz-specific (i.e. may break other platforms), that we commit back to the canonical repo or notify the maintainer if we don't have repo access. This policy would obviously be especially easy for any project owned by the Pharo team. Thanks :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
It seems very logical to require configs to be save into there own repos. The other locations should just be copies.
On 10 May 2015, at 18:45, Sean P. DeNigris <sean@clipperadams.com> wrote:
For example, Soup's config was updated to declare a stable version for 4.0. It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was confusing that loading from the config browser worked, but loading via another config as a dependent project did not (since we use the canonical repo in that use case).
Specifically, I am asking that if we update a config, and it's not Pharo xyz-specific (i.e. may break other platforms), that we commit back to the canonical repo or notify the maintainer if we don't have repo access. This policy would obviously be especially easy for any project owned by the Pharo team.
Thanks :)
----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes this is important we should think modularly. Le 10/5/15 18:45, Sean P. DeNigris a écrit :
For example, Soup's config was updated to declare a stable version for 4.0. It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was confusing that loading from the config browser worked, but loading via another config as a dependent project did not (since we use the canonical repo in that use case).
Specifically, I am asking that if we update a config, and it's not Pharo xyz-specific (i.e. may break other platforms), that we commit back to the canonical repo or notify the maintainer if we don't have repo access. This policy would obviously be especially easy for any project owned by the Pharo team.
Thanks :)
----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-05-11 12:15 GMT+02:00 stepharo <stepharo@free.fr>:
Yes this is important we should think modularly.
This is one of my issues when dealing with configurations: the need to copy them in many different places (the MetaRepo for each supported pharo version, the Smalltalkhub repo for the project, github, etc....). Now, I write a configuration once and for all, and that configuration delegates to baselines which are hosted in branch or version specific repositories (one repo if github, multiple repositories if smalltalkhub). Metacello/Git inspired workflow ;) Thierry
Le 10/5/15 18:45, Sean P. DeNigris a écrit :
For example, Soup's config was updated to declare a stable version for
4.0. It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was confusing that loading from the config browser worked, but loading via another config as a dependent project did not (since we use the canonical repo in that use case).
Specifically, I am asking that if we update a config, and it's not Pharo xyz-specific (i.e. may break other platforms), that we commit back to the canonical repo or notify the maintainer if we don't have repo access. This policy would obviously be especially easy for any project owned by the Pharo team.
Thanks :)
----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Canât we have configuration server pointing to the configurations of the projects in the repos and getting all supported versions of pharo out of them instead of having a dedicated repo for each pharo version? Uko
On 11 May 2015, at 14:06, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-05-11 12:15 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: Yes this is important we should think modularly.
This is one of my issues when dealing with configurations: the need to copy them in many different places (the MetaRepo for each supported pharo version, the Smalltalkhub repo for the project, github, etc....).
Now, I write a configuration once and for all, and that configuration delegates to baselines which are hosted in branch or version specific repositories (one repo if github, multiple repositories if smalltalkhub). Metacello/Git inspired workflow ;)
Thierry
Le 10/5/15 18:45, Sean P. DeNigris a écrit :
For example, Soup's config was updated to declare a stable version for 4.0. It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was confusing that loading from the config browser worked, but loading via another config as a dependent project did not (since we use the canonical repo in that use case).
Specifically, I am asking that if we update a config, and it's not Pharo xyz-specific (i.e. may break other platforms), that we commit back to the canonical repo or notify the maintainer if we don't have repo access. This policy would obviously be especially easy for any project owned by the Pharo team.
Thanks :)
----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t... <http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t...> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-05-11 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
Can't we have configuration server pointing to the configurations of the projects in the repos and getting all supported versions of pharo out of them instead of having a dedicated repo for each pharo version?
This does not solve one of my problems with configurations: the fact that writing a version is complex (or require a versionner use and makes for very long configurations in the end). Baselines are a lot easier for that. They do not carry old versions in their code, making them less susceptible of having a huge number of lines of code to represent past versions (and rejected / truncated in future pharo releases like it happened with package version history). Thierry
Uko
On 11 May 2015, at 14:06, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-05-11 12:15 GMT+02:00 stepharo <stepharo@free.fr>:
Yes this is important we should think modularly.
This is one of my issues when dealing with configurations: the need to copy them in many different places (the MetaRepo for each supported pharo version, the Smalltalkhub repo for the project, github, etc....).
Now, I write a configuration once and for all, and that configuration delegates to baselines which are hosted in branch or version specific repositories (one repo if github, multiple repositories if smalltalkhub). Metacello/Git inspired workflow ;)
Thierry
Le 10/5/15 18:45, Sean P. DeNigris a écrit :
For example, Soup's config was updated to declare a stable version for
4.0. It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It was confusing that loading from the config browser worked, but loading via another config as a dependent project did not (since we use the canonical repo in that use case).
Specifically, I am asking that if we update a config, and it's not Pharo xyz-specific (i.e. may break other platforms), that we commit back to the canonical repo or notify the maintainer if we don't have repo access. This policy would obviously be especially easy for any project owned by the Pharo team.
Thanks :)
----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-t... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (5)
-
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Yuriy Tymchuk