Last week, the OpenSSL dev team had another face-to-face meeting. It was a week of “mosts”: most of the team flew in for most of the week, and most of it was funded by the CII/LF
We got a great deal accomplished during that week. We do many things by vote, and having everyone in the room to talk not only beats email all to hell, but it ensures that we’re all on the same page for the decisions we make. Sure, not everything was a unanimous decision, but none were decided by narrow margins.
In this post I’m going to talk about two important decisions.
But first, here’s a team picture, so you can get an idea of the faces behind the code:
The first issue is about RT our old issue/ticket tracking system. After many fine years of service, frankly interspersed with periods of neglect, we are putting the old nag out to pasture and retiring the service. We’ll soon be updating the website, and the distribution files, but starting immediately we ask that you open GitHub issues instead.
One of the nice things about RT was its email integration. Conversation could happen on openssl-dev and it would get collected into the ticket. We know similar things are possible with various GitHub hooks, so please be patient as we make it more seamless. The general pattern of open an issue and then post a pointer and the text on openssl-dev should still be good, however.
The obvious question is what do we do with the existing tickets? We have been making pretty excellent progress over the past two years (the red line represents the open tickets and the blue line is the total number of tickets closed):
Last week we came to the painful decision to declare a “bug bankruptcy” and close any tickets that are at least two years old. A detailed list of the RT tickets will be posted to openssl-dev, and we will try to send email to everyone mentioned in a ticket (without spamming the dev list), and if their issue is still important, they should open a GitHub issue.
This will result in about half of the 326 open tickets being closed. It was a tough decision; we all had a couple of favorites we wanted to fix “real soon now.” :) But it is the most honest and transparent thing to do. And we are well aware that you don’t get to do this more than once.
Without RT, how is the community supposed to submit patches? For some time we encouraged the use of GitHub pull requests. Now it’s pretty much required. And it’s not right that we don’t do the same thing ourselves. Effectively immediately, all of the team changes will be done via public pull requests. Some of us have been doing this for awhile, but last week we made it official policy that all public team work must be done in public branches. Our policy of every submission requiring another team member to review, or outside code requiring two approvals, has not changed. The new GitHub review tools help make this easier, thanks GitHub!
Of course, security fixes will still be developed in private and not disclosed early. But with this new policy, the community should have the chance to make an earlier impact on improving OpenSSL, which is what this is all about.