Stuff

I have re-subscribed to squeak-dev in order to answer a few points I  
have seen on the list via nabble.

Points to answer...

1. Colin seams to think that he needed to develop Mason because Bob  
requires the building code, i.e. Sake to be in the image being built.

This is WRONG, Bob starts from the premise that the build image can be  
ANY image with no dependencies at all. This is necessary because the  
release teams usually cant even be bothered to produce images with the  
latest tools in, so any hope of any release image having an up to date  
Installer or sake in it is negligible. Given that Bob's goal has  
always been to facilitate the building of minimal and kernel images,  
how on earth do you get the idea that Bob needs Sake in the target  
image?

That is what Bob was designed to do. The only requirement that Bob has  
of the image is that the image can be launched from the command line  
and be supplied with a script. Bob is an image, a server that monitors  
what needs doing and invokes builds and tests. Bob uses Sake  
internally do define a hierarchy of build tasks, with dependencies. Oh  
look thats what Mason's description is, what a surprise. Tell me I  
wasn't wasting my time... oh yes I was, silly me.

So basically Colin admits that he didn't even look at Bob before  
writing Mason. This is precisely the same "Not invented Here" approach  
that I spent so long arguing against in the Pharo camp. This is why I  
have left the squeak community.

2. Andreas starts talking about package management being needed.

Welcome to the programme, only two years behind the rest of us.

I notice you cant even be bothered to recall that Sake/Packages  
exists, and has been working for a long period of time, developed  
precisely because the issue of getting things to work with  
dependencies is the number one issue that needs addressing for Squeak  
to be of any use to anyone for anything. Trunk developers can faff  
around with the image all they like but it doesnt fix ANY of squeak  
problems at all, since squeaks problems are all int he usability of  
its packages.

Don't even get me started on Metacello, more not invented here.

3. Someone said Sake/Packages is no good because its not supported on  
Gemstone.

Sake/Packages was designed to be trivial to port to any platform from  
the outset, unlike any other code e.g. Monticello. So that point is  
completely wrong. It doesnt have any dependencies on the tools used  
for loading things either.

Sake/Packages would be the ideal fit for a cross platform package  
manager, since it's content is user maintained rather than publisher  
maintained and those doing ports tend to be the users.

cya

Keith

Andreas' discussion about packages is one we had 3 years ago...

e.g. "if we are going to be removing packages from core we need a  
place to put them".

That was the discussion which led to the development of sake/packages  
in the first place... however note this. I talked to lex about fixing  
Universes FIRST, and he wasn't up for it. S/P was only developed after  
the existing options have been tried.

Keith

p.s. unsubscribing again

>
>
> p.s. unsubscribing again
>

The main reason I am unsubscribing again is that since I subscribed I  
have got 5 emails of commit messages from trunk. The board didn't  
consult with anyone BEFORE doing this, and until they change their  
decision and stop doing things autocratically, I am out of here, the  
squeak community is not viable.

Has there been any progress on the squeak board "terms of engagement"?  
(Answer privately please if you have any progress to report)

Keith

> So the question is, has ever been considered to simply build the bridge between 
> communities and to use the PharoCore image as the base for Squeak? 

This wouldn't work for the same reasons that it wouldn't work to use a 
Squeak-trunk image as the basis for Pharo. You should propose that at 
some point just to see what kind of reaction you get ;-) 

Cheers, 
   - Andreas 

Piece by piece, increasing the growth of community's knowledge about
what the Bob is.

You can sell anything, if you know how to get people interested.
Keith, your main fault is that you don't care about selling it to
people, instead you quit. No matter how great product is, it  can't
sell itself.

2009/12/16 keith <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

On 16 Dec 2009, at 00:41, Igor Stasenko wrote:

> Piece by piece, increasing the growth of community's knowledge about
> what the Bob is.
>
> You can sell anything, if you know how to get people interested.
> Keith, your main fault is that you don't care about selling it to
> people, instead you quit. No matter how great product is, it  can't
> sell itself.

