That seems completely reasonable to me.
On Thu, Apr 24, 2014 at 7:08 PM, Matt Caswell <fr...@baggins.org> wrote: > 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 >
