sound cool. Estenban we need more :) On May 19, 2010, at 2:45 AM, Dale Henrichs wrote:
> 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 >>>>> <[email protected]> >>>>> : >>>>> >>>>> >>>>>> 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 >>>>>> >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> -- >>> >>> www.tudorgirba.com >>> >>> >>> "Every thing has its own flow." >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> >> > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
