[squeak-dev] Re: On the upcoming Leadership Election

Keith Hodges keith_hodges at yahoo.co.uk
Thu Feb 19 14:38:59 UTC 2009


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.







More information about the Squeak-dev mailing list