2009/2/14 Ken Causey ken@kencausey.com:

This is a perfect example of something I think the Leadership team should NOT have anything to do with. The Leadership team should concentrate on those issues where a single decision has to be made or a job should only be done once. For example joining the Software Freedom Conservancy can only be done once, there is no value in competition here.

On the other hand technical issues can be investigated and solved by anyone and competition, if any, only improves the situation for everyone. I'm certainly not opposed to the Leadership team smoothing the way somehow, but I currently see nothing it could do on this issue. I suppose it's conceivable that some day we might end up with two competing solutions and no easy way to decide. In that case it might be appropriate for the Leadership team to step in and arbitrate. But I find it extremely hard to believe that the community itself could not make a decision.

Let me be clear, if this is the sort of thing you expect the Leadership team to focus on, do not vote for me. Outside of the Leadership team I would contribute to a solution to this problem as I could and cheer right along with everyone else, but just as another developer and community member, not as a Leadership team member.

Ken

Ken, i will make a separate list of technical-related questions. Squeak is not only an idea, a philosophy, but a software environment which stays behind ideas and works. We weren't been here if this wasn't true.

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.

On Sat, 14 Feb 2009 23:10:18 +0100, Mark Volkmann wrote:

On Feb 13, 2009, at 9:18 PM, Igor Stasenko wrote:

...

Hello squeakers,

A year has been passed and we are now going to elect a new Leadership team (many of us is still calling it Board ;).

In the light of this event, i want to propose create a list of requests, issues and proposals which will be addressed to a newly elected team. Let us help them with understanding what is the most important issues we have, and to start not from own to-do list, but also consider YOUR thoughts.

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.

---

Mark Volkmann http://www.ociweb.com/mark

OK

How about setting up some standard or even informal mechanisms to help keep the several forks of Squeak in sync where appropriate?

Steve

On Tue, Feb 17, 2009 at 5:20 PM, Igor Stasenko siguctua@gmail.com wrote:

So far i've collected 5 messages.. Hey, wake up! We need more! :)

-- Best regards, Igor Stasenko AKA sig.

Igor Stasenko wrote:

So far i've collected 5 messages.. Hey, wake up! We need more! :)

You're right. After some careful consideration I've decided to throw my hat in the ring as well. Count me in.

I'm doing this with a clear agenda: I want to (re-)enable a process by which contributions flow into Squeak, both small and large. From my point of view somewhere along the way we've lost the ability to pick up contributions, to continually improve Squeak. Except from small bug fixes and enhancements there is no process by which we can decide whether a particular contribution should be included, whether a particular turn in the development of Squeak should be taken, whether a change is worth the risk that comes with it.

We are not a benevolent dictatorship. We will have to find other means of making such decisions. However, finding a way to make such decisions is absolutely critical if we want to progress. Right now there is a variety of improvements out there that nobody has looked at simply because there is no process for making decisions. Examples include Freetype rendering, Hydra, Rio, Nile, Gstreamer support, Polymorph, Omnibrowser, but also things like Databases (SqueakDBX, ODBC), or even Seaside, Aida etc. There are questions about minimalistic Morphic, FunSqueak, Etoys etc. All of these should be open for discussion, some of them will end up being external packages, others may end up being bundled (via Universes or similar mechanisms) and yet others may go straight into the release image.

All of the above exist. These aren't projects that someone will only start if given assurances about their outcome. Rather than making wish-lists about projects that nobody is working on, I'd like to see more requests for the integration of work that has been done already. This is the kind of stuff where the board can decide on, assign a liaison to ensure integration and get things done that way.

Similarly, Keith and Ken are building some fantastic tools for getting stuff out of Mantis. Why not build a network of trust for people who can add candidates to the next Squeak version which is rooted at the board? In other words, if you have been blessed by any of the board members, you could add your fix straight to the next alpha build.

The above are all examples of things we can try. I'm not saying any of those is the right solution but I am asking for a mandate in trying to establish a process that will allow us to continually improve Squeak.

Cheers, - Andreas

On 2/18/09 3:02 AM, "Andreas Raab" andreas.raab@gmx.de wrote:

Igor Stasenko wrote:

...

So far i've collected 5 messages.. Hey, wake up! We need more! :)

You're right. After some careful consideration I've decided to throw my hat in the ring as well. Count me in.

I'm doing this with a clear agenda: I want to (re-)enable a process by which contributions flow into Squeak, both small and large. From my point of view somewhere along the way we've lost the ability to pick up contributions, to continually improve Squeak. Except from small bug fixes and enhancements there is no process by which we can decide whether a particular contribution should be included, whether a particular turn in the development of Squeak should be taken, whether a change is worth the risk that comes with it.

We are not a benevolent dictatorship. We will have to find other means of making such decisions. However, finding a way to make such decisions is absolutely critical if we want to progress. Right now there is a variety of improvements out there that nobody has looked at simply because there is no process for making decisions. Examples include Freetype rendering, Hydra, Rio, Nile, Gstreamer support, Polymorph, Omnibrowser, but also things like Databases (SqueakDBX, ODBC), or even Seaside, Aida etc. There are questions about minimalistic Morphic, FunSqueak, Etoys etc. All of these should be open for discussion, some of them will end up being external packages, others may end up being bundled (via Universes or similar mechanisms) and yet others may go straight into the release image.

All of the above exist. These aren't projects that someone will only start if given assurances about their outcome. Rather than making wish-lists about projects that nobody is working on, I'd like to see more requests for the integration of work that has been done already. This is the kind of stuff where the board can decide on, assign a liaison to ensure integration and get things done that way.

