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 <keith_hodges at yahoo.co.uk>:
> 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
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.