First let me say that I like the proposal because I feel that  
contributing is much easier that way for me. I think the minimum amout  
of work to make a contribution seems smaller than with the old process.

I have a question though. If I press the Update button do I get all  
the newest versions of the packages automatically? Or only those for  
which an mcm-file was issued.

Thanks for your attention.
Bernhard

Am 02.07.2009 um 05:03 schrieb Andreas Raab:

> [This message is also available on the blog at
> http://squeakboard.wordpress.com/2009/07/02/a-new-community-development-model/ 
> ]
>
> In the board meeting today we had a nice discussion about how to  
> move forward with a new community development model for Squeak. Here  
> is an overview of the model and what will happen next:
>
> The goals
> ---------
>
> The goal of this process is to get rid of as many hurdles as  
> possible in the contribution process. We are trying to enable the  
> community at large to improve Squeak, the core of the system and its  
> supporting libraries.
>
> To do this, we are adopting processes that have been shown to work  
> in commercial settings: The use of Monticello as the primary source  
> code management system, free access for the developers to the main  
> repositories, an incremental update process for both developers and  
> users of Squeak.
>
> Repositories
> ------------
>
> We will be setting up the following Monticello repositories:
>
> * http://source.squeak.org/trunk
>
> This will be the main repository for ongoing development. New code  
> will be committed here, the repository will be world-readable and  
> writable for the core-dev group.
>
> * http://source.squeak.org/tests
>
> This is the main repository for unit tests. It will be world- 
> readable AND world-writable. We encourage everyone to write more  
> tests and commit them, improve the existing tests and bring in  
> entirely new test suites.
>
> * http://source.squeak.org/inbox
>
> This repository is intended as dropbox. It’s usage will depend on  
> what we make it out to be. The idea is to have it world-readable and  
> world-writable, too.
>
> Developer access
> ----------------
>
> The board will manage developer access to the repositories at  
> source.squeak.org. In the next days we’ll send out a few “you are  
> pre-approved” messages to people who have proven to be active  
> developers in the past in order to invite them to become a core  
> developer.
>
> If you can’t wait and absolutely want to be in on the action you can  
> register yourself at http://source.squeak.org/ and send message to  
> the board asking for access but most of the regular contributors  
> (you know who you are) will be invited anyway.
>
> Rules of Engagement
> -------------------
>
> If you have used Monticello in projects with more than two  
> developers in the past you already know the drill. If not, here are  
> some useful guidelines:
>
> * Merge often. In particular when you pick up work and right before  
> you intend to commit.
>
> * Exercise caution. This is a running system and breaking it  
> needlessly is generally frowned upon.
>
> * Restrain yourself. Getting developer access doesn’t mean you are  
> free to put in every pet extension you always wanted to have without  
> discussion.
>
> * If in doubt, ask. This is the corollary to the restrain yourself  
> rule. You’re not under pressure to ship a product, so you have the  
> time to send a note saying “hey, I’m planning to fix this old issue  
> and it may have some side effect here or there. Anyone having a  
> problem with that?”
>
> >>> I’ll add a Squeak-dev exception here: Any response from any non- 
> developer can be entirely ignored in this context.
>
> * You break it, you fix it. If you change something you are  
> generally expected to take care of the consequences, though there  
> are some exceptions. If in doubt, ask ;-)
>
> * Do good and talk about it. When you’re done with whatever it is  
> you’ve been working on let people know about it. It can be as short  
> as a note to Squeak-dev saying “hey, some of you might care that  
> I’ve fixed the long standing bug with xyz. Update and enjoy”
>
> I think that roughly covers it. Basically you will be working with a  
> dozen (hopefully more) other developers on Squeak and we’ll all have  
> to learn how to make this work successfully.
>
> Updating
> --------
> We are in the process of developing an update process that can work  
> seamlessly with Monticello. An early experiment is described  
> here[1]. We are evaluating alternative approaches, in particular the  
> use of Installer since there are some shortcomings when using  
> Monticello Configurations.
>
> [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/136870.html
>
> Existing Work
> -------------
> It is important to note that we will be trying very hard not to lose  
> any work that is being done for Squeak 3.11. We will start with the  
> package set that was used in the 3.10 release, then we will issue  
> package updates to cover the missing delta up until 3.10.2.  
> Following which we will reissue any changes done for 3.11 into the  
> repositories.
>