[squeak-dev] [Election] ...is soon upon us! Last day info

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 10 21:20:16 UTC 2010

2010/3/10 Torsten Bergmann <astares at gmx.de>:
> Nicolas Cellier wrote:
>>Then I want you to play a little game:
>>take the exact Installer script that installed my mantis patches over
>>3.10, apply it to latest trunk, Cuis and Pharo, and report how it
> Nicolas,
> forget to play such games. I already requested Keith to play such a game
> and demonstrate his technology to me (see bottom of [1]). The answer was
> totally unsatisfying (see bottom of [2]).
> IMHO it will never succeed as long as the original author is not
> able to demonstrate or even explain in a way so we could really follow.
> Maybe Ken can ...
> Bye
> T.

Be sure, I won't play myself, I know very well the result.
That's just to stop false assertions to be repeated over and over again.
The patches have a limited lifetime. Code lives and dies.
It dies because it has good reasons to.
Unless you think trunk evolutions were all gratuitous and we should
better revert ?

One easy demonstration would be to traverse trunk MC repository and
count how many times each method were changed...

For external packages, i want to believe the Installer scripts works
well. But not for trunk...
It could work in a continuous integration scheme but then it's not
really far from trunk process, just with less convenient tools for
And don't tell cross fork patches come for free.

Keith is right when he says trunk dev. model is not easy to duplicate.
He is right because changes span over several packages, and gathering
information is tedious.
Maybe Pharo SLICE policy improve the model a bit :
- publish a bug report
- make a fix in Pharo
- create a SLICE package, let it depend on all dirty packages, publish
the SLICE.
If harvesters wait too long, then the SLICE is obsolete and can
conflict with other changes.
MC merge feature helps in this case. Which Installer tool does ?

I'm not a MC-fanatic, it has some weaknesses.
The worst thing regarding MC is whenever class and methods move into
another package, so it certainly must be improved.
But I don't buy changeSets, I already know the limits too well.


> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003871.html
> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003875.html
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

More information about the Squeak-dev mailing list