To give a little bit of reasoning: my idea was to provide a new field to make this whole extra metadata completely optional and also because of potential new fields that could appear for special projects.
To treat that information as an appendix that may or may not exist and that we would use in customer-specific tooling instead of UCT.
But I like the idea of moving those fields to dictionaries. That would make the structure look cleaner. I was worried about the repercussions of those changes, as some of those fields are published and we would need to do some filtering over those fields.
One thing that I didn't understand is the keyed by package name. As of today, we are "bundling" those fields by the project (i.e. Ubuntu CVE and subproject CVE). Are you proposing to have those split by package? I was thinking about it as https://pastebin.canonical.com/p/M9QBWSwQpx/
I would be happy to come up with a proposal for the dictionary idea though.
To give a little bit of reasoning: my idea was to provide a new field to make this whole extra metadata completely optional and also because of potential new fields that could appear for special projects.
To treat that information as an appendix that may or may not exist and that we would use in customer-specific tooling instead of UCT.
But I like the idea of moving those fields to dictionaries. That would make the structure look cleaner. I was worried about the repercussions of those changes, as some of those fields are published and we would need to do some filtering over those fields.
One thing that I didn't understand is the keyed by package name. As of today, we are "bundling" those fields by the project (i.e. Ubuntu CVE and subproject CVE). Are you proposing to have those split by package? I was thinking about it as https:/ /pastebin. canonical. com/p/M9QBWSwQp x/
I would be happy to come up with a proposal for the dictionary idea though.