[squeak-dev] [Cuis] Cuis
keith_hodges at yahoo.co.uk
Fri Jan 22 01:12:34 UTC 2010
> The trunk process is a "grand project" which hasn't produced
> anything of any use for 6 months. It signs up the community for an
> ongoing wait of 12-18 months per release. It ties you in to the
> "grand project" ethos which we all said we didn't want.
> Nonsense. In the past 6 months, just to take three that come to
> mind, we have closures, native fonts and unloadable smaller traits.
> There are lots of other things also; go look at the recent changes
> list. Trunk is actually progressing very nicely.
First of all these things are of no use to me, because my code base
will take about 2 months to port, longer since I now have to port the
tools as well.
You might think you are doing the community a service, but actually
you haven't provided stuff or "captured knowledge" that the existing
community can use easily. All you have done is encouraged some members
of the community to abandon the rest of us, moving over to developing
stuff for a new image that I cant use, leaving behind compatibility.
My production images don't have closures, the customer asks for an
update, I cant load the latest seaside if it uses closures for
example. This is the same as the pharo "stuff compatibility" attitude
and they are also developing stuff I cant use.
For example, Magma runs in Pharo and 3.7 - 3.10, apparently you
provide closures, but if closures aren't available as a loadable/
applyable feature for 3.7 then magma has to choose either not bother
to use closures, maintain two or three codebases, or drop support for
older images. The knowledge to implement closures has been redone 3
times now, in trunk, pharo, and cuis, but I don't have the expertise
to do it myself.
I think you misunderstand me my gripe is not about making progress, it
is about throwing all the knowledge into one disorganised pot, aka
If you had kept the knowledge needed to implement closures as a
separate initiative, in a separate repo, with separate change sets,
scripts etc then other people could harvest that knowledge, either all
or in part, and you would be contributing "knowledge" that I could
import into my codebase. Perhaps cobalt would like closures too.
Cobalt is not going to be able to move to build on trunk-alpha
overnight either, so they are going to have to do it all over again.
The same goes for bug fixes. Previously we had 100 fixes ready to load
into 3.10 from mantis, all documented, and supplied in their natural
form "changesets". Throwing fixes into trunk, dilutes the knowledge,
and makes it only useful for trunk users and no one else. I cant
harvest a fix out of trunk, into my image.
I suggested a compromise back in August, that Andreas ignored
completely. That if trunk development was split into clearly defined
initiatives with separate projects, then we would be able to work
Again feel free to correct me if I am wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev