>
> Keith,
> This is absurd. We can not develop trunk patches in 3.10.2.
> If it would be true, that would mean that you can take all the
> "patches" applied from 3.10.2 up to latest trunk and reload them in
> any order.

Correct.

however not quite in any order though, dependencies can be defined if  
needed. Check the "theory of patches" used by "darcs" SCM. This is  
fairly close to the hypothesis behind darcs.

However you cant do this with trunk because, you have a years worth of  
work in trunk. If you do not release more often, your deltas become  
too large to manage on this basis.

The original goals for developing the release process included monthly  
time boxed releases. (slowed down to bi-monthly to allow everyone to  
keep up)

When "trunk" is proposed, why didn't anyone ask the question, how long  
till the next release, over a year... forget it.

Point of fact, the time is soon approaching when we will have waited  
longer for a release from the trunk process, than I was allowed on 3.11.

> I really want you to try before speaking.
> I wonder what other squeakers think about closures/faster sets/new
> trailers/SmalltalkImage etc... :
> - shall we revert them and wait for a better engineered universal
> loading procedure ?

Well firstly you could have actually tried using the loading procedure  
that I put so much time into developing rather than ignoring it.

Secondly at the point when Andreas override my work, I was documenting  
bob on vimeo, bob was released in February 2009, so you could have  
used it then. So what were you thinking you had to wait for?

Secondly release teams have been saying that they wanted atomic  
loading for, I don't know 5 years now?!? Where is it if it is such a  
priority for making things easier?

> - or are we happy with a better than nothing trunk-only version ?

If you are happy to settle for a better than nothing solution, you  
could have had the courtesy to actually ask what the state of play was  
on bob stuff before replacing it, with a worse than nothing solution.

> In fact, these are not even trunk-only, because Juan, you and pharoers
> can take a part of the burden and port important things to fork.

This is where the problem lies. We would love to, however you have  
explicitly chosen a process which makes this hard, and you have put  
the knowledge in a form which is very difficult to harvest.

It will usually take as much effort to port it as to implement it in  
the first place. So trunk is no help there.

> I don't say that the statu quo is ideal, nor that we should not
> improve inter-fork exchange, but Keith, not this model please !

Well I would say the same thing. Not this model please, anthing but  
this.

Dont develop fixes on top of fixes on top of fixes, and then expect  
someone else to sift through and work out what the hell is going on.

Develop ONE fix, and refine it over time, when it is ready publish it,  
and a single discrete lump, against a known fixed point, that you can  
see the delta clearly.

Keith





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/2bf8e99f/attachment.htm