About MC for managing the image

[stéphane ducasse]

I like your suggestions
definitively the way to go.

Stef

On 18 sept. 05, at 20:57, Daniel Vainsencher wrote:

> stéphane ducasse wrote:
>
>> So if I understand correctly this means that to arrive to version  
>> x,  we have to load all the configs (hence the MC
>> deltas to speed up the process) until we load version x.
>>
> This is important in order to be able to do changes that require  
> specific intermediate steps, exactly like what is planned for the  
> entry of Traits into 3.9a.
>
>
>> I guess that  this is the set up done at impara to manage iSqueak
>> and Tweak. Bert is it correct?
>> Now this means that this is really tedious to have to
>>     - define
>>     - validate
>>     - a load order for all the packages
>>     - publish a new cs on the update stream
>>     - publish a new image
>> The implications with this setup is that we have to produce often  
>> an  image (validate a configuration
>> of changes working together) and this can be quite painful. At  
>> least  they are a lot of try and error
>> when there are a lot of dependencies between packages.
>>
> About creating the cs and new image - this should probably be  
> automated. Something like
> "write cs describing current image, get the last published image,  
> load updates, save new image to web space".
> I don't understand why the load order is necessary and what trial  
> and error comes out of that.
>
> But maybe Avi's response solves that part of the problem.
>
> A couple of notes and proposals of my own -
> 1. I think one way to make you lives easier is to try to use only  
> MC as much as possible. Tell people you accept only mcz/mcd files,  
> for the existing packages. This will take time, but it will mean  
> that people will think about their changes and what they affect,  
> and its one less thing for you to figure out. If you get a CS, do  
> you go over it manually and check that methods are marked as  
> extensions where needed? if you require package versions, people  
> are likelier to think of that themselves.
> 2. Use proper repositories, not Mantis. Mantis can contain a link  
> to an mcz file in a repository, that is as easy for you to use as  
> an attachment. But it helps accountability, because then anyone can  
> get the original submitted version and inspect it. So tell people  
> to put their versions up on source.squeakfoundation.org/inbox or to  
> create themselves an account a personal project there, and then put  
> up all their proposed changes as mcz files.
> 3. Tell everyone that care about maintaining the image to register  
> for the sources.squeakfoundation.org RSS feed (I just found out  
> about this). That way they get notified for every version that gets  
> put out. That way people see what changes are proposed, and there's  
> a better chance that good changes will be endorsed/extended, and  
> bad changes will be seen and commented on. This is now the  
> equivalent of reading the BFAV, except you can do it from Thunderbird.
>
> This policy direction of moving towards using MC and SqS more  
> exclusively for the management of the image are good because:
> 1. The current hybrid policy is too complex (as seen for example by  
> the confusion caused by looking in changesets for traceability)
> 2. We can improve the MC tools to improve the image maintenance  
> process.
>
> For example, we can make one repository inspector that shows  
> quickly all the new versions of everything that people suggest, and  
> then harvesting will become easier in that way too.
>
> Daniel
>