Vulnerability roundup 51: experiments on ticket formatting

Development Security
1

Hi everyone,

after having quite a bit of discussion here in discourse, on NixCon and in IRC I’d try a different ticket format. Vulnerability roundup 51 is split in 6 tickets:

Each ticket is intended to track updating, patching and backporting of that specific package independently.

I’m not sure if that is an improvement compared to the old roundups (all in one large ticket), so I’m glad to hear everyone’s opinions on this.

Pro:

  • Scales better. The goal is to have many people working on security in parallel.
  • Track updating/patching/backporting independently per package.
  • Per-package discussion about patch availability etc.

Con:

  • More tickets. It will be harder to keep an overview.
4 Likes
2

Thank you very much for experimenting with this approach. I believe it will help to keep an overview of the security vector more efficient in the future. Imho the con is not a big problem, if we keep the security label and in addition make the states more visible in a GH board.

3

I prefer the new format too. Also opens up the possibility of future improvements like tagging issues with severity rating or patch availability.

2 Likes
4

Ok, then let’s go for it!

I’ve reformatted the tickets manually last time, but for SR52 I’ll improve the tooling to generate this format automatically.

3 Likes
5

Great! Maybe it would be even worth considering just doing one issue per CVE instead of one per package.

6

let’s keep for the start one per package to see how the tickets evolve over time. Per CVE we would replicate the external databases without much to win for the start