Similarly, Keith and Ken are building some fantastic tools for getting stuff out of Mantis. Why not build a network of trust for people who can add candidates to the next Squeak version which is rooted at the board? In other words, if you have been blessed by any of the board members, you could add your fix straight to the next alpha build.

The above are all examples of things we can try. I'm not saying any of those is the right solution but I am asking for a mandate in trying to establish a process that will allow us to continually improve Squeak.

Cheers,

• Andreas

I can't add other as sharing all Andreas views.

And count me on the next race to Board. I having a awful 2009 start, full of unexpected troubles as my iMac PPC finally bite the dust.

But I still think Squeak is the only Open Source project deserving all my energy.

I plan to see some of my far away in colleagues in Brest this year, so take your turn to beat me :=)

Edgar

On Tue, Feb 17, 2009 at 09:02:09PM -0800, Andreas Raab wrote:

Igor Stasenko wrote:

...

So far i've collected 5 messages.. Hey, wake up! We need more! :)

You're right. After some careful consideration I've decided to throw my hat in the ring as well. Count me in.

I'm doing this with a clear agenda: I want to (re-)enable a process by which contributions flow into Squeak, both small and large.

Bravo. Thank you for deciding to run Andreas.

Dave

Andreas Raab wrote:

Igor Stasenko wrote:

...

So far i've collected 5 messages.. Hey, wake up! We need more! :)

You're right. After some careful consideration I've decided to throw my hat in the ring as well. Count me in.

I'm doing this with a clear agenda: I want to (re-)enable a process by which contributions flow into Squeak, both small and large.

This was exactly my vision too. As the developer of Rio, I could see no possible existing process by which Rio could be adopted into the mainstream, (Rio just being a representative example of a relatively significant but not huge change), I could list numerous other examples (Namespaces etc).

I expect that the process of introducing such a module needs to be planned. tried, experimented with some feedback gained. Pilot versions of squeak with the integration of the new feature might co-exist with the standard versions, until such a time as an effective transition can be planned.

This is possible with the current process, but only just. Firstly, the new module has to be completely ready, since the release team is only really supposed to be integrating. Secondly with the release team leader in the benevolent dictatorship role he, and only he has the ability to integrate the module in short incremental steps. Pulling out such a module at the 90% mark would probably be tricky. Such transitions are all or nothing, there is no waiting room, where a new idea can gestate and mature into place.

We lost the ability to say "we need this" and to plan for its development and evolution, instead we only have the option of using what is essentially complete, and then at the risk of upsetting/alienating those whose code breaks as a result.

From my point of view somewhere along the way we've lost the ability to pick up contributions, to continually improve Squeak. Except from small bug fixes and enhancements there is no process by which we can decide whether a particular contribution should be included, whether a particular turn in the development of Squeak should be taken, whether a change is worth the risk that comes with it. We are not a benevolent dictatorship. We will have to find other means of making such decisions. However, finding a way to make such decisions is absolutely critical if we want to progress. Right now there is a variety of improvements out there that nobody has looked at simply because there is no process for making decisions.

Agreed.

Our new framework has places to put new ideas, so if you wish to add the Nile api to an earlier version of squeak, then LevelPlayingField or Sake/Packages have a place you can do so. If you wish to remove a package from the kernel, then a Sake/Packages unload script can be developed. If you want to intergrate something new, then aim would be to define a task, "integrate Nile". This task can tested out now and be scheduled in as part of a planned future release, say 3.12.

The release team then applies the tasks to generate the build, but there is nothing stopping another variant image being generated from a similar set of tasks.

As I see this, this is a licence to fork. However if we empower people to fork and test their ideas within the same framework, where such innovations are visible, this promotes an overall meta-compatibility between the forks, through the exchange of ideas, and visibility.

For example, if I can see all the places where people are adding extensions to Collections, then I have the information I need to design a new streamlined Collections package that will suit everyone, with additional loadable non-core collections modules.

The hope is that the community will have the best of both worlds. The ability to try out new things, and the ability to share, exchange and update the best of the common stuff.

My sadness of the approach of the pharo project is the irony that at the exact same time we have been talking about a process that would facilitate new ideas, and different forks of squeak both existing and new. They choose to fork outside of that new proposed process, and carry on using the old, one perfect path philosophy.

Its like having discovered that the square pegs (banches of new innovation) don't fit through the round hole (the incremental, 2 person release team), lets go off and make a round peg (our one new streamlined branch of new innovation) which is compatibile with our hole (incremental, 2 person release team). At the very same time that those with the square peg (branches of new innovation) decide to adopt a square hole (a philosophy and framework for facilitating and embracing branches of new innovation).

All of the above exist. These aren't projects that someone will only start if given assurances about their outcome.

Right, and this was exactly my issue with Rio, from the outset the integration looked like it would never happen.

Similarly, Keith and Ken are building some fantastic tools for getting stuff out of Mantis. Why not build a network of trust for people who can add candidates to the next Squeak version which is rooted at the board? In other words, if you have been blessed by any of the board members, you could add your fix straight to the next alpha build.

yep, agreed.

The above are all examples of things we can try. I'm not saying any of those is the right solution but I am asking for a mandate in trying to establish a process that will allow us to continually improve Squeak.

I was a little bit forward, when I figured I could take hold of that mandate myself. In the void of vision, that was present after 3.10, the board were even considering not having a 3.11 at all.

I figured that it was better to take the opportunity to try something new, than to keep on with the same exsting process that wasnt really happening. I know Edgar pushed for more of the same in his 3.11 efforts, but the will didnt seem there to support the same approach ad infinitum.

I gtg, but its very very encouraging to hear you sharing these ideas. I know we dont have all the answers and we have a bit of exploration to go... but I do think we might just be able to make this fly

Keith

when I heard it muted that some considered that 3.10 was the end of the line for the current iteration of the kernel.