Author Archive

Meeting Report for 9/15/2010

September 21, 2010

With ESUG going on (Bert’s Squeak presentation was yesterday), we had a fairly short and quiet meeting today. Andreas, Craig Chris, Jecel and Randal were present, we started our discussion trying to find a better spot for our regular meetings as several of us had problems with the Wednesday spot. It looks like we’ve settled on the first and third Tuesday each month (starting next week) at 8am pacific. We continued the discussion of the transfer of outstanding funds to the SFC but haven’t made much progress yet. Lastly, we discussed the current state of integration of Cog and will be trying to push the integration forward a little more to see if we can help merging the main VMMaker and the Cog branch relatively soon. And that was about it.

Advertisements

Meeting Report for 7/21/2010

July 21, 2010

In case you haven’t noticed, it’s summer! People are on vacation and consequently Craig (on vacation in Europe) wasn’t present in our meeting and Bert joined us from his hotel room and shared a view of the beach with us.

There wasn’t too much to talk about. We discussed a bit the SFC status and noted that we need to make some progress with the reconciliation of our finances. We’re still waiting for some info from the SFC on how to best address this issue and will ping them again as a reminder. Andreas brought up the issue of providing a Squeak image with Seaside preloaded and the board agrees that we should provide such an image on http://ftp.squeak.org/various_images/seaside.

We raised a couple of other issues in the discussion, including what a useful scope for 4.2 might be, how to make progress with community supported packages, and how to continue the discussion about documentation, but no specific action items resulted from these.

As a result we finished our meeting early. But hey, it’s summer!

Squeak joins the Software Freedom Conservancy

July 1, 2010

The Squeak Oversight Board is excited to announce that Squeak is now a member of the Software Freedom Conservancy. The Software Freedom Conservancy is an organization composed of Free and Open Source Software (FOSS) projects. As a fiscal sponsor for FOSS projects, the Conservancy provides member projects with free financial and administrative services, but does not involve itself with technological and artistic decisions.

By joining the Conservancy, Squeak obtains the benefits of a formal legal structure while keeping focused on software development. The benefits of joining the Conservancy include, most notably, the ability to collect donations and protection from personal liability for the developers of the project. Another benefit of joining the Conservancy is we can use it to hold assets, which are managed by the Conservancy on behalf of and at the direction of the Squeak Oversight Board. The Conservancy is a tax-exempt 501(c)(3) organization, so member projects can receive tax-deductible donations to the extent allowed by law.

Squeak 4.1 released

April 18, 2010

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.

Meeting Report for 4/7/2010

April 9, 2010

As usual these days, everyone was present in the meeting (Andreas, Bert, Chris, Craig, Jecel, Juan, Randal) with Juan being a little late due to unforeseen events and a bit of bad luck.

The meeting started with Chris asking for the board to clarify its position with regards to Pharo compatibility issues. The board agrees that compatibility is both a concern as well as desirable and that we should do what we can to avoid superficial incompatibilities. Bert pointed out that we have some control over it by adding changes done in Pharo for compatibility in Squeak.

We then discussed the current status of joining the SFC. Bradley had replied to Jecel’s note and congratulated us on the release and the new board. Unfortunately, the message got apparently stuck in the spam filters so most of us hadn’t seen it before the meeting. Our next step is to get the latest draft from the SFC, review it and then execute it. There was no progress on consolidating the financial situation since it depends on the SFC membership.

We then discussed our options and Ken’s comments regarding the board list rejection policy. After some discussion we agreed that the desirable solution is to have some sort of recaptcha for verification to contact the board but since nobody was signing up for implementing it we decided it is worthwhile to go with a low-tech solution instead and have all members of Squeak-dev be whitelisted. That way, at least all the known members of our community have a way of contacting the board directly. We have contacted Ken regarding this idea and he’s investigating the options.

We spent a good amount of time discussing the situation of external packages in Squeak. We agree that the current situation is undesirable and that hopefully something can be done about this in the 4.2 time frame but what exactly that means is unclear at this point. Some ideas have been voiced that need to be discussed more widely (i.e., on Squeak-dev).

Lastly, Bert and Andreas agreed that they’re going to blow up some crazy fireworks on July 4th.

The Pillars of Squeak

July 6, 2009

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

July 2, 2009

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.

Initial Agenda for May, 7th 2009

April 22, 2009

One of the changes agreed on during the last meeting was to post a prospective agenda sooner rather than later to give others a way of influencing the agenda more directly. As a consequence the initial agenda for the next meeting only includes our “standard” agenda items:

1. Project Updates
2. Licensing Status
3. Mission Statement
4. Teams Updates
5. Process improvements

Please add more items to the list!

Agenda for April 2nd 2009

April 1, 2009

Here is the proposed agenda for our next meeting:

1.  Project updates.

2.  Outreach: Who represents the board for a podcast with James Robertson?

3. Teams, continued

4. Mission Statement for 2009

5. New Tasks for this year:

  • Positioning towards other communities
  • Process improvements (BPPs, decision making etc)

Agenda for March 26th 2009

March 25, 2009

Here is our agenda for the next meeting. It is basically the left-overs from last time as well as teams discussion:

1. Status updates for activities carried over from last year:
* Status of Incorporation
* Status of 3.11
* Status of 4.0 / relicensing

2. Team status, per http://www.squeak.org/Community/Teams/
* Keep the name ‘Oversight Board’?
* Give a detailed information about teams on Teams page?
* Team Leaders

3. New tasks for this year:
* Mission statement for 2009 (aka: Where is Squeak headed)
* Positioning towards other communities
* Process improvements (BPPs, decision making etc)

I’m not sure we’ll get to step 3 but since we’re still in the process of working through the issues from last year it feels appropriate to do move the team update to the top of the queue.