-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS name, release and architecture to meta? #339
Comments
Sound good to me. I'd call it |
I suggest a list of dicts: [
{
"name": "Fedora",
"release": "22",
"arch": "x86_64",
},
{
"name": "CentOS",
"release": "7",
},
] where any of the fields is optional. This would nicely fit the FAF use case, but we should probably think about others as well :-) |
That works for me. I thought for a little bit about trying a dict of lists (instead of a list of dicts) and I think it might be nicer to use at first. Something like this: {
"Fedora": {
"releases": ["22", "21"],
"arches": ["x86_64"],
},
"CentOS": {
"releases": ["7"],
}
} You could easily check that a message is about Fedora by writing: if "Fedora" in msg2releases(msg, **config):
print "Yes" Whereas checking that a message is "about Fedora" with your proposed message format is a little more cumbersome: if any([r.get("name") == "Fedora" for r in msg2releases(msg, **config)]):
print "Yes" .. but we lose some information with my format. Say we have a FAF message that's about Fedora 22 x86_64 and Fedora 21 arm. The "easy to use" format I suggested above can't express that, but yours can... so, let's use yours. :) |
From Fedora infrastructure, I can also imagine these using it as publishers:
As consumers:
Can you come up with something else? I'd say the list of dicts approach should work reasonably well for all. A single dict could even be enough for all publishers except for FAF. |
Apparently, for the purposes of FAF, it's useful to further filter notifications by OS name (and while we're at it also release and architecture): abrt/faf#432
Do you think it would make sense elsewhere as well? Would it warrant creating a
os_releases
method inmeta.base.Base
similar topackages
andusernames
, and a general filter in FMN? (E.g. filtering out EOL releases, focusing on rawhide, CentOS etc.)Note that the message might have multiple OS names+releases associated with it.
The text was updated successfully, but these errors were encountered: