The fix-it round is an opportunity to gain build-it points back by identifying which bugs from the break-it round are the same, and fixing them.
To setup your repository for for the fix-it round, you will need to download the zip of your build-it submission from the Builder’s Code page on the website and place it in the root of your repository. Then perform the following commands from the root of your repository (replace NNN with your team id, which is a three digit integer):
mkdir fix
unzip NNN.zip
mv NNN/code/build fix/code
rm -rf NNN
git add fix
git commit -m 'fix start'
This ensures that you start from your final build-it submission. The organizers will make all of the break-it submissions against your team available. You can download the break-it submissions here. You can look on the Break Submissions page on the contest website for bugs submitted against you. If team 3 submitted a successful break against your team, it can be found in breaks/3.
You fixes should address individual break submissions. We will consider correctness bugs first.
For these kinds of bugs, a fix should address the root cause of a particular test case failing. The fix should be the least change you can make to get this test to pass, while addressing the general underlying issue in your code. Now it may be that the change you make to fix one test case causes other test cases (e.g., those submitted other different teams) to pass as well. If so, then you will get points back for those tests.
When you submit your fix, you will have to explain why what you changed addresses a single issue related to a particular test. We will then judge whether we agree that your changes are really covering a the issue uncovered by this test. If we disagree, the fix will be disallowed and no points will be given back.
To submit a fix, fix your implementation in a directory fix/code/. Commit this fix and
note the git commit hash. This is your fix submission. Then create a
directory (e.g., fix1) for submission of this fix. In the directory,
create a JSON file fix.json (i.e., it should live in fix/fix1/fix.json)
like the following:
{
"commit": "fdb3186c9a2b6adcb5ddd96b844123331ba3832c",
"breaks": [563,123,42]
}
The commit attribute indicates the git commit hash of the fix’s commit. The breaks attribute indicates the break submission ids that are being fixed. You will only get points back for breaks that you explicitly include in the json file. Any changes to a json file will be ignored once it has already been commited. You must create a new json file if you want to make modifications.
Your justification for the fix will be stored in a separate text file in the same directory (e.g., fix/fix1/justification.txt). Please reference one of the breaks listed in your json file, explaining how your fix applies to precisely the issue raised in this test. The justification file should be at most 500 words long.
Note that you should make no commits to your fix/code directory that are not fix submissions with a corresponding json file. If you do, we will disqualify all subsequent fixes. If you want to develop a fix collaboratively, you can always change the code in your original build directory until it works and then commit the difference in the fix/code directory.
Once pushed, fixes will be run on the required correctness tests from build-it, as well as the break-it tests that are claimed to be fixed. If the fix passes all these tests, the fix will be marked for judgement; otherwise it will be rejected. We will judge fixes at the end of the fix-it round.
You may also fix integrity and confidentiality issues, but these will not be automatically tested. Rather, a fix for a confidentiality bug should be considered to address all confidentiality test cases submitted against your team. (That is, the breaks attribute should list all confidentiality breaks.) Likewise, a fix for an integrity bug should be considered to address all integrity test cases. If it’s easier, you may submit a single fix that addresses both kinds of issues at once. Either way, make sure you explain your fix(es) in the justification file; if you fix both at once, you may use up to 1000 words.
If you discover a break against your system that you believe is incorrect, make a note of its ID, and write a justification for why you think it is invalid. The justification (no more than 100 words per test case) should indicate why your system’s behavior is acceptable according to the spec, even if the oracle behaves differently. Once you have gathered the list of IDs and justification together, please notify instructors over Piazza.