On Tue, May 18, 2010 at 10:59 AM, Tudor Girba
<tudor.girba@gmail.com> wrote:
Hi,
I like this approach:
1. Projects can continue to be built independently. For example, in Moose, we have already a process with multiple configurations (one for each repository) depending on each other.
2. When ready, the Configurations and all related packages are "published" in the PharoXXMetacelloRepository. Having a package per Configuration makes it easy to copy it.
The only problem is that the code of Configuration mentions explicitly the repository (especially in the case of having nested Configurations, I point to a configuration by specifying the repository, package, and class). So, I guess the simplest thing here would be to provide the default "load" method to already override dynamically all repositories with the PharoXXMetacelloRepository.
Thanks Doru for pointing this. Actually, this was the only "problem" I found with the solution. My though about this where:
- I really don't care where they are the confs you depends on. I only care that YOU loads and runs perfectly.
- Maybe that other confs that you depend on are also in the same repo...but I don't think something bad to getting the conf from, for example, MetacelloRepository.
You can update the conf once you publish it and to use the PharoXXXMetacelloRepositopry instead of MetacelloRepository or whatever, but I don't think it is strictly needed. What it is needed is that it loads and works ok.� If other person, or even you, want to ALSO publish your dependences, great...
What do you think?
Cheers
Mariano
�
Cheers,
Doru
On 18 May 2010, at 09:32, St�phane Ducasse wrote:
I understand nicolas. Now my agenda is more than full.
and the proposal is here. Simple
==========================================================
One repo per version Pharo1.0, Pharo11 ... MetacelloRepository
� � �containing **published** configurationOfXXX
� � � �-> all the dependent packages are copied locally + configuration ready to load using load.
A project
� � �contain its single/or several configurationOfMyProject with the complete history
� � �people commit the config to their repository and if they want they **publish** from their repository to the version repository
� � �a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load.
For Pharo core or pharo packages that we maintain we want to maintain it as a project.
with its own repository and packages.
We can use automatic build server to validate the status or migration between different repositories
==========================================================
Stef
On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote:
The meaning of my message was don't do it for squeak, but do it for yourself.
I don't doubt the mailing list is a mine of information, but even in
the best mine you need to dig a lot before extracting the gold
nuggets.
Of course, I've got no right to control your agenda, who am I ?
You can consider the subject close, and I won't find your attitude
shocking at all.
But next time, consider writing a rationale for your own, it will
increase quality of Pharo decision process.
Best regards
Nicolas
2010/5/17 St�phane Ducasse <stephane.ducasse@inria.fr>:
nicolas
all the information is in the metacello mailing-list �and we already posted many mails on that topics in this mailing list.
I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood
in a nutshell
one repo per version Pharo1.0, Pharo11 ... MetacelloRepository
� � �containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load.
a project
� � �contain its single/or whatever configurationOfMyProject
� � �people publish the config to their repository and if they want they push from their repository to the version repository
� � �a version that they freeze (may be using tags)
For Pharo core or pharo packages that we maintain we want to maintain it as a project.
with its own repository and packages.
Then we have a server that load configuration and barks if something wrong happen. And may be we kick out
the configurationofXXX from MetacelloRepositories
Steph,
I understand how boring it may seem:
- you already discussed the subject over and over
- you already took decisions
and now we come later with new proposals, and ask you to reconsider
the work again...
more than that. :)
It looks like if we did not talk or think about what we are doing.
As for the Preferences/Settings, Pharo choices are probably very weel thought.
However, every solution will come with trade offs, and it would be
good to have a rationale justifying the choices you made, and perhaps
more importantly justifying why you did abandon some solutions,
because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ...
and find different answers in different context. Note that Squeak
evolutions might have influence on Pharo too, and it's part of the
context...
I strongly encourage you to establish your rationale on Pharo grounds
- independently of Andreas proposals, put it on the Pharo wiki and let
us know the URL.
You also know that Squeak goals are not exactly those of Pharo w.r.t.
backward compatibility, so Squeak can't just blindly replicate Pharo
solutions without a rationale.
The merit of Andreas proposal is to try and establish such a
rationale. Without it, we're bound to repeat discussions again and
again,
So to fix the problem consider that as our proposal.
Stef
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
www.tudorgirba.com
"Every thing has its own flow."