Providing baseline quality levels?

Streams in RTC are very inexpensive (both in terms of cost on the
server, and in terms of maintenance ... just delete one when you are
done with it).

What part of delivering to a "promotion level stream" is messy or
complex? One key question is "what are you planning on doing with the
promoted baselines". If you have some team members, which want to only
accept baselines at a given promotion level (as is commonly done with CC
UCM), then having a promotion level stream makes this very easy ... they
would just have that promotion level stream as a flow target of their
workspace.

Note: I do agree that it could be easier ... if RTC let you declare
separately what are the "source streams" (that you accept from) and what
are "target streams" (that you deliver to). Work item 160738 requests
this enhancement.

Cheers,
Geoff

On 9/5/2011 11:38 PM, bmiller wrote:

Hmmm...that seems awfully messy and complex just to reflect a quality
level. Can an entire snapshot be delivered to the steam as a
"promotion"?

This is a small team of developers (6-8) and I was hoping to keep
things simple with only two streams.

In RTC, promotion levels are modeled by streams.
In order to promote a baseline to a given promotion level, you would

deliver the baseline to the stream for that promotion level.

Cheers,
Geoff

On 9/5/2011 10:23 AM, bmiller wrote:
Hello all,

I am looking for a method of providing baseline quality levels
analogous to the baseline promotion scheme in ClearCase UCM.
Basically, a way to communicate the level of testing rigor to which
a
baseline has been subjected.

Any and all thoughts welcome.

Cheers

-Bryan

In RTC, promotion levels are modeled by streams.
In order to promote a baseline to a given promotion level, you would
deliver the baseline to the stream for that promotion level.

Cheers,
Geoff

On 9/5/2011 10:23 AM, bmiller wrote:

Hello all,

I am looking for a method of providing baseline quality levels
analogous to the baseline promotion scheme in ClearCase UCM.
Basically, a way to communicate the level of testing rigor to which a
baseline has been subjected.

Any and all thoughts welcome.

Cheers

-Bryan

Hmmm...that seems awfully messy and complex just to reflect a quality level. Can an entire snapshot be delivered to the steam as a "promotion"?

This is a small team of developers (6-8) and I was hoping to keep things simple with only two streams.

In RTC, promotion levels are modeled by streams.
In order to promote a baseline to a given promotion level, you would
deliver the baseline to the stream for that promotion level.

Cheers,
Geoff

On 9/5/2011 10:23 AM, bmiller wrote:

Hello all,

I am looking for a method of providing baseline quality levels
analogous to the baseline promotion scheme in ClearCase UCM.
Basically, a way to communicate the level of testing rigor to which a
baseline has been subjected.

Any and all thoughts welcome.

Cheers

-Bryan
[/quote

I understand streams are inexpensive in RTC. I guess I am thinking about a small group of mainframe guys getting really confused when they forget to reset their flow target and end up delivering to the wrong location. Plus, someone has to own the task of delivering baselines from stream to stream. It is a large mental jump from single stream plus green streams only.

Work item 160738 would certainly reduce the complexity for large, multistream projects. I'll subscribe to that WI.

The "state=QA" attribute would give those watching a notion of the quality of the baseline or snapshot. It would indicate when it could be grabbed by the next test group for testing or when it was ready for production. Surely you accomplish that with a delivery - it still seems foreign to my twenty years of ClearCase thinking...

Who knows. Maybe they'll love it ;-)

Cheers

-Bryan

Streams in RTC are very inexpensive (both in terms of cost on the
server, and in terms of maintenance ... just delete one when you are
done with it).

What part of delivering to a "promotion level stream" is messy or
complex? One key question is "what are you planning on doing with the
promoted baselines". If you have some team members, which want to only
accept baselines at a given promotion level (as is commonly done with CC
UCM), then having a promotion level stream makes this very easy ... they
would just have that promotion level stream as a flow target of their
workspace.

Note: I do agree that it could be easier ... if RTC let you declare
separately what are the "source streams" (that you accept from) and what
are "target streams" (that you deliver to). Work item 160738 requests
this enhancement.

Cheers,
Geoff

On 9/5/2011 11:38 PM, bmiller wrote:

One advantages of using streams for promotion levels: it remembers the
"history" of what was promoted to that level. So for example, if you
find something seriously wrong with something that was promoted, you can
"fall back" to the previous baseline that was promoted.

Cheers,
Geoff

On 9/6/2011 5:08 PM, bmiller wrote:

I understand streams are inexpensive in RTC. I guess I am thinking
about a small group of mainframe guys getting really confused when
they forget to reset their flow target and end up delivering to the
wrong location. Plus, someone has to own the task of delivering
baselines from stream to stream. It is a large mental jump from
single stream plus green streams only.

Work item 160738 would certainly reduce the complexity for large,
multistream projects. I'll subscribe to that WI.

The "state=QA" attribute would give those watching a notion
of the quality of the baseline or snapshot. It would indicate when
it could be grabbed by the next test group for testing or when it was
ready for production. Surely you accomplish that with a delivery - it
still seems foreign to my twenty years of ClearCase thinking...

Who knows. Maybe they'll love it ;-)

Cheers

-Bryan

gmclemmwrote:
Streams in RTC are very inexpensive (both in terms of cost on the
server, and in terms of maintenance ... just delete one when you are

done with it).

What part of delivering to a "promotion level stream" is
messy or
complex? One key question is "what are you planning on doing
with the
promoted baselines". If you have some team members, which want
to only
accept baselines at a given promotion level (as is commonly done
with CC
UCM), then having a promotion level stream makes this very easy ...
they
would just have that promotion level stream as a flow target of
their
workspace.

Note: I do agree that it could be easier ... if RTC let you declare

separately what are the "source streams" (that you accept
from) and what
are "target streams" (that you deliver to). Work item
160738 requests
this enhancement.

Cheers,
Geoff

On 9/5/2011 11:38 PM, bmiller wrote: