> On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral < kpa...@redhat.com > wrote:
> > ...
>
> > What are the use cases? I can think of one - yesterday Adam mentioned he
> > would like to save manual test results into resultsdb (using a frontend).
> > That would have no ExecDB entry (no UUID). Is that a
So, what's the decision? I know I can "guesstimate", but I'd like to see a
group consensus before I actually start coding.
On Thu, Sep 29, 2016 at 7:31 AM, Josef Skladanka
wrote:
>
>
> On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral wrote:
>
>> ...
>> What are the use cases? I can think of one - y
On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral wrote:
> ...
> What are the use cases? I can think of one - yesterday Adam mentioned he
> would like to save manual test results into resultsdb (using a frontend).
> That would have no ExecDB entry (no UUID). Is that a problem in the current
> design?
> If grouping at submission is the concern here, then it would be more than
> easy to do - the idea here (maybe I did not communicate it properly) was to
> use the ExecDB generated UUID as the identifier, the same way we do in the
> whole stack.
> Since the Groups can be created "on the fly" (meani
On Thu, 15 Sep 2016 19:10:56 +0200
Josef Skladanka wrote:
> On Thu, Sep 15, 2016 at 4:20 PM, Tim Flink wrote:
>
> > On Mon, 15 Aug 2016 22:48:38 +0200
> > Josef Skladanka wrote:
> >
> > > Hey gang,
> > >
> > > I spent most of today working on the new API docs for ResultsDB,
> > > making use
That sounds great Josef, thanks!
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
On Thu, Sep 15, 2016 at 4:20 PM, Tim Flink wrote:
> On Mon, 15 Aug 2016 22:48:38 +0200
> Josef Skladanka 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,
On Mon, 15 Aug 2016 22:48:38 +0200
Josef Skladanka 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
On Mon, Sep 12, 2016 at 11:39 PM, Tim Flink wrote:
>
> I think we talked about this in person earlier but I didn't write any
> notes about it and I don't recall the details.
>
> How exactly are we going to be using Groups? The first thing that comes
> to mind is to group results by execution so t
On Tue, Sep 13, 2016 at 8:19 PM, Randy Barlow
wrote:
> Will the api/v1.0/ endpoint continue to function as-is for a while, to
> give integrators time to adjust to the new API? That would be ideal for
> Bodhi, so we can adjust our code to work with v2.0 after it is already in
> production. If not,
Will the api/v1.0/ endpoint continue to function as-is for a while, to give
integrators time to adjust to the new API? That would be ideal for Bodhi, so we
can adjust our code to work with v2.0 after it is already in production. If
not, we will need to coordinate bodhi and resultsdb releases at
On Mon, 15 Aug 2016 22:48:38 +0200
Josef Skladanka 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
So, I have completed the first draft of the ResultsDB 2.0 API.
The documentation lives here: http://docs.resultsdb20.apiary.io/# and I'd
be glad if you could have a look at it.
The overall idea is still not changed - ResultsDB should be a "dumb"
results store, that knows next to nothing (if not no
13 matches
Mail list logo
