source.squeakfoundation.org (was Re: iSqueak)

[Doug Way]

For what it's worth, I think the process Bert describes below sounds OK
for 3.9alpha for now... the "update stream/config map hybrid".  Do you
agree Avi?  We could tweak this as we go along.

Also, keep in mind that once in a while, if we have a stable set of
alpha packages, those could also be published to SqueakMap for the world
at large to play around with.  (Maybe on those occasions we would also
save an MC config map, I don't know.)

- Doug


On Sun, 26 Jun 2005 15:47:53 +0200, "Bert Freudenberg" <bert at impara.de>
said:
> 
> Am 26.06.2005 um 13:22 schrieb Avi Bryant:
> 
> > On 6/26/05, Bert Freudenberg <bert at impara.de> wrote:
> >
> >
> >> Please have a look at
> >>
> >>      http://tweak.impara.de/ABOUT/FAQ/MCConfigurationUpdates/
> >>
> >> Then ask back with any questions :)
> >>
> >
> > My first question is about workflow: how often do you save a new
> > config map?
> 
> Actually, in the Tweak update scheme we do not "save" a config map at  
> all. When we post it to the update stream, it is not retained after  
> loading packages. It is just used as a list of packages that need to  
> be loaded.
> 
> Additionally, we have a global config map in the image, which is  
> updated automatically by using the highest-numbered version found in  
> the repository. This config map update is performed after updating  
> from the update stream.
> 
> > Do you only do it when you either add or reorder
> > packages, or need to post an intermediate update to the stream?
> 
> Yes, that's the current practice, because Tweak is still undergoing  
> heavy development.
> 
> > Or do
> > you save the config map for every stable configuration of versions
> > (whenever all tests are green or whatever)?  It seems to be intended
> > more for the former, particularly because the naming seems to be
> > totally manual, whereas with the current dependency system I tend
> > towards the latter.
> 
> True. We rely on the update-stream / config map hybrid, so previous  
> config maps are only found in the update stream, not as explicitly  
> versioned files.
> 
> > Do you tend to just have one version of the config map in the repo
> > that you overwrite when things change, or do you end up with a lot
> > with different names (which seems it would really clutter up the
> > repository browser)?
> 
> As I said, we do not create config map files at all right now, so  
> this part of the code is a bit underdeveloped. Our squeaksource  
> version supports uploading of config maps, but we do not use this  
> right now. When I experimented with this, I uploaded the updated  
> config map under the same name. Locally, I even explicitely forbid  
> caching of config map files because the name was not guaranteed to be  
> unique.
> 
> OTOH, config maps are a lot like MCVersions, so they would benefit  
> from the same naming scheme when they are stored in files. We might  
> want to implement something along these lines, or actually go and  
> merge versions and config maps into one (I imagine MCConfiguration  
> and MCVersion could share a common superclass handling dependencies  
> and naming, MCVersion would additionally have code, MCConfiguration  
> would have repository info ...).
> 
> - Bert -
>