I don't care about promoting of documenting Bob because because, I  
can't. I haven't been paid since April, and the actions of the board  
etc have a lot to do with that. Writing this email,  coding Bob, or  
even writing emails about Bob doesn't pay the bills. The code is all  
there. Seaside users didn't need documentation. You lot (aka the  
board) collectively turned working with squeak from being a joy to  
being a nightmare.

Secondly, I am not going to compete, I don't have the will or energy  
to compete. I shouldn't be put into the position of having to compete.  
The board has a process of accepting proposals precisely because open  
competition of ideas, and whims in the market place isn't going to be  
of any use if you want to plan an approach properly.  We were supposed  
to be a collaborating community, and Andreas turned it into something  
completely different in a single email, he should have come to me and  
asked how he could serve the existing vision, instead he chose to  
replace it, without discussion.

You either want the vision or you don't, if you want it contribute to  
it, don't compete against it. I am not able to document Bob or promote  
it because I don't have the time, energy, motivation or will to do so.  
Having been sucked dry by having everything I ever said or did  
systematically ignored now you turn on your wounded, accusing me of  
corroding the atmosphere.

This corrosion was an inevitable consequence of having two leaders who  
are tasked with the same job. The board followed a path which had  
inevitable consequences. This fraction was the inevitable path chosen  
by the board. Any one with half a brain would have seen it coming. I  
didn't do anything to cause it, or to corrode anything.

I quit fundamentally because you cant work with people who treat you  
like shit, or people whose organizational structure and policies  
inevitably will result in people being treated like shit. All it takes  
is for one new person to be elected to the board, and Andreas could  
find all of his work discarded too. If there anyone who would like to  
run for the board with the ticket "Lets build the next squeak on pharo  
core", I for one will vote for you, and we can throw this unplanned,  
unmanageable trunk chaos thing away.

I have repeatedly stated that until the board has established its  
terms of engagement there is nothing more that can be done, and having  
watched 4 years of work be routinely discarded piece by piece, I don't  
feel inclined to throw more good effort after bad.

However I do think that it behoves me to point out whenever I can just  
how much time and effort the boards actions have wasted, and how much  
code and progress they have thrown in the bin, because those "terms of  
engagement" are still needed.

Keith

What we are seeing with these recent discussions of Package management  
from Andreas, is essentially an admission that his "new community  
development process" really wasn't a process at all, more of an anti-
process.

Lets all hack in an uncontrolled manner, without documenting our  
reasons, plans or actions, is not a process, and there is no process  
for integration or testing offered either.

6 months later Andreas is still only beginning to think about actual  
process issues, like what do do with a package when it has been  
removed, and how to manage it.

SUnit has already been conceptually removed (there is a loadable dummy  
stub in squeaksource/Testing), and so has Monticello1.5, and Nebraska,  
they are currently loadable via package definitions in Sake/Packages,  
(with LevelPlayingField for MC).

How did the board manage to hand over the reigns of squeak to someone  
who is so ignorant of the actual thinking and progress that had been  
made? Think about it where was Andreas in the years 2006-2009 what  
active role was he playing in the community? What efforts did he make  
to be aware of the progress we had made in that time? I think it is  
quite remarkable achievement to go this far backwards in one day.  
Considering that I worked on squeak for much of that time, is there no  
interest in building on what was achieved?

The package developers lot is one in which the image release teams  
keep breaking things from under you. The pharo team is very guilty of  
this also. Andreas and Stef work in an image developers paradigm where  
they are used to having control of the whole image. So they don't  
think of the process in the terms of the package developer, and  
everything that I have seen Pharo do, and trunk developers do, is  
simply making work for me to keep my packages viable on these moving  
targets.

Sooner or later you will realize that having a moving target in the  
first place is an absolute no no. I manage some 14 loadable packages,  
and they are all being subjected to bit rot by release image  
developers, this is not helpful, or acceptable. Therefore it will be a  
requirement of any actually useful process, to build upon a known  
starting points, known by the package developers of the packages you  
are loading and testing against.

