Defect and Feature Review Process

THIS IS A PROPOSED PROCESS

Principles

• Start looking at the newest entries in RT first and work backwards in time. This is on the basis that the newest bugs are likely to still be present and most relevant. As we go back in time we will see more and more which are no longer relevant - we will start hitting the law of diminishing returns.

• Older entries can be looked at on an ad-hoc basis if a person doing triage identifies them (probably on the basis of some post to the dev list) as being important

• Any new RT entries coming in should get the very highest priority. We can only start to make progress if the problem doesn't continue to grow.

Triage

New defects start off in the "New" status. Someone assigned to triage duty will do a first pass assessment about what the RT entry is about.

1) The person triaging the report classifies it as one of:

• Bug report
• Feature request

And gives it a status of one of:

• Closed (the report has already been dealt with; or the report is not relevant or appropriate)
• Open (the report appears to be sane from reading it and requires further investigation)

The triage person classifies the report by area and puts it on one of the following queues:

• Documentation
• Command line app
• libssl
• libcrypto
• Compilation & installation
• Platform specific
• Other

Report Confirmation and Approval

Someone reviewing a queue will take ownership of a report (keeping in mind the principles stated above). It is assumed that people will review the queues that they have most expertise in:

2) A defect owner will pick up Open requests from a queue and mark them as "owned" by them. They then attempt to recreate the bug (if appropriate). The status is then updated to be either:

• Confirmed
• Not Confirmed (this is effectively a closed status - it could be reopened if the initial person reporting the defect provides further information)

3) Review or create patch

3a) If the bug is confirmed and a patch has been supplied then the owner verifies that the patch fixes the issue. They can also sanity check the patch to make sure it looks reasonable. If all is ok the owner should also check that the patch can be applied to all branches. If not the owner can either port the patch themselves to all branches, or request that the submitter do it. Once all of this is done the owner loads the patch into their github repository and creates a pull request (including the RT number in the request)

The status is updated to either:

• Rejected (the patch is not suitable, appropriate, or available for all branches. Again this could be reopened if the original poster submits a revised patch)
• Approved (the patch is in github for all branches and appears sane - it is ready for the dev team to review)

3b) If the bug is confirmed and no patch is available then the same process as above applies, but the owner creates the patch themselves.

4) The dev team only look at Approved RT reports and verify that they are happy with the patch before committing it.

The status is updated to either:

• Rejected (as above)
• Closed