 |
 |
Hi (again), For development on the new hps-java git repo, I would like HPS to use a more formal workflow than we have previously with SVN. Git and github have several nice mechanisms for this. This is my proposal: 1) All new functionality, changes to existing functionality and bug fixes for hps-java which are non-trivial are assigned items in the github bug tracker. 2) These issues are worked on and resolved on branches with a naming scheme like 'iss1234' where '1234' is the issue number from the bug tracker. 3) When development is complete on that issue, the author creates a Pull Request (PR) to request a merge of their development branch back into the master, including any relevant information/details about what was changed or added. 4) Developers cannot review their own PR. They must request a review from someone else. Maurik and I could be the default reviewers with others assigned appropriately depending on the code module (Omar for tracking code, etc.). 5) The reviewer reviews the code and tests it, possibly requesting changes or bug fixes. 6) After the reviewer is satisfied that their requested changes have all been made, the PR can be approved. This is essentially the "standard" github workflow used by many projects. Basically, no work should be checked in directly to the master, aside from the most trivial changes. (I could see the addition of lcsim steering files being an exception here, too.) I have plans to split off the "users" module of hps-java into a separate github repo, where direct checkins to the master would be allowed without any review. We can discuss these proposals in more detail within a future software meeting. --Jeremy ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1