7/15/2013 — Meeting Minutes

Squeak board minutes 15 July 2013

present: Eliot Miranda, Chris Muller, Frank Shearar, Tim Rowledge

The annual summertime quiet-period has struck again.

4.5 is planned for release Q4/2013.  This is a rich release with the Environments feature and significant package factorings.

Colin is in process of moving to another hemisphere, so he may not be able to respond immediately to questions about Environments.

Meanwhile, Frank continues modularisation of the image.

Eliot is back from vacation and just released new Cog VM’s.

Eliot and Craig had met at one point to discuss integration of Spoon VM changes into Cog.  Additional work is needed.

6/3/2013 — Meeting Minutes

Squeak board minutes 3 June 2013

present: Bert Freudenberg, Eliot Miranda, Chris Muller, Colin Putney, Tim Rowledge

– We had a discussion about the Swiki.  We would like to have a rich and useful wiki for the community, but there is no way around having to do some work to achieve that.  Thankfully there appear to be some easy opportunities for cleaning.  A plan was discussed:

   1) get access to the swiki image so the code and features can be improved.

   2) is the Swiki software installable and testable on 4.5?

   3) some easy cleanups seem obvious:  remove empty & clearly obsolete pages.

   4) develop guidelines about what content is needed.

   5) ask other folks to help review and clean per guidelines.

– There was a discussion about the vision and future of Squeak.  Squeak evolves naturally by the participation of community members pushing their desired features into the image.  To the extent they are acceptable to the rest of the community ensures a sufficient element of stability that allows the community to remain up-to-date and cohesive.  Meanwhile the platform continually becomes a better and better Squeak.

– Some improvements come from individuals and some are purposefully discussed and acted on as a community.  Members of the board have some ideas about this and also invite others to open discussions about this on the mailing list.  As an example, there was a recent discussion about graphical backends to support anti-aliased output.

Meeting Report for January 18th, 2011

Bert, Chris, Craig, Jecel, Juan and Randal were present at this week’s Squeak board meeting.

Jecel was experiencing network-bandwidth issues for part of the meeting, and so Skype-chat was suggested as a backup alternative for future board meetings.

4.2 is still scheduled for release sometime during the week of January 31st, 2011. Then, the trunk will be reopened for new features again.

It will soon be time for the annual Squeak board election. Bert suggested we manually create a definitive list of the registered voters for the 2011 election. Randal is taking that up.

The SqueakMap server package in the source repository is not the code currently being run by the production SqueakMap server. Chris is fixing that issue.

Squeak 4.1 released

Squeak 4.1 has just been released. From the release announcement:

Squeak 4.1 combines the license change occurring in the 4.0 release with the development work that has been going on while the relicensing process took place.

Much of the work in this release has been focused on fundamental improvements. Major achievements are the integration of Cog’s closure implementation, the improved UI look and feel, the new anti-aliased fonts, the core library improvements, and the modularity advances.

To download the Squeak 4.1 release please visit:

http://ftp.squeak.org/4.1

The Website will be updated over the next few days to reflect the availability of Squeak 4.1.

Squeak 4.0 released

The Squeak project announced today the public release of Squeak 4.0. This release completes the multi-year effort to relicense Squeak under FOSS licenses.

Squeak 4.0 is functionally equivalent to the previous Squeak 3.10.2 release but licensed under the MIT license with some original parts remaining under the Apache license.

Current development work will be released as 4.1 as soon as possible following the release of 4.0.

A New Community Development Model

Edit: Updated 11/4/2009 regarding Unit Testing.

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.

License

In accordance with our goal of joining the Free Software Conservancy, all code submitted to the repositories must be licensed under the MIT license.

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”

* Unit Testing. Unit tests are an essential part of maintaining the reliability of our releases. New units tests are always welcome. Keep in mind that a unit test should take as little time to run as possible.  Maintaining the reliability of Squeak is always easier when the tests are all green: if you break something the appearance of a new failure or error is immediately obvious and the cause is more easily found. To that end fixes for failures or errors are extremely valuable and please avoid submitting changes that cause new failures or errors.

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. We are evaluating alternative approaches, in particular the use of Installer since there are some shortcomings when using Monticello Configurations.

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.