Given that the original goal of moving squeak forward to a smaller  
kernel was stated some 5 years ago, don't you think it is worth  
considering this question sooner rather than later? Or even perhaps  
first! Anyone can hack an image to smithereens (aka trunk) not  
everyone can keep that image stable and tested so that a loadable  
package may be loaded in the new image and older images so that you  
only need to maintain one release of the loadable package. I don't see  
any loadable packages provided by Andreas, or Stef to the community,  
not being package developers, they don't work in the package paradigm.

This is the fundamental problem of squeak and pharo, having release  
images, and release teams that actively make the package developers  
life a pain, because they don't personally test release images against  
working derived images. If you want to test against working derived  
images, then you have to build those images using loadable packages,  
and loadable packages are published to be loadable into a known  
starting point. Hence having moving targets as the starting point for  
image building is not a viable part of the process.

The "new community development process" is not a viable development  
process, unfortunately those pushing this process have destroyed any  
semblance of process for managing bugs and fixes against known images  
with Mantis, hence my designation of it as an anti-process.

Keith

If I email to squeak-dev again shoot me

Keith

On 2009-12-15, at 3:48 PM, keith wrote:

> 1. Colin seams to think that he needed to develop Mason because Bob requires the building code, i.e. Sake to be in the image being built.

I stand corrected.

>  Tell me I wasn't wasting my time... oh yes I was, silly me.

Apparently I'm the one who wasted his time, building something that already existed. ;-)

> So basically Colin admits that he didn't even look at Bob before writing Mason. This is precisely the same "Not invented Here" approach that I spent so long arguing against in the Pharo camp. This is why I have left the squeak community.

I did take a good look at Sake, and a somewhat more cursory look at Bob, via whatever information I could find on the web. Apparently I didn't understand it well enough. I apologize for spreading misinformation.

With hindsight, though, I'm glad I implemented Mason, despite the duplication of effort. With you having left the community, Bob and Sake are unsupported. Mason has become crucial to my development practices and I wouldn't want to be relying on unsupported software that I don't fully understand.

Colin

Soon, peace and order will be restored throughout galactice (c)
Emperor Palpatine


--
Best regards,
Igor Stasenko AKA sig.

