We would like developer to deliver change sets to a
stream and allow only baselines to be accepted from the stream, not
individual change sets.

Why? After the deliver, a (stream) build
is started. When it succeeds a baseline is created and developer may
accept the baseline, but when it fails the baseline is not created
and developers should not accept the change sets (because it inflicts
their workspace with a failing build).

Alternative scenario would be that developers deliver to stream
"A" where it is built, then automatically deliver a
baseline from the (successful) build to a stream "B" and
developer accept baselines from stream "B". This would
imply a 'deliver target' to stream "A" and a 'accept
target' (better: 'accept source') from stream "B". Is this
possible?


I understand that the principle for "accept before deliver"
is to assure that any merge conflicts are resolved in the developer's
workspace. So there is a point in forcing developers to accept changes
that cause conflicts.

Why not just accept the changes from the stream before
delivery to the stream, you may wonder?

Suppose a build runs 4 hours. Joe and Mary start their private build
at around 8am and find it to finish successful at 2pm. Joe delivers
and May tries to deliver... oops. She has to accept Joe's changes
first. Then she rebuilds and finishes at 6pm: time to go home, one
day lost. Tom has worked late and managed to deliver at 8pm. Next
day, Mary retries her delivery and finds that she needs to accept
Tom's changes first, run a build and hopefully she can deliver that
same day - possibly not when someone else beat her with a delivery.
So, people start to accept and deliver to the stream without checking
their build. And when the build (on the stream) fails, all workspaces
are infected with changes that fail the build, and nobody is able to
build& test anymore.