On Fri, Mar 12, 2010 at 8:09 AM, keith <keith_hodges at yahoo.co.uk> wrote:

>
> So I see why you insist that your way would be better, and you may even be
> right. But I'm also part of this community for a dozen plus years and know
> it's not going to follow you on a whim. This community is different, for
> better and worse.
>
>
> I don't insist that my way will be better. You are confusing many things
> here.
>
> 1)
>
> Firstly there is the question of what changes to squeak are possible with
> the trunk method and what changes are not.
> My method allowed any changes, the trunk method prevents me (and edgar it
> seems) from participating. I object strongly to this.
>

You're simply wrong on this.  I, with help from others, managed to get the
closure compiler into several dialects quite recently and I can assure you
that changing the compiler under one's feet is tricky.  There is nothing
inherent in the trunk model that hinders difficult change.  A coordinated
series of package updates is just as powerful as changesets.  One simply has
to try and try again because one will make mistakes and the system will
break and one will be able to discover why and compensate.  Don't confuse
the medium with the message.  Change sets and MC packages are media but they
can convey many messages.  Eventually one gets to a depth at which these
media fail to do the whole job (for example changing the object format,
bytecode set etc).  But Smalltalk's reflective nature is what makes both of
these media equally powerful and equally unsafe.  If you want to make deep
changes you simply have to be prepared to fail, to be confused, to be
persistent and then to be enlightened (often through conversations with
friends).  It's a fun path; more fun and productive than endlessly whining.




> If you want to give the community a familiar method then fine, but that
> familiar method will have to be an update stream of changesets. If you were
> to use that familiar method I would be all for it, anything but trunk.
>
> In case you didn't realise that was what the bob2 method consisted of at
> the end of the day, conceptually it was a series of changesets, that could
> do anything to any image. MC was used to publish the result afterwards.
>
> See, no mention of git bazaar or anything.
>
> 2) The second issue is that of respect.
>
> For someone to turn around and say to edgar ".. but you don't have to use
> squeak" is really quite offensive to me, because Edgar is a pillar of this
> community, and so the development methods we use should support him not shut
> him out.
>
> Squeak is not just the image... We had a series of tools, including LPF
> that made squeak a much better place to work, you could install things
> reliably including dependencies. I regularly installed Magma Seaside
> Scriptaculous Magritte and Pier in a one liner.
>
> For someone to come along who doesnt appreciate that squeak had moved
> forward considerably in the period they had been away, and then discard all
> progress, and actually break things for us, is similarly rude.
>
> Fix the respect issue, and fix the contribution barrier issue and you might
> move forward. It has nothing to do with "my way", my way is just a technical
> way forward I am using to personally extract myself out of this mess.
>
> regards
>
> Keith
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100312/ac26c274/attachment.htm