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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Mar 12 19:48:08 UTC 2010

2010/3/12 keith <keith_hodges at yahoo.co.uk>:
> Why couldn't Bob harvest changes from Mantis so they can be reviewed and
> posted to trunk?
> 1) Because trunk is a moving target. The principle is that mantis needs to
> manage fixes relative to an actual release. So that you can take a
> production image and fix bits you need to to keep current. If you are
> harvesting fixes from mantis into trunk then you will be adjusting the fixes
> to be appropriate to "trunk" (a moving target).
> Bob isnt only about harvesting fixes.

but Keith,
Mantis fixes of Kernel are dead code. If you don't load AND MAINTAIN
them in an image, they die.
Why can't you realize that ?
I don't know in which language I could explain it to you...

> 2) If you are the developer of a package that loads in all forks, you are
> supported by the ability to load fixes into the other forks you support. The
> trunk process doesn't care about supporting you to keep your package
> working.
> Every change made to trunk is made to trunk only, the implications on that
> change to the packages that you may wish to load is not tested. That is what
> bob was designed to do, to test the whole, and to test all derived images.

It depends whether we change API or internal implementation...
If packages depend on internal implementation, then they are not what
I would call modular, and they must improve.
API does not change gratuitously. Whenever it has to, we warn and ask
in squeak-dev. We should probably record these precious informations
as well as more or less automated rewrite rules.

> 2) The bob process is intended to be used in regular cycles, to generate
> multiple artifacts, that may then be integrated. Trunk messes this up by
> prolonging the release cycle to years to produce one artifact.

I still do not understand.
Since you have Bob with automated tests, you should know very well
when and why a package breaks against trunk.
You can then signal it to squeak-dev and ask for (multiple choice):
- reverting a change,
- providing a backward compatibility hook,
- ask for support for upgrading the packages you use/maintain
Or just DIY.
Keith, that would be added value, really.

Every one has a chance to collaborate in trunk, and sure technical
details are discused and listened...
(Well, I should say when you don't occupy to much band width with
political dead ends)
I can imagine a couple Edgar+Keith regularly reporting what works,
what breaks and discuss the solution here.

Alas... I see you're not cured yet.


> Keith

More information about the Squeak-dev mailing list