[squeak-dev] Object >> future
keith_hodges at yahoo.co.uk
Wed Mar 10 21:38:53 UTC 2010
> 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.
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev