See #114 for some initial comments on this.

I wonder if we could be more specific when this can be removed. I assume this has to do with us being reasonably certain people have updated to new CLI?

Typically this would be something like "Fedora 26 has to be EOL before we remove this"

@sochotni with @ralph we were talking about create a new task to remember ourselves to do it in ~a month.

So you pop the result_id here. Does that mean you submit dict with just 3 keys: waived, product_version and comment for data points submitted with result-id and if it was subject-based it will have subject, testcase, waived, product_version and comment keys?

I know there was server side compat layer too - but I kinda expected CLI to figure out subject/testcase and submit that to server?

Yes, result_id shouldn't be removed here because we moved the call to resultsdb (for having the corresponding subject/testcase to the result_id) only in the API.

I'll change it

It should be ok now.
Thanks @sochotni

This LGTM.

@dcallagh, can you take a look too?

This makes me nervous... but okay. Onwards and upwards...

Might be helpful to indicate which result id failed in this and other error messages.

I guess this wording is copy-pasted from the other code. A more accurate message might be something like: "Unable to determine subject for result id %s"

Looking good overall, although I think these two commits should just be squashed together, right?

13879def0cc2f8dd0122bcaf0afdf423c68695d9 Backwards compatibility in the server for result_id argument.
1ded94f6cddcfa57150374d16cb8ff137c98823a Provided backwards compatibility for result_id

It should be fine now

:+1:, let's go for it.