Verified Answers


If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Verified Answer
  • Replies replies
    7
  • Subscribers subscribers
    4
  • Views views
    1100
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Help with Pulse for StarTeam

psciascia

I started playig with Pulse but I had a few things that were unclear, and for which I could not find answers in the documentation. Looking here, I found a video, which was helpful but actually raised more questions. I posted these as a comment on the video but it has not been published, so I figured I would post it here.

I paste it below here:

 

I have started to play with pulse and I have a few questions, which may or may not be issues;

1. In the default workflow of a CR, the status Code Review was added and accessible after Fixed. What does this change trigger? Anything in Pulse?

2. Is a status like Code Review  available in Tasks, which we use to check-in new development?

3. When I check-in - always associating a process item with the check-in - my review has no message (ex: Q3: No delivery message provided). From the video above, the title should be extracted from the linked process item. IT doesn't seem to be the case.

4. If I set a review to "WATCH" the button changes to UNWATCH, but no longer changes, so I am always watching.

5. On a given day, a programmer may make a dozen check-ins to a process item. Each will create a separate review. Can these be grouped? If a file is modified 5 times it would be great to have a cumulative, or at least a diff between the revision of the last check-in and the revision before the first check-in.

6. On a test, I created a review (Q1) on a process item and set it to rework. I then made another check-in for the correction of the rework which created a Q2 review, What is the workflow here? Do I, as reviewer approve the second review, then go back to Q1 and approve that one as well.? How are they not linked?

Perhaps, many of my questions stem from the fact that my titles are not being properly created.

That's it for now, I may post more questions  as I keep trying this feature out.

  • Verified Answer

    0

    As an introductory general comment, pulse, as a technology, introduces content code reviews into StarTeam. With the initial release (i.e 17.0), pulse only supports checkin / (workspace) change packages. With the next release 17.1 due out in November, pulse will be extended to include code reviews of cross-view vcm change packages, both committed as well as uncommitted.

    Enforcement of code reviews of uncommitted change packages is actually a powerful feature, insofar as it allows you to review, verify and influence the changes that will be committed to the target view before/prior to the commit taking place.

    Answers inline to those of your questions which I am in a position to answer...

    1. In the default workflow of a CR, the status Code Review was added and accessible after Fixed. What does this change trigger? Anything in Pulse?

       No. Changing the state of a process item after committing the ChangePackage has no effect on Pulse.

    2. Is a status like Code Review  available in Tasks, which we use to check-in new development?

     No. The Code Review status was introduced on the ChangeRequest type as a consequence of an Enhancement Request raised by you. If you would like to see this functionality introduced on the Task type, I suggest that you raise an Enhancement Request accordingly.

    5. On a given day, a programmer may make a dozen check-ins to a process item. Each will create a separate review. Can these be grouped? If a file is modified 5 times it would be great to have a cumulative, or at least a diff between the revision of the last check-in and the revision before the first check-in.

    No. Individual Code reviews are currently created per checkin (/workspace) ChangePackage. With the 17.1 release, you may prefer to use the pulse code review model on cross-view vcm ChangePackages. With the latter model, you can choose to  aggregate the number of VCM commits made from an activity view to its parent (possibly) release branch, in which case, the corresponding code review would span the set of all checkins for any given file.

     

     

    I hope this helps

    anil

  • 0 in reply to 

    Wow, thanks for the quick and  great answer.  I guess the way pulse works, and especially will work in November, encourages the use of activity views per process item if the cumulative of work is to be reviewed at once, which I have been wanting to put in place rather than a common activity view which is what we use. 

    As far as the workflow for rework, are you able to clarify? Let's say a check-in comes in and creates a review. The reviewer sets to Rework. The Programmer makes a new check-in to correct the mistake which creates another review. I see the review like a process item on its own. Is there a way to link reviews together so that the reviewer knows the a craeted review actually correct a 'rework' review? 

    I am sorry, it's a little hard to explain.

    Thanks

  • 0 in reply to 

    >>Is there a way to link reviews together ...? 

    No,  I am unaware of a mechanism for linking reviews together.

  • 0 in reply to 

    >>encourages the use of activity views per process item

    With the 17.0 release of StarTeam, we have introduced lightweight work views which actively encourage the use of throwaway workspaces. These are typically best used on a per process item basis.

    For 17.0, we introduced them on projects which enforce checkin change packages.

    In 17.1, we are extending them to projects which disable checkin change packages, and continue to use old style links.

    Take care

    anil

  • 0 in reply to 
    Thanks. Talking after the release of 17.1, say a programmer completes a development in a lightweigh view and is ready to merge it back in to the main activity view, will the review get triggered on the commit of the promote or can it be triggered on a saved promote session. I am asking because the review should take place before the commit.
  • 0 in reply to 

    >>will the review get triggered on the commit of the promote

    yes, if you configure the parent view to trigger reviews on committed change packages

    >>or can it be triggered on a saved promote session

    yes, if you configure the parent view to trigger reviews on uncommitted change packages, 

    and further, choose to enforce the requirement that the review must be Approved before the change package be allowed to be committed.

     

  • 0 in reply to 
    Fantastic, thanks!

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.