That is relying on a field that is entered by a developer/L3.  That means mistakes will be made.  I am looking for a way to accurately determine this information that does not rely on manual input.  Also, I just found an example where someone used a single workitem and delivered a changeset to multiple streams with that single workitem.  That would clearly break the use of a field within a workitem. 

Is there anyone who is currently delivering fixes on the workitem basis and not delivering entire jars?  If so, how are you handling this? 

Jay,

I don't understand what you mean by "delivering fixes on the workitem basis and not delivering entire jars". However, there is no direct link between a work item and a stream. Instead, the link is through the iterations defined in a project area and the relationship between that project area and the stream. For instance, a stream is typically owned by a project or team area. It is possible to configure the process of that process area to ensure that a certain process is followed. One can configure an SCM deliver advisor to ensure that changes delivered to a stream match a desired iteration. I'm not an expert on work item advisors but I believe it is possible to restrict the changes made to a work item once it is resolved which would address you comment about the potential for mistakes.

I picked the wrong blog post, I meant this link http://rsjazz.wordpress.com/2013/12/12/using-rtc-work-item-attributes-to-display-rtc-components-and-other-item-data/ . Unfortunately there seems to be no direct way to select a stream as objects.

It is unclear how you are supposed to be able to service products where you want to ship individual fixes and their prereqs.  You would normally fix problems with a work item and it may involve multiple change sets.  You need to be able to associate a change set to a work item for a given stream to deliver this service.  This is a very common way of delivering service and it is surprising that RTC does not do this...  It is not reliable to have hundreds of programmers remember to put the right data in some field to identify the stream. 

The way how we, as far as I know, work is by having streams for the versions that are out there and fix streams derived from them. Developers create a workspace for the version they need to work against from a stream, create the fix and get reviews etc done. The Found In attribute in the work item as well as the flow target of their workspace they use to develop tells the developer all they need to know.

I would assume that we don't have an attribute like you describe because we simply don't need to use one, due to the practices developers are using and the common data in a work item.

Without the ability to associate a change set with a workitem for the current stream, I do not see how you can reliably deliver individual fixes with prereqs.  I believe we are basically broken in that area.  The reason is that we deliver fixes in workitems.  All of the workitem must be delivered.  When you have a prereq changeset, the real prereq is the workitem.  Otherwise if the prereq has multiple change sets, you will deliver part of a workitem fix and not the complete fix.  Teams in WebSphere have been using this approach for many years and based on what I am hearing, that approach is is not safe in RTC.  It sounds like only jar level service is accurately supported in RTC.  How are you actually delivering service?  At the jar level or individual fix level?