Preliminary Agenda for August 5th, 2009

Comments are appreciated.  Some topics we hope to consider at our next meeting include:

Development Progress

Relicensing Progress

The technical responsibilities of the Board

Squeak Swiki upgrade/replacement

Meeting Report for 7/15/2009

Attendance was nearly complete this week with Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, and Igor Stasenko present.  Randal Schwartz was in transit and is currently busy busy busy.

The main topic was of course the progress of the New Community Development Model and the discussions in the last two weeks about it and related topics.  We spent a lot of time reviewing and discussing the concepts in an attempt to better understand.  I think that we did improve our understanding a little bit but see no further action that should be taken at this time.  The best choice seems to be to continue to take little steps and see where things go.

We will meet again on August 5th, 2009.

The Pillars of Squeak

Disclaimer: These are my own thoughts, posted here for visibility. They have not been discussed with, or endorsed by, the Squeak Oversight Board.

I’ve been trying to come up with a starting point for a strategy discussion to help our community understand better what we are and what we want to do in the future. In thinking through the various aspects (there is nothing like sitting on a porch in North Carolina on a warm summer evening to do that 😉 it occurred to me that Squeak is really built around three fundamental pillars:

• Minimalism.
• Tools.
• Education.

Minimalism. I think we all agree that we love minimalistic, simple kernels and systems. I don’t think any of us would disagree with that. Whether it’s an embedded system, a little kernel image, or some self-contained bootstrap magic; we just all love and cherish self-contained little systems.

Tools. It’s what we use daily and it’s one of the things that we’re most proud of. The effectiveness of our tools, the speed with which they allow us to do almost magical things, the ability to simulate even complex interactions are all parts of the environment that I don’t think anyone would give up on.

Education. Smalltalk started as a system simple enough that a single person could understand and making a system that way means building it in an accessible form and that is squarely part of education. Some of us are also interested in educating children using Squeak but I think that we *all* want the system to be easy to learn from and easy to access.

In addition to these fundamental pillars of Squeak I see three more areas that are of very wide interest but not universally shared:

• Media.
• Internet.
• Business.

Media. The media aspects of Squeak are certainly unique. There is no other Smalltalk system that comes even close and for me, the media aspects were always the most interesting. Having the ability to have vector graphics, 3d, sound synthesis, mixing, video, scripting running bit-identical over such a variety of platforms is what makes projects like Plopp, or Etoys, or even Croquet and Qwaq Forums possible.

Internet. This is the Internet age after all, and much of what we do centers around it. Projects like Seaside or Aida are central for much of newly generated interest, entire companies are built around the abilities of Squeak on the ‘net.

Business. Last, but not least, business uses. There is a lot of interest in business use of Squeak which I think we have never very carefully catered too, but the interest (mostly in the form of complaints 😉 is certainly there. Since that’s literally where the money is I think it’s worthwhile to take it into account carefully.

Since this is supposed to the the starting point for a strategy discussion, what do people think about the above areas of interest? I’m in particular interested in whether you think you could identify with the three pillars of Squeak since if we can agree on those as the most important values that we *all* share, it seems that there are obvious practical consequences that we can draw from it.

I think that formulating and agreeing on our values as a community is a central part of setting our own direction. It gives us something to look back to when we don’t know what to do next, it gives us something to agree on when we disagree.

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.

Preliminary Agenda for 7/15/2009

First let me state that we are paying attention to your comments and we do appreciate them but it’s amazing how quickly one hour disappears and there is only so much that can be fit into a single meeting.  Triage is required.

Development Model Progress

Relicensing Release Progress

I’m sure more will be added, feel free to offer your own suggestions.

Meeting Report for 7/1/2009

Attendance was complete and timely this time around: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta,  Andreas Raab, Randal Schwartz, and Igor Stasenko.

We discussed the progress of the relicensing release.  Currently Matthew Fulmer is gathering information in preparation to meet with a representative of the Software Freedom Consortium to plan the next steps toward the completion of the 4.0 relicensing release.

Members of the Squeak Oversight Board have been kindly asked again to appear on Industry Misinterpretations.  Details are still being worked out but expect this episode sometime in September.

The primary topic was Andreas Raab’s proposed development model.  Discussion of this can be found here and here.  There was considerable discussion and even a little debate but ultimately the decision was to support Andreas’ proposal.  Expect Andreas to announce this in more detail soon.

Our next meeting is scheduled for Wednesday, July 15th, 2009.