>
> 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.

Hi Elliot,

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  
"trunk".

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  
together.

Again feel free to correct me if I am wrong.

Keith

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100122/865214a8/attachment.htm