[squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Keith Hodges keith_hodges at yahoo.co.uk
Sat Jul 4 22:38:10 UTC 2009


Andreas Raab wrote:
> Folks -
>
> I just had a very good (off-list) discussion where it was brought to
> my attention that one might look at the proposal from the point of
> view that it replaces Installer, Bob & Co. in situ and that there is
> no role for these tools in the proposed process. Nothing could be
> further from the truth.
>
> What I am imagining goes along these lines: Consider Bob running
> daily/weekly builds and then checks if any new fixes have appeared on
> Mantis. If there is anything new, it loads the fix, runs the tests
> inside the image, runs the tests attached to the bug. If this works
> out Bob puts his "stamp of approval" on the fix or commits it directly
> to the repository. In effect, Bob becomes our main harvester doing all
> the boring integration stuff that we can reasonably automate.
>
> This is actually quite similar to what Bob does today - except that
> Bob isn't producing an image but rather commits to the trunk. In any
> case, from my perspective there is a lot of room for Bob and Installer
> - be that in providing up-to-date images from weekly builds, running
> automated test suites, and so on.
>
> I have no intention to get rid of Bob and Installer. I hope that with
> Keith's help we can make maximum use of both since these are valuable
> tools in a successful software development project.
>
> Cheers,
>   - Andreas 
Bob generates and maintains a repository with each build target that it
makes.

Given that there may be 5 of us running our own bob servers why bother
with a centralised (read slow) repository as part of the process.  If we
run a build once a day, the repository with that build target tracks the
changes to that build target day by day. The tricky part is putting
meaningful comments into the repository package comments.

ftp://squeak:viewpoints@squeak.safeprayer.com/bob/output/BuildBase/Squeak3.10.2-build/_source/

A centralised repository can be used for packages that have been pulled
out of the kernel, to be managed externally. We have that repository
already. squeaksource/311

The whole point of the way the process works is that there would be
several projects going on at the same time in parallel. i.e. 3.10 +
closures is a project going on at the same time as 3.10 + mantis fixes.
Each project starts with a fixed starting point. There isn't one
repository that represents the final output, until that final output,
the integration of the chosen projects e.g. 3.10 + closures + fixes is
generated.

It is a point of policy that the build of 3.11 has to be made up of bits
that could be applied to other images. The task that builds 3.11
collects the knowledge of what went in to 3.11, and in doing so makes it
available for other forks to see what we did and follow suit. They can
do this by subclassing our 3.11 generating task and adapting it there.
When they do this, we get to see what knowledge they captured in their
subclass.

You suggest that bob's output should be to commit things to trunk... but
bob is supposed to build images. The reason for this is that he not only
builds the 3.11 image, but he also simultaneously builds all of the
derived images (e.g. the developer image, the full image etc), which you
need to test against.

It looks to me that you are still looking at the production of the final
image as an incremental process. Its not supposed to be an incremental
process. It is supposed to be an atomic process. However it may take
several goes (one per day for a month) to get that atomic process right.
Technically we should be able to make new releases once a month with
ease, but practically the demand for that number of releases per year
would not be there.

Keith
_______________________________________________
Release mailing list
Release at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/release




More information about the Squeak-dev mailing list