[Release] The role of Bob, Installer & Co.
Andreas Raab
andreas.raab at gmx.de
Sun Jul 5 14:46:14 UTC 2009
Keith Hodges wrote:
> Andreas' proposal is to throw every package within the kernel and the
> image as a whole out to be treated as an "external package" to be hacked
> on by any approved person who fancies a go.
Really, the fundamental idea of the proposal to have a shared repository
where I can collaborate with other Squeak developers on core packages.
> The result can be viewed and used by anyone by publishing to MC and
> subscribing via an updates mechanism.
Correct.
> The image will probably be a bit unstable for a bit, but we cant go to
> the extent of breaking it ever, because we are not distibuting a new
> image, just updates, everything must continue to work seamlessly.
Not necessarily. If there is a need to distribute a new image, we can
certainly do that. I'm just not in favor of requiring a new image any
time you want to do anything. Keep in mind that in previous messages
I've pointed out Bob's role in building images based on the trunk
packages. That's useful because people can fetch the latest version for
playing with it which is right in line with the idea of reducing hurdles
since the need to go through a lengthy update process can be just as
bothersome as the need to download a new image every week.
In short: Updates and images go hand in hand. Yes, there will be images,
and I would like Bob to play a role in building these automatically (say
on a weekly basis).
> Everything has to be done in small evolutionary steps as required by an
> updates mechanism. There is no mechanism for removing things from the
> image, or for changing the image structure. You will have to clear out
> stale package references, repository references from your image
> yourself.
All of this can be done automatically. Removals and doIts can be
deployed (for example) via package preambles/postscripts and since the
MCM update mechanism can be instructed to load precisely those version
with the scripts attached to it you can utilize the process in a similar
manner as preambles/postscripts in change sets.
> Then it is supposedly up to Bob to take these packages as an **input**
> putting the image into an unpredictable state.
Actually, you start with some base image (like the previous release)
which I think we can agree on as being called stable. Then you run the
package updater process just like any client would. Not much difference
to a SakeTask (which could be produced from the MCM automatically) and
it leaves the image in a no more unpredicable state than loading any
other code would.
> Then Bob is expected to apply some fixes from mantis which were perhaps
> submited a year ago and were definitely not targeted at the image in
> which bob has to get them to work. Bob then uploads the resulting
> packages up to the trunk repo,
> Bob is now an automated contributor to the single trunk repository.
That's the point where I would hope that Bob can help us to drastically
reduce the turnaround times. A fix produced a year ago should not stall
for a year in Mantis. If Bob identifies the fix within a week or two, if
Bob can prove that the fix doesn't break an existing test and does allow
the provided tests to run then there should be little need to wait for a
year. The point being that Bob's stamp of approval can help us screen
tests that "look ready" much, much faster.
> Bob also helps out by running tests in the hope that at some point in 2
> years time, we get to a point where all the enthusiastic contributors to
> trunk have calmed down and have arrived at a reasonably stable working
> image. At which point a release will be asssembled manually by someone,
> probably Andreas, who will manually update the versions number, and
> manually ftp the new image up to ftp.squeak.org or publish an mcm for
> people to use.
Something along those lines, yes. I think that having an ongoing release
team would be useful, for example to work out which demos should be
included, how the contents is presented, which extra parts (fonts,
media, etc) to include and so on.
Cheers,
- Andreas
More information about the Release
mailing list