Andreas Raab wrote:
> 
> Hi Daniel,
> 
> > > Please be clear about what you're trying to achieve with this step.
> [snip]
> > As I understand it, the desired benefit is to remove the latency that
> > occurs between the moment an approver approves something, and the moment
> > Doug send out updates. In the new scheme, approvers would be able to
> > broadcast their update immediately (to the unstable stream). I think
> > that if (using the conflict checker) approvers can be reasonably sure
> > not to make a mess by the very act of publishing from multiple sources,
> > then the way to address the stated concern is to do the same directly
> > with the current stream.
> 
> Thanks. It's good to have an understandment about this (I actually thought
> this was designed to give some people "direct access" to the unstable
> stream). OTOH, let me point out that (as has been earlier mentioned) there
> is really no intrinsic reason why we have to be as conservative as we are
> with the "main" stream. Not in my experience anyway.

I think keeping one stream would be enough.
Allow harvesters to issue fixes and enhancements
to the update stream while in alpha. Then we can withdraw or fix the
updates 
that are broken. Harvesters need to have access to the update stream server.
When all enhancements and goodies are added and the most severe 
bugs fixed, we can move to beta and just fixes are allowed. 
If people say yes to run in alpha stage they will soon learn that it is
risky and 
keep backups of important work. 

We could then also issue updates to the stable versions for advancing to
alpha, 
and then when beta is ready an update to advance to beta, so people can 
skip the alpha stage etc.

Karl