Re: 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