keith wrote:
I'm not going to reply to everything Keith said but I'll make an
exception here. I think Keith has misunderstood what I've been saying in
the above (and if that's true many others here might too). He seems to
be implying that this is all just one big pissing match which could be
resolved by me just showing a bit of humility. I disagree. (well, okay,
there is *some* of that here but that's natural given that absolutely
nothing is at stake ;-)

But I do think that there are some fundamental differences between the
goals of Pharo and that of Squeak. From my perspective (and I know
others will differ here but this is my post so I get to put my
perspective forward) Pharo has a relatively narrow goal: Providing a
feasible economic niche around Seaside. From all I've seen that is what
Pharo is aiming for. Not a goal easy to reach, but still a narrow one.

Squeak has always had a much broader perspective. It is driven by the
vision of a universal computing environment, as a medium for personal
dynamic media. Projects like Croquet, Etoys, Squeak-NOS and quite
possibly even Seaside wouldn't have even been started in Squeak if not
for this broader scope. We've lost a good bit of traction in the last
years when Squeak was (from my perspective) degenerating to being "just
another Smalltalk implementation" that had nothing that made it special
anymore, the original vision being lost in some forks and demos on the
web. Fortunately, we've started the process of reversing this trend and
give Squeak back it's own unique position in the open source ecology.
The competition helps in this regard as it requires both sides to
sharpen their profile with respect to each other.

 From the differences in direction, there come some very direct
incompatibilities. Pharo (rightfully!) doesn't care about lots of things
that are not within scope for its goals. As one example, consider MVC
and projects. I don't believe that the Pharo folks will spend a second
to think about any of this stuff - they're currently tied to Morphic and
will soon have to go to some native widgets stuff if they want to be
commercially viable. As a consequence, MVC or projects are quite
understandably of no concern. In Squeak, however, we do care about both
of them very much. MVC is just one of the many faces of Squeak and a
valuable one because we can learn from it. Projects are one of the high
points of Squeak since they allow us to make advances into orthogonal
directions. If there's ever going to be another UI framework in Squeak,
it will take advantage of projects. And so, where Pharo takes the choice
of just deleting everything that doesn't fit its world view, in Squeak
we've been step by step rebuilding all those parts and continue to do
so. The same goes for many other areas.

As a consequence we currently have some irreconcilable differences.
Pharo-core is not an option as a basis for Squeak since it is driven by
a fundamentally incompatible set of ideas at this point. Squeak is not a
basis for Pharo, since it doesn't share the narrow perspective that
Pharo subscribes to. As a consequence there is no other option than
having each system go its own way for the time being.

However, this may change in the future. I do see some serious interest
on both sides in modularity and the competition between the systems is
clearly helping matters along nicely (ah, competition! *alwys* good for
the customer! it would be a shame to fold either Squeak or Pharo for the
resulting lack of competition alone). With developments like FileSystem,
i.e., libraries that replace parts of the core system but are externally
maintained there is a good chance that some homogenization can take
place. At some point it may be worthwhile to review this topic.

Cheers,
   - Andreas

Andreas wrote:
>Pharo-core is not an option as a basis for Squeak since it is driven by
>a fundamentally incompatible set of ideas at this point.

Can you elaborate on this a little bit more.

At least there is enough interest shown here to keep all forks closer
and I think Matthew wrote in November he will try to rebase Cobalt
atop Pharo.

Maybe Pharo-core is not "core" enough to be the basis for Squeak
and other distributions like Cuis, EToys, ...
So what is the "basis"?

Since I use and enjoy both, Squeak and Pharo I think the main
question remaining is if we can find a common "core"/"kernel" for
all distributions/forks and how does it look like...

Bye
T.

--
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

Torsten Bergmann wrote:
We need to decide if this common core will include an UI framework or
not. If the answer is 'yes' then it would be very much like Cuis itself.

> Since I use and enjoy both, Squeak and Pharo I think the main
> question remaining is if we can find a common "core"/"kernel" for
> all distributions/forks and how does it look like...
>
> Bye
> T.

Please take a close look at Cuis: http://www.jvuletich.org/Cuis/Index.html .

Cheers,
Juan Vuletich

Torsten Bergmann wrote:
> Andreas wrote:
>> Pharo-core is not an option as a basis for Squeak since it is driven by
>> a fundamentally incompatible set of ideas at this point.
>
> Can you elaborate on this a little bit more.

I thought I just did ;-) To repeat my example in slightly different
terms: Unless I'm mistaken Pharo probably doesn't support MVC and has no
option to load it back in. Moreoever, I would expect that this is
considered a Good Thing, since it doesn't align with the goal of being a
commercially viable platform. And I think that's true for many other
areas (Etoys for sure) currently under scrutiny.

As a consequence I would expect that with every week there are changes
in Pharo which make it a better Pharo (i.e., commercial platform) but in
return make it a worse Squeak (i.e., universal computing environment).
Given the lack of modularity in the system today that seems unavoidable.

As we improve modularity on either end, we may be able to meet in the
middle at some point. But that's still quite a while out and would also
require more willingness to compromise from either side than is
currently available.

> Maybe Pharo-core is not "core" enough to be the basis for Squeak
> and other distributions like Cuis, EToys, ...
> So what is the "basis"?

I think the real answer here is that we'll learn by competition. Don't
forget that we only just got started. Reinventing the contribution
process was a strict requirement before we can move on to higher level
goals. We're at that stage now, looking at packages, looking at what we
want the Squeak image to be, as well looking at how we can make things
smaller.

> Since I use and enjoy both, Squeak and Pharo I think the main
> question remaining is if we can find a common "core"/"kernel" for
> all distributions/forks and how does it look like...

Like I was saying earlier, I think there's a higher probability that the
"common stuff" will come from outside packages (such as Filesystem).

Cheers,
   - Andreas