could we start to organize MetacelloRepository?

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

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

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

>
> Dale
>
> ----- "Stéphane Ducasse" <[hidden email]> 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

> 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" <[hidden email]> 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" <[hidden email]> 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