On 24 April 2014 18:31, Ben Laurie <b...@links.org> wrote: > Note that this is just how to help me, not a consensus view from the > whole team, though I have no doubt much of it will be helpful to the > team, too. > > 1. Triage RT (https://rt.openssl.org/). > > RT has been neglected for a long time. People could usefully go > through it and identify: > > a) Tickets that can be closed > > b) Tickets that should have action taken, and how urgent that action is. > > If a ticket describes a potential security issue, then please don't > just announce it to the list. Instead send it to > openssl-secur...@openssl.org. > > In order to avoid duplication of effort, perhaps someone should set up > a github repo (or something else) assigning ranges to volunteers? It > might also be useful to use the same repo to hold the triage results > (so things can be ticked off as they are actioned). > > See also points 3, 4 and 5.
I would suggest the following process to do as Ben has requested: 1) We 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 I suspect we'll see more and more which are no longer relevant - we will start hitting the law of diminishing returns. 2) 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. 3) The first step is for someone assigned to triage duty to do a first pass assessment about what the RT entry is about. I'm not sure what RT supports here? Can it be configured to record these somewhere (the queue perhaps)? I would suggest classifying as one of: - Bug report - Feature request And given a status of one of (the initial status is New - I'm not sure what statuses RT supports but I'm assuming it can be configured): - 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) Possibly we could further classify by the area of code this report is about, e.g. - Documentation - Command line app - libssl - libcrypto - Compilation & installation - Platform specific - etc Not sure how granular you might want to go here. 4) The next step is for someone (not necessarily the same person who has done the initial triage) to pick up Open requests and mark them as "owned" by them. They then attempt to recreate the bug (I suggest we focus on bug reports rather than feature requests at this stage). This could be done on the basis of expertise, e.g. "John" knows most about libcrypto and so will focus on libcrypto reports. 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) 5a) 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. The status is updated to either: - Rejected (the patch is not suitable, appropriate, or available for all branches) - Approved (the patch is in github for all branches and appears sane - it is ready for the dev team to review) 5b) If the bug is confirmed and no patch is available then the same process as in 5a applies, but the owner creates the patch themselves. 6) The dev team only look at Approved RT reports and verify that they are happy with the patch before committing it. Thoughts? Ben - Is it possible for some of us to get RT users created? The above assumes we can configure RT statuses - is this possible? Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
