Archive for the ‘Community’ Category

2010 Election Announced

February 17, 2010

The current Election Team Leader, Göran Krampe, has announced the plan and schedule for the election of the 2010 Squeak Oversight Board.  Please read it and be prepared.

Advertisements

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.

garbage collecting the Wiki

June 13, 2009

The wiki is a fantastic resource for the community. Any search involving “squeak” will certainly have a link to a wiki page among the top results. And when answering questions on IRC, I nearly always end up pointing out some wiki page as the source for additional information.

Unfortunately, a significant portion of the information available there is obsolete. It is very easy for less experienced Squeakers to waste a lot of their time following advice they found on some page without realizing that it no longer applied to any Squeak newer than 2.5! One way to solve this is for a team to scan the wiki looking for stuff like this and then updating the information. In practice this is simply too much work and is unlikely to happen in a larger scale than what has been done so far. An alternative, inspired on garbage collection algorithms like those implemented in the Squeak VM, is to start a new wiki and move only current information there. This might seem like even more work, but it can be done incrementally: any person searching for information and not finding it in the new wiki can copy it from the old one.

If access to the old wiki remains as it is now, nobody would have any incentive to copy information to the new one. The most radical solution would be to simply eliminate normal access to the old wiki – you would have to explicitly log on to it or something like that. This would quickly make it vanish from the search engines. At the other extreme, it would be simple to add a warning to all old wiki pages saying that the content is obsolete. That could be done with the “message of the day” mechanism (lately it has been broken and only showing one quote from me anyway). This is too easy to ignore, however. A slightly more complicated solution would be to patch the swiki code to show a warning that would be far harder to ignore. It might be interesting to include a link to the new wiki for any page which has content that has been moved there. One way to encourage moving content to the new wiki would be to disable editing of the old one (except for adding links to the new).

The goal is to eventually have a new wiki, possibly based on some more modern Squeak technology, that document the system as it is now. The best way to achieve this would be for the board to issue a request for proposals so that people interested could form a team to create the new wiki and patch the old one. This team would not be responsible for the content, except moving a few key pages themselves to get the process started. The details that I have mentioned above are only examples – the candidates would be free to suggest any solution they want as part of their proposals.

Personally, I am very interested in Squeak’s history and would not like to see the old information vanish entirely from the web. But I do agree that as things are now the noise is getting in the way of the signal and we need to cause a better first impression to people interested in Squeak and Squeak based projects.

Mission Statement Published

June 4, 2009

Well it took a while but we have finally published a ‘Mission Statement’ for ourselves and it can be found listed on the right.  Please let us know what you think.

The voice of community about future of Squeak

March 26, 2009

Here the list of ideas i collected, when asked people to speak what
they want to see in Squeak.

by Aik-Siong Koh

Make Squeak callable by other programs. Make Squeak well behaved in plugin or addon environments. It would be so much easier to make Squeak financially viable by selling small plugins or addons, rather than complete applications. I see this in the areas of 2D and 3D CAD. Squeak cannot possibly win on looks, so let it do great work hidden.

by Edgar

I think of Board (not like the word Leadership) as members who have a record of enough Squeak presence. People trusting us want a better Squeak , right  ?
What do not seems enough clear is how we help to a better Squeak.
In the present Board we have differents ideas about this.

For me, a better Squeak is a modular one which could grow from a tiny
kernel to a any major fork or any user own image.

I saying this for years and tryng to do.

(By member who wanted to stay anonymous)

I know the leadership team has already been working on this, but just so they know at least part of the community is still interested, it’s
important to me that we form an official non-profit.  This would make
donations tax-deductible, at least for me here in the US, which in turn
opens up a lot of opportunities for people and corporations to give
money, which in turn opens up a lot of opportunities for improving
Squeak, advocating Squeak, et cetera.

Now that re-licensing is coming to a close (yay!), I think this is the
most important thing the board can do for the community.

by Mark Volkmann

1) Make it as easy to run a Squeak application from a command prompt or terminal window as GNU Smalltalk.
2) Add support for native threads and utilizing multiple cores/processors.
3) Either put significant effort into a replacement for Morphic or
document Morphic much better. I’ve pretty much given up figuring out
even basic things like discovering all the out-of-the-box widgets and
learning the best ways to lay them out in containers.
4) Make Squeak a happier place with much less fighting between subgroups.
by Klaus D. Witzel

A simple+powerful GUI designer which runs accross multiple Squeak
releases (and does not depend on other packages).

It should provide concepts+vocabulary from HTML+DOM+CSS+bindings so that even noobs feel comfortable and don’t immediately run away as soon as they confront morphic.

And in the tradition of Smalltalk, the morphic implementation details
have to be “encapsulated away”, leaving it to experts to squeeze the
maximum out of morphic.