Tracking important issues

Matt Caswell matt at
Mon Oct 5 09:00:14 UTC 2020

On 04/10/2020 15:22, Kurt Roeckx wrote:
> On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote:
>> Hi,
>> I would like to have a system so that we can tag issues as
>> important. But I think they fall in a few categories:
>> - Features for the next minor/major release (so 3.1 or 4.0)
>>   that we find important. I've created a new milestone for that:
>> (Post 3.0.0)
>>   We've also had a Post 1.1.1 milestone, but that seems to be just
>>   things that didn't block the 1.1.1 release, maybe some more
>>   things can be moved over.
>>   I suggest we do not add all feature requests to the new
>>   milestone, so that we can have some kind of overview.
>> - Features we want in before beta 1: The 3.0.0 beta1 milestone
>> - Bugs that need to get fixed before the 3.0.0 release: 
>>   currently using the 3.0.0 milestone
>> - Important bugs that affect the stable releases. I've started
>>   tagging bugs that have "triaged: bug" also with the branches
>>   that are affected. But that doesn't say how important it is.
>>   I have 2 proposals for that:
>>   - Create a milestone for them, like 1.1.1-stable. In cases we
>>     have multiple supported branches, we can add for instance a
>>     3.0-stable and use the oldest branches that's a affected
>>     as the target. This would at least match what we do now
>>     with the "3.0.0" milestone.
>>   - Create a label for the severity. I'm not sure we need things
>>     like "severity: minor", but it might be useful too.
> So I've created the "severity: important" label, and started
> tagging some issues with it.

We should define some criteria for what constitutes an important bug.
Everyone always thinks the bug they found is important because it
impacts *them*. But what makes something important for the project?.
Perhaps something about the number of users likely to be affected, or
likely to cause interoperability issues, etc.


More information about the openssl-project mailing list