Bernhard Pieber wrote:
> I am not sure if I understand correctly what you mean by "developed
> against 3.10". Do you mean a certain image
> like Squeak3.10.2-7179-basic? You probably don't mean that if I want
> to fix or improve something I should always do that in a certain
> image, do you? I thought you were deemphasizing that everyone uses the
> same image.
The idea of a release is a little bit broader than it was before. It is
more of a conceptual entity than simply an image. The release does
consist of the image, but it also includes the set of packages that will
load and unload from that image. In effect it is a snapshot of the
entire state of our fork at a particular time. The release team will
release an image, but at the same time, all of the derived distros will
also be available.

When you publish a fix, it has to be against a known quantity, because
those looking to harvest your fix into another fork of squeak, need to
know the starting point in order to see exactly what you did and why in
order to determine how to apply that fix to their fork. If the fix is a
new bit of API, for example 5669, then perhaps the underlying code will
be different for them. Another most important thing to capture is design
intent, and having some discussion recorded in mantis can help with that.
>> 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.
> Interesting. So far it looked exactly like the opposite to me. Since I
> tried out the board's proposal I always stayed in the same image and
> just pressed the "load code updates" button. On the other hand I
> thought your proposed process would have me start from new images
> regularly because you said the update button was useless in that other
> thread.
Bob can build a new image every time the status of a fix changes in
mantis if we want. But you wouldn't necessarily need to download this
image immediately since bob will run the tests as well, and you will be
able to see the test results remotely.
> Sorry, it seems my misunderstanding is even bigger than I realised. I
> am trying hard not to be dense. ;-) So, how often would you take a new
> image in your proposed process?
It depends upon what you are working on.

Since you are developing stuff against the fixed point, you only really
need 3.10.2-build which is the base that everyone is working to.

If you want to see the final integration, then you can take a new build
daily if you want.

If you are working on a project of your own then you might prefer to run
your own bob server, that could build the latest with your project included.
> Would Bob be one central server, or would everyone have his own Bob?
Both... the individual tasks that bob is working are published
publically so anyone can subscribe their own bob to any build.

If you want to define a build without running bob locally you simply
need to get the centralised/public Bob(s) to subscribe to your task that
you upload to Bob/Tasks-Distros or Bob/Tasks-Releases
> As every package version has a comment it seems certainly possible to
> generate all the changes in trunk. What am I missing?
I am assuming that any significant refactoring which includes both
subsystem and client code is unlikely to be restricted to a single
package. We need to capture the knowledge of changes to both

>> 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.
> I agree with that. I just can't see why I or someone else could not
> merge my package versions I save to source.squeak.org/trunk to say
> Pharo. It will always have to be a manual process anyway, because the
> APIs in the image are different. I am not sure if you agree with that.
> Do you?
I very much doubt that the majority of packages are mergeable simply.
The client code for any package API change could be all over the place.

does that help make things clearer?

Keith
>
> Sorry but I am still confused. ;-)
>
> Cheers,
> Bernhard
> ------------------------------------------------------------------------
>
>
>