Bob Arning  <arning at charm.net> wrote...
>Well, how about a radical solution: put *all* bug fixes in the (or an) update stream, but in an inactive form. Perhaps simply gzip+base64 the change set plus documentation and install this in some sort of ProposedChanges class. Then you can use any current image to easily extract and test any proposed fix/enhancement. If you put them in *the* update stream, it might be nice to add a preference to skip these kinds of updates since they might be large and uninteresting.

This is *just what I wanted* during the couple of years that I and a few others were doing all the harvesting.  You have a queue of proposed inclusions, and everything can go into it right away so nothing gets lost.  Everything is there for testers to test, and maybe tweak and resubmit.  Then the next release gets tested by just running some subset of these, and released when it is happy.

Interestingly, the current update stream structure could handle this *just fine*.  It is just huge folder of changeSets, and an ordered list of pointers to them.  It should be pretty easy to add a UI for doing what Bob suggests.  To make a new trial release, you just make a new list of pointers (just a new *section of the current update stream or, even better, a new distinct update stream file).  Toggling something active/inactive for that trial release would merely mean adding/removing the corresponding pointer in the update stream for that trial release.  Releasing the result just means pointing everyone at the final version of that update stream.

Motion seconded ;-)

	- Dan