xtuml/BridgePoint Workflow

homepage Forums Miscellaneous xtuml/BridgePoint Workflow

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #5093
    Bob Mulvey

    This topic came up in the miscellanous chat room. I wanted to capture in a spot that is easy to find.

    MeHeba, you had a question about “workflow” ?10:52am
    back to workflow :)10:56am
    how would things go around10:57am
    MeSmile BTW, Keith the new forum is there now.10:57am
    In the developer’s getting started guide, https://github.com/xtu…de.md , you will see that you must create a fork11:01am
    Your work will now always be done in your own fork11:02am
    We still suggest you use branches within your fork, so that you can easily have multiple projects going on, as you did when we working in branches against master. However, the branches are now in your fork11:03am
    Other than that, process is quite similar to what it was when the team was with Mentor Graphics.11:04am
    You pick an issue, or are assigned one (in your case)11:05am
    make sure your fork is up to date with master11:05am
    create a new branch _11:06am
    Write the appropriate development note and investigate11:06am
    Review the note with us11:06am
    compete the work in your fork11:06am
    review again as needed (depending on issue size)11:07am
    run tests11:07am
    when ready for promotion you will create a pull request on your fork11:07am
    Someone with permission to service that pull request will review and promote.11:08am
    BTW, the issues status should be changed to “in progress” when you start working on it11:08am
    When you issue the pull request, the status need to be changed to “resolved” to indicate that the issue is resolved, but not yet in master11:09am
    The person that performs the final review/promotion will close the issue when they promote it11:09am
    I think that is all. Did I leave anything out11:09am

    Bob Mulvey

    When a commit message is made in git we use the following format:

    There is a cron job that looks for the “job:#” in a message and, when found, sends the comment to the specified issue number in the issue tracking system. This serves as a means of requirements tracing. The issue in the issue tracking system ends-up holding links to every individual change that was made (and the comment associated with the change).

    Bob Mulvey

    I must note here that the cron job only runs against the repositories git origin. This means, you will not see all your comments go into the issue until your fork’s branch is promoted.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.