Figure out a better procedure for Competition Changes

[Advay17]

Especially with the last competition, we have a large amount of different features all jumbled together in one branch, and the issue is that we made so much changes during comp to each of those features that we would be losing a huge amount of progress if we just decided to go back to the original branches those features came from.

In an ideal scenario, each of the features we would want for a comp would already be in a complete state and merged to main, and we would just add the smaller changes during a comp to main afterwards. However, when features need to be devved during comp, things become messy, as we often just merge to the comp branch and work on that branch rather than the feature branch. This is because it allows us to work with new features without having to worry about merging even more than we are currently.

I propose that we enforce some sort of branch rule on event branches. Perhaps we limit who can push to these branches to only an account that is only on the dev drive laptops? Everyone else has to code on feature branches, and when they finish with their changes, they can merge to the comp branch. This would actually reduce the amount of merge conflicts we deal with, as we only merge when every change to a feature is done, allowing us to still push our changes safely. This would also allow us to make prs for the feature branches first before the event branch, meaning that code review would be a lot more meaningful and actually allow the reviewers to see if any parts of the code need changes.

[VMFortress]

I agree. I believe a potential setup would look like:

• Create an event branch event/<event name or location>
• Lock event branch to the team5338 account that is on the pit development laptop (not the drive station!)
• Create feature branches in the format event/<event name or location>/<name of feature>
• Individuals develop on their feature branches which can be tested and then merged to the main event branch
• Individuals pull changes to their branch, merge conflicts should be dealt with on a feature branch, not the event branch
• No direct development occurs on the event branch, just the merges (ideally as a rebase in my personal preference but a merge commit works too)
• The commit that goes to each match should be tagged for future reference and can be reverted to if needed
• Event branch gets tested before queue time and if determined unstable, revert to the last good match tag

I don't necessarily think we need to do PRs during the competition due to the time limitations and availability of people to review but between competitions we absolutely should keep up our PR practices.

[ironon]

I absolutely agree with this idea, but one thing I will say is that unless we explicitly give everyone a quick 5 minute training/practice on how this development model works (maybe the meeting before the comp, or in the pits before stuff actually gets going), next comp will probably descend back into madness. Just something to make sure we do

[VMFortress]

Agreed. Before this closes out, I would like someone to write-up a markdown document in our repo here to clearly display how our competition processes will go and submit a PR. This can be a part of #40

[Advay17]

Probably not PRs during comp, I meant PRs after the comp for each of the feature branches. If Github forces us to use PRs, we can just set the required number of reviewers for that rule to be 0.

Also, could we not name feature branches event//? Github rules are based on the name of a branch, so having just event in the name would be difficult to work around. Could we instead do event-feature//?

[VMFortress]

I don't think we'll be forced to use PRs. The branch will just be locked to the dev laptop so the code that should be merged will be pulled in from that laptop directly to the event branch.

We can definitely do a different naming scheme. Outside of competitions, we should likely be labeling branches feature/..., bugfix/..., etc. We could just use standard features or bug fix branches at competitions. Or some Git hosts support organizations when nested with a backslash (something like feature/event or other way around). I'm not sure how GitHub handles that though.

[Advay17]

If anyone is curious, I've kept this issue open because even during last competition, our version control was not great(though definitely better). Part of it was due to the fact that we had so many things to test but not a lot of time. Accordingly, we need to come up with a better procedure for actually testing code and get through our backlog of testing during comps.

[VMFortress]

Definitely still needs to stay open until we at least have a document showing how we handle competition changes, which will include how to handle the git side, unit testing, etc.