How to do things in an MC update stream world

stéphane ducasse ducasse at iam.unibe.ch
Fri Sep 23 09:57:09 UTC 2005


On 23 sept. 05, at 03:43, Daniel Vainsencher wrote:

> Hi all. We've been discussing on the packages list how to make life  
> easier on harvesters and everyone else that cares about what goes  
> on in the alpha, development stages.
>
> Here are some things that you might consider. I am not stating  
> agreed policy, just a proposal for such.
>
> 1. Use MC as much as possible. IOW, try not to submit cs files.  
> The .mcz files should correspond to the packages in the image - do  
> not create new packages if you're trying to fix several methods in  
> different packages. Just create a new version of each of the  
> affected packages. Write a small paragraph describing what versions  
> of what packages are related and how, and copy-paste this into all  
> the versions you're submitting. Submit all your versions together  
> into the submissions project of source.sqf.org when you feel  
> they're ready for possible inclusion. The reason to use mcz files,  
> though it might be easier for you to use cs files, is that mcz  
> files give harvesters more tools to work with. For example, CS  
> files can get stale (include old versions of code that has since  
> been updated), and cause hard to detect collisions, which are  
> automatically detected by MC.

but daniel
I would prefer to have a top packages which indicated which one of  
the package work together
example
     MyFixe
         required
             Morphic-sd.35
             Network-sd-67

Else this will be the hell for us.

>
> 2. Use proper repositories (such as the one mentioned above), 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 having the  
> actual file in a public repository helps accountability, because  
> then anyone can easily get the original submitted version and  
> inspect it. If you think a change is not ready for the submissions  
> project, create your own personal project on source.sqf.org and use  
> that.
>
> 3. Register for the sources.squeakfoundation.org RSS feed (I just  
> found out about this). This way you get notified about every  
> version that gets proposed or accepted. This allows you to be  
> active in reviewing other peoples stuff, to see when your proposed  
> changes get accepted, and generally know what's going on. This is  
> now the equivalent of reading the BFAV, except you can do it from  
> your friendly RSS client, without any special installation beyond  
> subscribing to the feed. BTW, the squeaksource.com feed is also  
> interesting.
>
> Daniel Vainsencher
>
>




More information about the Squeak-dev mailing list