On Mon, 15 Aug 2016 22:48:38 +0200 Josef Skladanka <jskla...@redhat.com> wrote:
> Hey gang, > > I spent most of today working on the new API docs for ResultsDB, > making use of the even better Apiary.io tool. > > Before I put even more hours into it, please let me know, whether you > think it's fine at all - I'm yet to find a better tool for describing > APIs, so I'm definitely biased, but since it's the Documentation, it > needs to also be useful. > > http://docs.resultsdb20.apiary.io/ > > I am also trying to put more work towards documenting the attributes > and the "usual" queries, so please try and think about this aspect of > the docs too. After the conversation about resultsdb yesterday, I have a proposal for a change to ResultsDB and clarification about how we'd be using it in Taskotron to answer some of the questions I asked earlier. 1. Add a null-able column to result to indicate the job it came from. This could be a URI or just UUID so long as the final URI could be computed from whatever is stored in this new column. 2. Change "group" to "tag" and plan on it being used for the grouping of results by/for humans. This isn't something that we'd be making use of right away but it seems like a logical feature to add given where things are going. This would mean that we can find the job that every result came from without having to worry about grouping them at submission time. I can think of use cases where there either be no need for a job UUID/URI or one would not exist, hence the suggestion that the column could be empty. How does this sound? Any suggestions, concerns or comments? Tim
pgpHBpRVevEUn.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
