[squeak-dev] Object >> future
nicolas.cellier.aka.nice at gmail.com
Wed Mar 10 22:17:26 UTC 2010
2010/3/10 keith <keith_hodges at yahoo.co.uk>:
> 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 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.
Take the changes of Sets: they are faster and can include nil. Also,
IdentitySet scale far better. What do you suggest ?
Have only one change every two months ?
Tell Levente "no no, we cannot accept your contribution, it's too fast" ?
More information about the Squeak-dev