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 
packages.

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. 
http://smallwiki.unibe.ch/smallwiki/pier/installationofseasidemagmaandpier/ 
)

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 
#testsFor38Only.

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 
etc.

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 
too idealistically?


Keith


 






Send instant messages to your online friends http://uk.messenger.yahoo.com