[squeak-dev] Its a shame

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Its a shame

keith1y
Dear Edgar,

My own personal goal with my contributions to 3.11 is to encourage
teamwork, the contributions of others and the potential for integration
of the various existing streams of squeak past present and future. My
other goal is to continue to have a solid basis on which to build
commercial applications. I believe that Matthew and others share these
goals, and we also recognize that it is not going to be easy to achieve.

Having professed this goal a number of months ago, I find it very
disappointing and somewhat ironic we now have 3 different planned routes
forward for 3.10+. Especially since the fundamentals of the way all
three branches have proposed moving forward are essentially the same.

For you to say there has been no progress in 8 months indicates to me
that you haven't looked at the progress that IS being made. I think
there has been lots of progress.

Example 1
========
If we take a goal of 3.10 and 3.11, that being to unload packages from
the image all the way back to a kernel image and make them loadable
again. Kernel images dont have a UI, so if we do not have an effective
tool for loading things back in again, there is no point in taking
things out in the first place. Hopefully Sake/Packages is that tool.

So with your infinite knowledge of loading lots of things into squeak to
build FunSqueak, there is a great deal that you can contribute to the
community effort of 3.11. You could help fill Sake/Packages with your
knowledge of how to load and unload packages into 3.10.

Example 2
========
Some that know better than I have stated that Atomic Loading is needed
for effectively managing loading/unloading crucial packages in the
kernel. Monticello 1.5 has supported Atomic Loading for a while, however
there have been some System Editor bugs to iron out, which we now think
has been done. So in the past 8 months the possibility of Atomic loading
has moved from coded and guaranteed to crash your image to actually
usable. This is progress, because without it we know that the release
team would expect real pain the closer the KernelImage ideal is reached.

Example 3
========
One major hindrance to the different streams working  together has been
the traits issue. Thanks to Matthew's UnloadTraits script this is no
longer as big an issue as it was.

The above three examples demonstrate that there has indeed been
significant progress in the past 8 months, and these are not the only
examples.

The current situation is that we have some already overworked people
working on different things, and there is always room for more
contributions. However we know that our sub-projects will eventually
work together for good. None of us feel we need to take over and "do it
all ourselves". There are lots and lots of smaller sub-projects to which
you could contribute, to the team effort.

so how about it?

Keith