yes I see.
We will check that. The problem is when we do not have tests.

On May 11, 2010, at 9:10 PM, Dale Henrichs wrote:

> Stef,
> 
> If you can automate the "acceptance test" for moving a config into the 
> Pharo1.0 Metacello repository then I think things can work smoothly.
> 
> I manually qualify configs for inclusion in the GLASS Metacello Repository, 
> but that doesn't scale well.... For GLASS I'm mainly interested in a very 
> small subset of the configs that I'm already involved with, so it isn't that 
> difficult to manage manually...
> 
> Dale
> ----- "Stéphane Ducasse" <[email protected]> wrote:
> 
> | On May 10, 2010, at 8:14 PM, Dale Henrichs wrote:
> | 
> | > Stef,
> | > 
> | > Just thinking off the top of my head a bit.
> | > 
> | >     Conceptually a separate repository makes sense ... then Gofer
> | Project could be
> | >     setup to to use this repository by default and the standard
> | instructions for 
> | >     loading things would be reduced to simple expressions like:
> | > 
> | >       Gofer project load: 'FFI'.
> | >       Gofer project load: 'Magma'. 
> | > 
> | >     The difficulty comes in keeping the repository
> | up-to-date....First you'd need
> | >     to qualify configurations for inclusion (a hudson server for
> | validation) makes
> | >     sense. For hudson, it would be nice if there were a list of
> | candidate 
> | >     configuration/version pairs that would be tested against ...
> | 
> | tomorrow we will sit with lukas and marcus to see how we can setup an
> | hudson server
> | on pur server. 
> | 
> | >     In reality we are really looking for an approved list of
> | configuration/version 
> | >     pairs that are known to work in Pharo 1.0. So we're probably
> | really interested
> | >     in expressions like the following:
> | > 
> | >       Gofer project load: 'FFI' version: '1.2'.
> | >       Gofer project load: 'Magma' version: '1.0r44'. 
> | > 
> | >     At this point a separate repository becomes a little less useful
> | ... it's not
> | >     the Configuration alone that the end user is interested in as
> | the version is
> | >     very important and the important information is that it is
> | "known to work"
> | 
> | 
> | For me I thought that we separate repository so that we can have
> | distributions. 
> | 
> | >     This leads me to think along the lines of 
> | > 
> | >       - configs from MetacelloRepository
> | >       - hudson server validating each version for each config
> | >       - list of config/(latest passing version) pairs published
> | > 
> | >     It would seem to me that a relatively simple morphic/glamour
> | window could be 
> | >     written that read the config/version pairs from the hudson
> | server and 
> | >     provided a means for selecting/loading the config/version
> | pairs.
> | > 
> | > How does this sound?
> | 
> | I do not know because I do not foresee the use well.
> | 
> |     Gofer for: #Pharo1.0.
> |     Gofer project load: 'FFI'
> | 
> |             looks simple to me.             
> |     Then if I want to load a specific version
> |     Gofer project defaultVersionFor: 'FFI'
> |                     '1.2'
> |     Gofer project load: 'FFI' version: '1.1' if I need the one before 1.2
> | if it makes sense. 
> | 
> | Stef
> |     
> | 
> | 
> | > 
> | > Dale
> | > 
> | > ----- "Stéphane Ducasse" <[email protected]> wrote:
> | > 
> | > | Hi Dale and others
> | > | 
> | > | I would like to have a 
> | > |         Pharo1.0 folder in the MetacelloRepository and ideally all the
> | > | configurationOf... inside should work for Pharo 1.0.
> | > | How can we proceed to get that. 
> | > | In the future we should also have a process to avoid that we get
> | junk
> | > | inside. any idea (I was thinking about an hudson
> | > | server that would validate the configuration automatically)
> | > | 
> | > | Stef


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to