Bernhard Pieber wrote:
> Hi Keith,
>
> I must admit that I don't understand why these new package versions
> are not useful for you. It's very probable that I don't understand
> your 3.11 process well enough even though I have read most of your
> e-mails about it.
>
> If I understand your process correctly it should work with different
> images as a starting point, right? So why can't you create one of your
> tasks which
> 1. takes 3.10-7159-basic,
> 2. load the latest version of MonticelloConfigurations from trunk
> 3. MCMcmUpdater updateFromRepositories:
> #('http://source.squeak.org/trunk' <http://source.squeak.org/trunk%27>
> 'http://source.squeak.org/tests') <http://source.squeak.org/tests%27%29>
> 4. continue with your envisioned 3.11 process?
>
> Confused,
> Bernhard
Because the fixes that will be applied have all been developed and
submitted relative to 3.10. The packages that you update to the latest
versions will all have been developed against 3.10.

Using your method you would have to generate the new image, without the
latest of anything, or the fixes, and then wait for everyone to sift
through the fixes and make them relative to your version, which kind of
defeats the object. It is already risky enough applying fixes en-masse
for testing, since there may be clashes.

If you do follow you plan, the fixes in mantis are now against some
indeterminate version, and cant be used by existing 3.10 users in their
existing 3.10 images. This leaves production images and forks based upon
3.10 without fixes that they can apply.

Secondly the knowledge that you are putting into trunk is not organised
into separate portions, it is effectively ad-hoc. Therefore I don't know
what I am adding and what I am not. Documentation of the changes is is
not automatically generatable, and furthermore I cant publish this
knowledge in a form that is useful to Cobalt, or any of the other squeak
forks.

This leaves the Cobalt guys to plough through the history of 40+
packages to findout what you have done. This wont happen so the forks
wont get much closer together.

Thirdly, it would be better for everyone if the same effort was put into
picking a specific project or subsystem that is worked on as an
engineered task, plans, specs, defined interfaces etc, in such a way as
all forks could benefit.

regards

Keith