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
?11:09am
HebaNope11:16am
.
