Managing Pharo external packages with Metacello, please read!

> Elliot believe me we **really** discussed that over more than a year with dale and a couple of others.
> We pushed metacello contrary to other people that said it was crap and bloated.
> So may be we are a bit slow and not that smart but we want to give a try to the setup we have in mind.
> Now we also want to have a list of packages which constitutes pharo-core that will be manage as a pharo-core
> configuration.
>
> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

>
>
> Mariano Martinez Peck wrote:
>>
>> 1) We create a squeaksource repository called Pharo10MetacelloRepository
>>
>
> Just a wee idea here, since there are all these ConfigurationOfXXX packages,
> why not have a MetacelloRepositoryForXXX (rather than
> XXXMetacelloRepository).  Maybe ConfigurationRepositoryForXXX is a better
> name?
> --
> View this message in context: http://forum.world.st/Managing-Pharo-external-packages-with-Metacello-please-read-tp2218629p2219590.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Stef
>
>
> > I was thinking about the "folders" to store copies of ConfigurationOfXXX
> > for a given release. I think that this will have problems, for example
> > for the simplest package that load fine in 3 consecutive release we will
> > have exactly 3 copies of the ConfigurationOfXXX package (not that the
> > disk space is a problem). On the other side, if a package has 19
> > versions for a given release (lets say RFB has 19 version methods in the
> > ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a
> > copy of it will be made. This copy will be full, having the 19 version
> > methods, or you just take the last version method. Also, what about the
> > pre/post do its, they will likely be similar or exactly equal between
> > releases of Pharo.
> > If you delete the methods, you also lost the history and the opportunity
> > that new users can learn or use the previous versions.
> >
> > Some time ago I proposed the idea that Metacello should have tags to
> > mark that a version method has been tested in a given fork/release. As
> > the time pass, the tags in a method will grow to mark the version has
> > been tested on.
> > But for this to work, Metacello or the tools (I would prefer Metacello)
> > must honor this tags and before loading the code in a given image by
> > comparing what image is being installed on.
> >
> > Lets put an example:
> >
> > 1. Initial creation of the configuration for package Package for Pharo
> > 1.0 uploaded to MetacelloRepository:
> >
> > ConfigurationOfPackage>>baseline01
> > "initial baseline"
> >
> > ConfigurationOfPackage>>version01: spec
> >  <version: '0.1'>
> >
> >  spec for: #common do: [
> >    spec blessing: #release.
> >    spec worksIn: 'Pharo1.0'
> >    ... ].
> >
> > 2. A new version for Pharo 1.0 (lets say a bug fix):
> >
> > ConfigurationOfPackage>>version02: spec
> >  <version: '0.2'>
> >
> >  spec for: #common do: [
> >    spec blessing: #release.
> >    spec worksIn: 'Pharo1.0'
> >    ... ].
> >
> > 3. A new Pharo release is made, no changes to the package are needed,
> > that is, it works correctly in Pharo1.0 and Pharo 1.1
> >
> > ConfigurationOfPackage>>version03: spec
> >  <version: '0.3'>
> >
> >  spec for: #common do: [
> >    spec blessing: #release.
> >    spec worksIn: #( 'Pharo1.0' 'Pharo1.1' )
> >    ... ].
> >
> > At this point the ConfigurationOfPackage has four methods: baseline and
> > three versions. Also, before loading, Metacello checks the worksIn:
> > list against a standard release string in the image is working on. If
> > it match it install the package. That is, if I start with a Pharo1.1
> > image and load the configuration, the only possible candidate version
> > to install is the 0.3, because is the only one marked to work in Pharo1.1.
> >
> > 4. A port to Squeak 5 is made. This likely will need a new baseline
> > because will need squeak specific packages to be included
> > (compatibility packages) and also maybe a Pharo compatibility package
> > will be made. Anyway, a new baseline indicating new packages
> > relationships will be made:
> >
> > ConfigurationOfPackage>>baseline02
> > "second baseline, it accounts for install in Pharo and Squeak"
> >
> > ConfigurationOfPackage>>version04: spec
> >  <version: '0.4'>
> >
> >  spec for: #common do: [
> >    spec blessing: #release.
> >    spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' )
> >    ... ].
> >  spec for: #squeak do: [
> >    ... ].
> >  spec for: #pharo do: [
> >    ... ].
> >
> > At this point the ConfigurationOfXXX is capable of install the last
> > version in Squeak and Pharo.
> >
> > If I start on Squeak 4.0 then even if I load the
> > ConfigurationOfPackage, no package will be installed because nobody has tested this.
> >
> > If I start on Squeak 5.0 only version 0.4 can be installed.
> >
> > If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed
> >
> > If I start on Pharo 1.3 no package will be installed
> >
> > 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases
> > but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1
> >
> > ConfigurationOfPackage>>baseline08
> > "second baseline, it accounts for install in Pharo and Squeak"
> >
> > ConfigurationOfPackage>>version09: spec
> >  <version: '0.9'>
> >
> >  spec for: #common do: [
> >    spec blessing: #release.
> >    spec worksIn: #( 'Pharo1.3' 'Pharo1.4' )
> >    ... ].
> >  spec for: #pharo do: [
> >    ... ].
> >
> > 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0:
> >
> > ConfigurationOfPackage>>baseline04
> > "third baseline, it accounts for install in Pharo and Squeak"
> >
> > ConfigurationOfPackage>>version10: spec
> >  <version: '1.0'>
> >
> >  spec for: #common do: [
> >    spec blessing: #release.
> >    spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' )
> >    ... ].
> >  spec for: #squeak do: [
> >    ... ].
> >  spec for: #pharo do: [
> >    ... ].
> >
> > So the tags come and go as the support for given forks and releases are
> > tested.
> > Different versions of the Package package can work in different forks
> > and in different releases of those forks.
> > It is always the job of the interested parties to add support (that is
> > version methods and baselines, or simply tags to the worksIn: list) for
> > a package in a given combination.
> >
> > What do you think?
> >
> > Cheers
> >
> > --
> > Miguel Cobá
> > http://miguel.leugim.com.mx
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> El lun, 17-05-2010 a las 09:49 +0200, Stéphane Ducasse escribió:
>> I like the idea of tags.
>> Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD
>> with all the code included.
>
> But look at Debian for example. They release a stable release, lets say
> 5.0 on January 15th. This is a iso image that includes a given set of
> package versions, lets say
>
> Package A version 1.1
> Package B version 2.0
> Package C version 2.1
>
> then they continue working on testing and unstable versions of the
> distro. Of course as the software is used all around the world, the
> users report bugs and the developers push new versions with the fixes to
> the debian repositories. The fixes can be bug fixes, security fixes and
> new features. Only the security fixes and severe bug fixes are pushed to
> the stable release (as well as to the testing and unstable branches of
> course). This security fixes are part of the security updates for stable
> installations of the distro.
> But.. after a given number of security fixes and severe bug fixes are
> collected, they release an update for the stable release, even
> generating new .iso files. Suppose that they release an update in May
> 1st. They could call it Debian GNU/Linux stable 5.0.1.
>
> The point is, even if I downloaded the stable release on January 15th,
> it is different from the version you download on May 1st. They are both
> called debian 5.0 stable and nobody expect that they are bitwise
> identical.
>
> But, when you install from the version from January and after updating
> it from the update stream, I get the same packages that the person that
> install its server from the version of May 1st.
>
> I think the same can happen to Pharo. You release a given set of
> versions (in the form of configurationOfXXX) but that doesn't means that
> those are inmutable. They will be updated to match the packages that fix
> bugs in a given external package.
>
> Now for the generation of the release, you simply script it to use the
> latest #released version of a configuration. That is the way that
> Metacello works currently, installing the latest released version by
> default.
>
> Cheers
>
>
>>
>> Stef
>>
>>
>>> I was thinking about the "folders" to store copies of ConfigurationOfXXX
>>> for a given release. I think that this will have problems, for example
>>> for the simplest package that load fine in 3 consecutive release we will
>>> have exactly 3 copies of the ConfigurationOfXXX package (not that the
>>> disk space is a problem). On the other side, if a package has 19
>>> versions for a given release (lets say RFB has 19 version methods in the
>>> ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a
>>> copy of it will be made. This copy will be full, having the 19 version
>>> methods, or you just take the last version method. Also, what about the
>>> pre/post do its, they will likely be similar or exactly equal between
>>> releases of Pharo.
>>> If you delete the methods, you also lost the history and the opportunity
>>> that new users can learn or use the previous versions.
>>>
>>> Some time ago I proposed the idea that Metacello should have tags to
>>> mark that a version method has been tested in a given fork/release. As
>>> the time pass, the tags in a method will grow to mark the version has
>>> been tested on.
>>> But for this to work, Metacello or the tools (I would prefer Metacello)
>>> must honor this tags and before loading the code in a given image by
>>> comparing what image is being installed on.
>>>
>>> Lets put an example:
>>>
>>> 1. Initial creation of the configuration for package Package for Pharo
>>> 1.0 uploaded to MetacelloRepository:
>>>
>>> ConfigurationOfPackage>>baseline01
>>> "initial baseline"
>>>
>>> ConfigurationOfPackage>>version01: spec
>>> <version: '0.1'>
>>>
>>> spec for: #common do: [
>>>   spec blessing: #release.
>>>   spec worksIn: 'Pharo1.0'
>>>   ... ].
>>>
>>> 2. A new version for Pharo 1.0 (lets say a bug fix):
>>>
>>> ConfigurationOfPackage>>version02: spec
>>> <version: '0.2'>
>>>
>>> spec for: #common do: [
>>>   spec blessing: #release.
>>>   spec worksIn: 'Pharo1.0'
>>>   ... ].
>>>
>>> 3. A new Pharo release is made, no changes to the package are needed,
>>> that is, it works correctly in Pharo1.0 and Pharo 1.1
>>>
>>> ConfigurationOfPackage>>version03: spec
>>> <version: '0.3'>
>>>
>>> spec for: #common do: [
>>>   spec blessing: #release.
>>>   spec worksIn: #( 'Pharo1.0' 'Pharo1.1' )
>>>   ... ].
>>>
>>> At this point the ConfigurationOfPackage has four methods: baseline and
>>> three versions. Also, before loading, Metacello checks the worksIn:
>>> list against a standard release string in the image is working on. If
>>> it match it install the package. That is, if I start with a Pharo1.1
>>> image and load the configuration, the only possible candidate version
>>> to install is the 0.3, because is the only one marked to work in Pharo1.1.
>>>
>>> 4. A port to Squeak 5 is made. This likely will need a new baseline
>>> because will need squeak specific packages to be included
>>> (compatibility packages) and also maybe a Pharo compatibility package
>>> will be made. Anyway, a new baseline indicating new packages
>>> relationships will be made:
>>>
>>> ConfigurationOfPackage>>baseline02
>>> "second baseline, it accounts for install in Pharo and Squeak"
>>>
>>> ConfigurationOfPackage>>version04: spec
>>> <version: '0.4'>
>>>
>>> spec for: #common do: [
>>>   spec blessing: #release.
>>>   spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' )
>>>   ... ].
>>> spec for: #squeak do: [
>>>   ... ].
>>> spec for: #pharo do: [
>>>   ... ].
>>>
>>> At this point the ConfigurationOfXXX is capable of install the last
>>> version in Squeak and Pharo.
>>>
>>> If I start on Squeak 4.0 then even if I load the
>>> ConfigurationOfPackage, no package will be installed because nobody has tested this.
>>>
>>> If I start on Squeak 5.0 only version 0.4 can be installed.
>>>
>>> If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed
>>>
>>> If I start on Pharo 1.3 no package will be installed
>>>
>>> 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases
>>> but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1
>>>
>>> ConfigurationOfPackage>>baseline08
>>> "second baseline, it accounts for install in Pharo and Squeak"
>>>
>>> ConfigurationOfPackage>>version09: spec
>>> <version: '0.9'>
>>>
>>> spec for: #common do: [
>>>   spec blessing: #release.
>>>   spec worksIn: #( 'Pharo1.3' 'Pharo1.4' )
>>>   ... ].
>>> spec for: #pharo do: [
>>>   ... ].
>>>
>>> 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0:
>>>
>>> ConfigurationOfPackage>>baseline04
>>> "third baseline, it accounts for install in Pharo and Squeak"
>>>
>>> ConfigurationOfPackage>>version10: spec
>>> <version: '1.0'>
>>>
>>> spec for: #common do: [
>>>   spec blessing: #release.
>>>   spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' )
>>>   ... ].
>>> spec for: #squeak do: [
>>>   ... ].
>>> spec for: #pharo do: [
>>>   ... ].
>>>
>>> So the tags come and go as the support for given forks and releases are
>>> tested.
>>> Different versions of the Package package can work in different forks
>>> and in different releases of those forks.
>>> It is always the job of the interested parties to add support (that is
>>> version methods and baselines, or simply tags to the worksIn: list) for
>>> a package in a given combination.
>>>
>>> What do you think?
>>>
>>> Cheers
>>>
>>> --
>>> Miguel Cobá
>>> http://miguel.leugim.com.mx
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>:
>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.
>
> 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 <[hidden email]>:
>>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> On Tue, May 18, 2010 at 10:59 AM, Tudor Girba  
> <[hidden email]> 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 <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi,
>
> Well, the whole point of the "publish" idea would be to ensure a safe and guarded place from which everything can be loaded.
>
> If you depend on other repositories, these can disappear in time and you are back to the same problem as now.
>
> So, I think the only way around this problem is to produce configurations that can load only from a controlled repository.
>
> Cheers,
> Doru
>
>
>
> On 18 May 2010, at 12:03, Mariano Martinez Peck wrote:
>
>>
>>
>> On Tue, May 18, 2010 at 10:59 AM, Tudor Girba <[hidden email]> 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 <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow."
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> www.tudorgirba.com
>
> "Be rather willing to give than demanding to get."
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Yes, I don't think that it is a good idea to modify the configuration when it is published in the PharoXXMetacelloRepository.
>
> In the end the reason for this discussion revolves around the desire to provide a simple method for developers/users to load projects that are "known/tested to work in PharoXX".
>
> Creating a PharoXXMetacelloRepository means that we have a "white list" of configurations that are"known/tested to work in PharoXX".
>
> GoferProjectLoader provides  an API for loading projects from a target repository. The API makes it very simple to load a particular project by name, without having to specify more details about the version of groups involved. It also means that one can arrange to do special things under the cover of the GoferProjectLoader, like point to a different repository based upon the version of Pharo that it is running in ...
>
> I think that what we need in addition to a "white list" of projects, a "white list" of  _versions_ that are "known/tested to work in PharoXX."
>
> I think it would be straightforward to subclass/extend the GoferProjectLoader to add the notion of a version/group "white list"  that records the exact configuration/version/group(s) that have been tested and known to work. This same extension to GoferProjectLoader can automatically include an overrideRepositories: to ensure that all projects/packages are loaded from the PharoXXMetacelloRepository repository...
>
> By default, the GoferProjectLoader loaded into PharoXX would point to PharoXXMetacelloRepository and use the "white list" of versions.
>
> Once a developer/user has become comfortable using PharoXX, he/she can configure GoferProjectLoader to suit his/her needs as well as directly load Configurations/versions that are not on the "white list" (using Metacello directly) without requiring any changes to the configurations or where they originated from...
>
> So in the end the following expression will do things differently depending upon a) which version of Pharo it is executed in and b) whether or not you are using the 'default' GoferProjectLoader:
>
>   Gofer project load: 'SqueakDBX'.
>
> All while using the same Configuration...
>
> Dale
>
> Stéphane Ducasse wrote:
>> Yes I think that this is what dale proposed.
>> Dale is off line today but he will probably comment
>> Stef
>>
>> On May 18, 2010, at 10:59 AM, Tudor Girba 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.
>>>
>>> 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
>>>>> <[hidden email]>
>>>>> :
>>>>>        
>>>>>
>>>>>> 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
>>>>>>
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>>
>>>>>>          
>>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>>
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>>        
>>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>>
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>      
>>>>
>>> --
>>>
>>> www.tudorgirba.com
>>>
>>>
>>> "Every thing has its own flow."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>>
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>    
>>>
>>
>>  
>>
>