A process proposal for 3.10
keith_hodges at yahoo.co.uk
Thu Oct 19 04:59:49 UTC 2006
I would like to know how the test server idea would work in practice?
What would it do. Would it be possible to have a one paragraph spec of
such a server.
This is my own idea as to how to informally collect fixes and image
enhancements in a decentralized manner, while the release team take on
bigger things in parallel.
The aim is to attempt to obtain potentially the same end result as the
'update stream' but with the possibility of full community
participation. One would also hope that we can lighten the burden of the
release team so as to free them up to do more radical improvements.
Rather than a test server, this idea gives everyone the ability to test
a known configuration against their hardware and their own favourite
1. Begin with a known starting image, be it a Kernal image or an RC2.
2. Present a wiki page consisting of an install script
This wiki needs the following features
- full support for "history of page" and authors of edits.
- diffs between page versions (if possible)
- wiki links within preformatted text for the script to be annotated.
example script (e.g.
3. Allow updates to be monticello, sm, or change set based, or some
other alternative. i.e. anything that may be found on mantis.
Allow/Prefer the install script to directly download source from the
mantis file repository (possible?)
4. A user can register with the wiki, adding their proposed submission
to 3.9.? to the script page.
4. Testers can then Start with the prescribed image, select the whole
script from the wiki page, and update their local image.
- Run the tests which (hopefully) come with the updates
- Test their own packages/projects with the proposed image.
5. Improve SUnit slightly to enable publishing more than a single test
suite. This allows a TestCase class to publish multiple suites of tests.
Then you can run all the #tests and the #testsFor39Only but not the
6. Each item in the script wiki page may be marked as a link for
feedback, or perhaps to the appropriate mantis page.
7. Have some criteria that we would like submissions to meet, and be
willing to allow our submissions to be commented out and marked as not
ready yet by benevolent testers.
- insufficient test coverage
- breaks something
- tests fail
8. Be nice to each other
If this process can informally chug along while the 3.10 team is
forming. I propose that they then be freer to take on these "big dont
fit monticello tasks on".
The release team begins with the same starting point as this informal
process. When their change is done. They can test it against the
informal process script. They can then post the new image and users can
see how the fix install script and the tests handle the new image. Then
the process of integrating the fixes to the new image can if necessary
be a shared responsibility.
Alternatively the release team can review the current status of the
informal process, declare that a new release, and begin their "big task"
from there, at the same time beginning a new wiki page install script to
harvest more fixes in parallel.
For loadable packages, package universes seem like a viable option.
Again the idea is to raise the visibility of the process and the ability
to involve as many people as want to get involved at whatever level of
commitment they can offer, as and when. I am not sure how package
universes would handle variants. For example, there is Pier, Pier with
Unix Security, Pier with ACL Security, Pier with 4 different Persistency
schemes, and My own snazzy-pier. Those would have to be marked as
mutually exclusive within the universe.
does this idea sound like it has practical potential or am I musing far
Send instant messages to your online friends http://uk.messenger.yahoo.com
More information about the Squeak-dev